After being chainloaded by GRUB, where is my partition?

[TylerH]

After I get chainloaded by Grub, how can I tell where the second of sector in my partition is? Or more generically, where my partition I was loaded from is?

Thanks.

[JackScott]

If I understand the question correctly, you want to know how your kernel can tell what boot device GRUB loaded your kernel from.

The Multiboot Specification reserves a place in the boot information structure for that information. Read this. What I think you're looking for is offset 12 in the structure.

[Love4Boobies]

Also, using Multiboot 2 (WIP but usable), that would be tag type 5.

[TylerH]

If the OS image was not loaded from a bios disk

Does this mean for chainloaded bootloaders too? I don't want to load my kernel image with Grub, just my bootloader.

[Combuster]

A bootloader receives the drive number in DL, you can then get from that drive the relevant information. Or you can patch your bootloader binary to hold the location of the partition you want to load from (both have advantages and disadvantages).

[TylerH]

Yeah I was thinking about hard coding the location into the boot sector, thought it was a little crude, but if you consider it a possibility I guess hard coding is okay. Thanks.

[Brendan]

Hi,

A bootloader receives the drive number in DL, you can then get from that drive the relevant information.

The MBR code is also meant to leave DS:SI pointing to the boot loader's partition table entry; so that the boot loader can find out which partition (on which device) it came from.

This gives 3 possibilities:
a) Use DL and DS:SI to find out where you came from, and hope that the MBR/boot manager did the right thing. This is what Microsoft do.
b) Use DL to find out which device, then load the partition table yourself and search for your partition. This would work, even if the MBR/boot manager is dodgy and doesn't set DS:SI; but fails in most "multiple OSs" scenarios (e.g. where there's some sort of boot manager that creates a dummy/virtual partition table to get around the "only one partition table entry can be active" restriction).
c) Hard-code it when the OS is installed. This makes the boot loader code easier, but makes it a little harder to install the OS and makes it very hard to relocate the partition with generic tools.

In all of these cases, you'd need to supply your own MBR/boot manager (in case you're installing the OS on a blank device that doesn't already have an MBR, which includes most USB flash devices). Your own MBR could be capable of more than just booting one active partition though.


Cheers,

Brendan

[TylerH]

Interesting, but one question, if the partition pointed to is an extended partition, how can I know how many EBRs to skip?

[Brendan]

Hi,

Interesting, but one question, if the partition pointed to is an extended partition, how can I know how many EBRs to skip?

DS:SI should point to a structure that contains the starting and ending sector for your partition. It doesn't matter if it's a primary partition or an extended partition, or even if it's a virtual partition (that was artificially constructed by some sort of boot manager) that isn't mentioned (or isn't the same) in any partition table.


Cheers,

Brendan

[TylerH]

Oh, okay. Thanks.