# Trouble Installing Dual Boot BootManager



## johndh2 (May 20, 2011)

I'm trying to follow the FreeBSD Handbook, Chapter 2, procedure for installing i386 RELEASE-7.4 on a Pentium 4 two-HDD (SATA's) PC currently running Win XP Pro (32bit). I can't believe the trouble I'm having trying to figure out how to get the FreeBSD boot manager installed. I've got Windows on an 80GB drive which the installer sees as ad4. I'm wanting to put the FreeBSD on a separate 40GB drive, which the installer sees as ad6, and to install the FreeBSD boot manager to cover both OS's. Section 2.6.4 of the Handbook tells me I need to install the boot manager on BOTH drives. The trouble is, after I choose to install the boot manager on the ad6 drive (Section 2.6.3), I'm never given a chance to get back to the ad4 drive. Thus I can never install FreeBSD boot manager there.

Let's don't diverge into other methods/boot managers here, please. I'm interested in solving the problem of not being able to achieve what the Handbook says I ought to be able to do.

Thanks for anything that helps here.

John Hixson


----------



## dthomas53 (May 31, 2011)

Unless I'm mistaken, I don't believe the FreeBSD Boot Manager has the sophistication to choose/boot from separate hard disks (i.e. you can only create a boot menu for OSs on the same hard disk).

If you are looking to boot from the first disk or second disk, I believe you will need make that selection in your BIOS boot device priority settings. This is quite possibly why many choose to use GRUB, instead (but that's just speculation).

Therefor, you should only need to install the standard MBR for FreeBSD on your second disk (during your install), and can leave your Windows MBR untouched. If you have already overwritten your Windows MBR, you can reinstall it using a Windows install/repair disc or simply boot a FreeBSD disc into single-user and use boot0cfg(8).

Good luck.


----------



## aragon (Jun 1, 2011)

johndh2 said:
			
		

> Section 2.6.4 of the Handbook tells me I need to install the boot manager on BOTH drives. The trouble is, after I choose to install the boot manager on the ad6 drive (Section 2.6.3), I'm never given a chance to get back to the ad4 drive. Thus I can never install FreeBSD boot manager there.


I'm not sure why the handbook says what it does.  The only drive that needs a boot manager is the drive which your BIOS recognises as the primary boot device.  If that is your Windows drive, that's where you install it (it will overwrite the Windows boot loader).  In that case your FreeBSD drive will just need the "standard MBR" boot loader.  Having another copy of boot0 won't hurt, but might get confusing.



			
				dthomas53 said:
			
		

> Unless I'm mistaken, I don't believe the FreeBSD Boot Manager has the sophistication to choose/boot from separate hard disks (i.e. you can only create a boot menu for OSs on the same hard disk).


You are mistaken.  boot0 is the most functional 446 bytes on the planet.


----------



## dthomas53 (Jun 2, 2011)

aragon said:
			
		

> You are mistaken.  boot0 is the most functional 446 bytes on the planet.



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? :\


----------



## aragon (Jun 2, 2011)

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)


----------



## dthomas53 (Jun 5, 2011)

Thank you, aragon. That was a thoroughly informative post and one I'll put to good use. 

You should consider sending this off to freebsd-doc@. It belongs in the Handbook.


----------

