Date: Tue, 28 Oct 2003 09:48:36 -0800 (PST) From: Dan Strick <strick@covad.net> To: jhb@FreeBSD.org Cc: dan@ice.nodomain Subject: RE: boot0/1 problems Message-ID: <200310281748.h9SHmaiH000537@ice.nodomain>
next in thread | raw e-mail | index | archive | help
On 22 Oct 2003 John Baldwin wrote: > > On 22-Oct-2003 Dan Strick wrote: > > I seem to have stubbed my toe on another nasty little bootstrap problem. > > My Gigabyte motherboard AWARD BIOS passes the wrong drive number in the > > %dl register when it invokes the MBR bootstrap program, boot0. > > This forces me to configure the MBR bootstrap with the setdrv option. > > The noupdate option must also be set because otherwise I risk writing > > the MBR partition table back to the wrong disk and that would be a major > > disaster. > > > > Here is the problem: the boot1 program depends on the boot0 program > > setting the active partition flag in the MBR partition table. This > > doesn't happen if the boot0 noupdate option is set. > > > > The boot1 program always boots the active FreeBSD slice (or the first > > FreeBSD slice if there is no active FreeBSD slice). > > If you have multiple FreeBSD slices on a disk whose boot0 program is > > configured with the noupdate option, YOU CAN ONLY BOOT ONE OF THE > > SLICES. > > > > I have release 4.9-RCx and 5.1 slices on the same disk. If the 5.1 > > slice is active, the system wedges hard if I attempt to boot the > > 4.9-RCx slice. If the 4.9-RCx slice is active, the system resets > > if I attempt to boot the 5.1 slice. > > > > This really sucks. > > > > Can someone who knows how the bootx programs are supposed to work > > verify that my understanding of the problem is probably correct? > > Yes, it is correct. > > > Can someone suggest a workaround? > > You can change the device you load the kernel from by changing the > 'cuurdev' variable. Thus, if you do 'set currdev=disk1s2a' you can > switch from the first slice to the second. You can set the device to > mount your root filesystem from by using > 'set vfs.root.mountfrom="ufs:/dev/ad0s2a"'. You might be able to use > the beastie menu in current and hack it to add a menu item for booting > your 4.x slice and then always boot into the current loader and pick > 4.x from the menu. Thanks for the suggestion. I think I want a "solution" that does not make booting one slice dependent on another slice. For the moment I have settled for not being able to boot the 5.1 slice on this disk. I don't know what I will do for a permanent fix. I think the basic source of the problem is that the boot0/1/2 system is currently just too fragile. One possible fix for the current glitch might be to make boot1 configurable with a setdrv option much like boot0. This would make a lot of sense since boot1 is always installed in a particular slice and is typically installed by the disklabel/bsdlabel program which could configure the setdrv option automagically. Another bootstrap improvement might be to copy the boot0 program to a new location in memory by rereading it from disk instead of copying it from memory location 0x7c00. This would guarantee that it could be safely rewritten back to the same disk. Another bootstrap improvement might be to always attempt to use the "extended" int13 disk i/o function and fall back on the traditional c/h/s function if the extended function fails. This would fix the problem where a boot0 program configured to use the extended BIOS functions cannot load the next MBR in the chain because it is on a disk whose BIOS does not support the extended functions. (This one also took me a while to figure out.) I don't know if any of these changes would be practical. There is not a lot of space in a 512 byte bootstrap sector. (And it has been many many years since I last wrote 8x86 code.) For the moment, I will have to use the bootstrap as it is and live within its limitations. Dan Strick strick@covad.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200310281748.h9SHmaiH000537>