dthomas53 said:
How would one specify menu options for booting off multiple disks? I was digging through the boot, boot0cfg and fdisk man pages, as well the Handbook, but couldn't find an example/option for this? :\
One doesn't. boot0 auto generates a menu based on what the BIOS and partition table present. boot0 will attempt to read the primary boot device's partition table, and will draw a menu based on what partitions it finds. Each partition is given a shortcut key, starting from F1 for the 1st partition found, working upward to F4 if present (an MBR can hold only 4 primary partitions). It'll also attempt to guess what each partition is, based on the partition type the partition table presents. For example, if you have a FreeBSD partition (partition type 165) and an NTFS partition (partition type 7), it will draw two options: F1 and F2. F1 will be labeled "FreeBSD" based on its partition type, and F2 will be labeled "Win" based on its partition type.
In the case of multiple drives, it is up to the BIOS to present a secondary disk device. If it does, boot0 will draw an F5 menu option labeled "Drive 1" (as opposed to Drive 0, your primary boot device), and selecting that option will cause boot0 to pass execution to the boot code in the MBR of the secondary device. If that secondary device also contains a copy of boot0, you should get another boot menu that is drawn based on the partitions presented in that secondary disk's partition table, as well as an F5 entry labeled "Drive 0". If the "standard MBR" exists in the secondary disk's MBR, the system will simply boot the partition marked as active in its partition table.
It's imperative to realise that boot0 is engineered in such a way so as to solve a problem in the tight design constraints of the PC boot sequence - that tight constraint being only 446 bytes of space available for boot code. It doesn't have a configuration file because the partition table and BIOS already serve as a binary configuration file, and there's simply not enough code space to add more functionality than that. With that in mind, you might encounter situations where boot0 draws menu items that are labeled with a "?" character instead of something meaningful - the reason for that is that there's not enough space to store more than a handful of possible partition types and associated labels, so it only recognises partition types that its authors recognise as popular. That's also why it draws "Win" instead of "Windows".
With that said, boot0 can be "configured" in some ways, and that is what
boot0cfg(8) is for. Apart from writing boot0 code to the MBR, it gives you the ability to set some low level options that work by taking the base boot0 code residing at
/boot/boot0 and altering certain offsets within that binary. In other words, it modifies the boot0 binary code for you before writing it to the disk. It does nothing more than alter defaults that are set at compile time, much as one would otherwise do manually with a hexeditor.
And after this lengthy explanation you might be wondering... "Why go through all this trouble, and how does a boot loader like Grub accomplish so much more functionality?"
I guess it comes down to values and ideals. Grub is subject to the same constraints as boot0. It works around them by writing 446 bytes of boot code in the MBR, and another 8k or more of boot code else where on the disk which the MBR code chain loads. Traditionally this would be in the gap of unused space between the MBR and track 1 of the disk, but I think that's changed in Grub 2 seeing as that legacy gap is less of a certainty with modern partitioning regimes. boot0 is hand written assembler to keep its size as small as possible, and because of that ideal it can accomplish everything it does without making assumptions on where/how to have more boot code.
(YMMV, E&OE)
