Em 02/07/2009, às 03:59, "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> escreveu:
You're pretty much on the wrong track here.
Yikes. Colour me puzzled then. So what's that BFS *partition scheme* add-on for?
The haiku_loader just scans the disks for known partitioning systems *and* file systems. It neverneeds an actual partitioning system; but it does check the offset givento it by the stage1 boot loader to see from which partition to boot.
If it's then supposed to find the boot volume independently of it being declared on a supported partitioning scheme as long as stage1 provides a valid offset, well, that's not working for me...
The haiku_loader is brought up but shows no volumes. In fact, I could only tell it was brought up because instead of loading the kernel it entered the volume selection screen by itself, out of not finding any (bootable) volume.
Case in point: I have bootman installed on a separate GPT entry with a 'BOOT' 4-byte magic at the start of the Haiku UUID signature I proposed some time ago. The hybrid MBR/GPT IPL was changed to look for this signature. Bootman has entries for all volumes, detected from the GPT, including, of course, the bootable BFS volume. Neither that nor the bootman partition have corresponding entries on the MBR.
If I compile in GPT support for both the kernel and the loader, everything is peachy. If I compile for neither, it doesn't matter if the bootable volume is loaded via "external" stage1.bin chainloading or "internal" chainloading via bootman reading the 1st sector of the volume: haiku_loader will present you to the volumes selection screen, one with no entries at all.
If as you say everything is supposed to work regardless of partitioning scheme support *at least* as far as booting the system is concerned (ignoring any other volumes that might exist on the disk since there's no partition to map them), well, it doesn't work for me. Should I file a bug report or am I missing something (as usual :))?
Cheers, A.
