Revision as of 07:31, 21 November 2009 view source osdev>Scgtrp IN UR WIKI FIXIN UR CAPITALLIZASHUNZ ← Older edit		Revision as of 07:33, 21 November 2009 view source osdev>Scgtrp ... and part 2. Newer edit →
Line 3: == Installing your OS on a partition == It has occurred to me that GRUB can be used to load a boot partition OS from any kind of ~~File System~~filesystem. In light of this, I've written this article. GRUB allows you to do a lot of things that you wouldn't be able to do with any other bootloader due to its ability to load an OS in raw sectors from a ~~Floppy~~floppy or ~~Hard~~hard drive. I must give a small overview of the boot process for an OS that is installed in a partition other than the first partition, which is also not the only OS installed on the ~~Hard~~hard Disk. The Master Boot Record holds the Boot Manager for the disk. GRUB is techniacally a boot loader, but its functionality far exceeds that of a conventional boot loader, and crosses the line of a Boot Manager very convincingly. Line 21: For Windows, a record is placed which indicates the partition Windows is installed on, and an instruction to ''chainload'' one sector (512 bytes) into RAM at 0x7C00, and jump to it; In other words, simply load the Windows bootloader into RAM as if it was placed there by the BIOS. For OSs that use EXT, ReiserFS, or other directly supported GRUB ~~File Systems~~filesystems, you have the convenience of being able to ask GRUB to look into the partition and ''find'' your kernel file and load it into memory. For OSs that do ''not'' use a GRUB supported File system, the convention has been to simply ask GRUB to chainload the partition boot sector for your OSs partition and jump to it. Line 69: There are other reasons why it is probably ''best'' that Hobbyist OS Developers use this method: The method implies that GRUB is placed into the MBR of a hobby OS partition installation, or even whole disk installation. IFIf all hobby OSs use this method, whether or not they use a custom FS, it gives them the advantage of being able to load a full program, in ''protected mode'' via GRUB, and bypassing the Real Mode bootloader stage ''completely''. No more problems with writing an efficient program in 446 bytes. Line 75: And, the best advantage of all is that again, GRUB will then be able to allow Hobbyists one more, extremely essential advantage: The unification of all hobbyist OSs under one bootloader. This will mean that every OS coming out will be using GRUB. Then, since Windows doesn't care enough to be polite, if it overwrites ~~GrUb~~GRUB and placed NTLDR into the MBR, then since everyone else is using GRUB, Windows ends up looking like the selfish, unpopular choice. Also, GRUB has code to handle all kinds of unexpected real hardware situations in Real Mode that you kernel's private bootloader cannot deal with most likely.

I use a Custom Filesystem - What Bootloader Solution is right for me?: Difference between revisions