Reliable Custom FS Bootloader solution using GrUB.

[gravaera]

I discovered, by a small moment of extreme insight, that it is entirely possible to have a kernel loaded off of any custom filesystem by GrUB no less, via a method which completely invalidates the need to write any form of 512 byte partition bootsector code.

The method is simple: For OSs not using EXT, ReiserFS, or any other FS format recognized by GrUB, simply reserve a number of sectors directly following the first sector of your FS's partition on any drive.

Place your ELF kernel image in this space. Have GrUB load the kernel image from the first N secotrs of the partition. In this manner, any kernel image of any size may be loaded by GrUB off any custom Fs format.

Since GrUB loads the kernel directly off a partition, no bootloader is needed. In other words, the partition bootloader stage is completely bypassed. So no matter what partition your kernel exists on, GrUB can load it, and load it into protected mode no less, as long as GrUB is installed into the MBR.

http://wiki.osdev.org/I_use_a_Custom_Fi ... _for_me%3F

Please see the above link for more information. It may also be wise to add this to the Wiki's FAQ, so as to once and for all cut short the stream of constant bootloader questions. If everyone uses this method, then they get jumped directly into the protected mode kernel stage even on real hardware.

--All the best
gravaera

[Combuster]

This just reminded me of a beginner mistake (no offence meant):

The reason to have the kernel stored in the filesystem is for convenience - you don't have static sizes, you don't have to special case to store a kernel, and it's user friendly. And once it works, you can just forget about it. While yes, GRUB can well operate in an unformatted environment but the key feature of GRUB over other bootloaders is that it can also operate in hosted environments.

Why would you think we were all no longer using LILO?


Nice article, but I would seriously considering labeling it something other than "ultimate solution"

[gravaera]

Heh. Point taken.

I'll just label it: Flexible GrUB based solution, or something to that effect.

--All the best
gravaera

[Solar]

No offense intended, but of all the ways to boot your kernel using GRUB, this is the least flexible... it expects a kernel of a given size at a given position on the disk (as Combuster said). That's what LILO did, which is why GRUB was so successful getting rid of these limitations...

[fronty]

s/GrU/GRU/g. Purely aesthetic correction.

[scgtrp]

I made some miscellaneous capitalization fixes (mostly s/GrUB/GRUB/g).

My opinion is that this seems like an exceptionally hacky and temporary way to do it.
Better temporary solution: put the kernel and GRUB on a floppy/CD image; load kernel from there but have the kernel load anything else it needs from the correct partition.
Better permanent solution: implement your filesystem in GRUB.

This isn't a good enough solution to justify potentially changing the filesystem spec to allow for reserved sectors at the beginning.