MBR & stage1 do not handle boot partition passing for chainloading (makebootable should not be required)

[mmu_man]

Unlike GRUB, GRUB2, LILO, and most other MBR loaders, our own MBR sector does not pass the selected partition info properly, and our stage1 loader does not attempt to use it, which is why we require running makebootable on install. But it should not be necessary.

Most MBR pass the selected boot partition entry in a register (ds:si) with a flag set to let the chainloaded OS know about it. There is no reason not to do it as well, as it would eliminate the need for makebootable.

This is not about BIOSes, buggy or not, since it's only the MBR which does this, and except if the user does not install our own MBR or GRUB or GRUB2 or the many other MBRs which support this convention, it would just work without makebootable.

We can still ship with makebootable just in case, but it shouldn't be required anymore once this is fixed.

cf. ​http://www.gnu.org/software/grub/manual/legacy/root.html#root ​http://f.osdev.org/viewtopic.php?f=1&t=26015 ​http://forum.osdev.org/viewtopic.php?f=1&t=22470 ​http://forum.osdev.org/viewtopic.php?f=1&t=27371 ​http://forum.osdev.org/viewtopic.php?f=2&t=23227 ​http://stackoverflow.com/questions/17517813/grub2-chainloading-how-does-it-pass-drive-number-and-partition-entry-point

[mmu_man]

Related to #3545 although I don't understand the wording.

[starsseed]

Our booting process does not handle the "drive number" passed in the DL register, either, stopping us to boot Haiku from "BootManager" when it's not installed on the boot drive.

Both issues should be adressed simultaneously.

[mmu_man]

See also EFI hybrid MBR boot (draft) at page 73: ​http://www.t13.org/documents/UploadedDocuments/docs2010/d2132r4-Enhanced_Disk_Drive_-_4_EDD-4.pdf

[mmu_man]

Replying to starsseed:

Our booting process does not handle the "drive number" passed in the DL register, either, stopping us to boot Haiku from "BootManager" when it's not installed on the boot drive.

I'm quite sure I've seen DL being passed around in several places as boot drive, at least the MBR code and stage1, didn't check bootman though.

[mmu_man]

Actually, we would still need makebootable though, since it writes all of the stage1 loader, not only the partition offset...

[mmu_man]

But the raw image could now be dd-ed onto a partition without any need for makebootable.

[axeld]

It's more of a "nice to have" thing than a requirement in any case.

[pulkomandy]

So, there are some problems with this:

• According to Wikipedia(​https://en.wikipedia.org/wiki/Master_boot_record#MBR_to_VBR_interface), "The Windows Vista/7 MBRs no longer provide this DS:SI pointer." They do provide the pointer in DS:BP instead, so we have to check both in stage1 now.
• When our MBR finds a GPT, it will use that to find the partition to boot from (by checking for the boot signature in each partition). In that case, there is no MBR entry to point to. As far as I can see, the suggestion is to build one that points to the right place on disk and use that. There is no space free in the boot sector for this.

So, the stage1 loader has to:

• Check if the address in either DS:SI or DS:BP points to a valid partition entry, and if so, load from there
• Otherwise, parse the GPT partition table again and look for the boot signature (assuming only the boot partition has the boot signature set - but this is similar to the "active" partition flag)

This seems quite difficult to fit in stage1, which already includes a (very) minimal BFS filesystem implementation and HPKG file reader. We could, however, free some space in both mbr and stage1, by removing the non-LBA disk reading code (still using cylinders/head/sectors).

[mmu_man]

Why do I think Microsoft likes to screw up things for others…