Date: Tue, 28 Oct 2003 14:45:06 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Dan Strick <strick@covad.net> Cc: dan@ice.nodomain Subject: RE: boot0/1 problems Message-ID: <XFMail.20031028144506.jhb@FreeBSD.org> In-Reply-To: <200310281748.h9SHmaiH000537@ice.nodomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28-Oct-2003 Dan Strick wrote: > 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. So whoever runs disklabel last gets to boot? :) > 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. I implemented that, but it hung on some machines. > 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 also implemented this, but it required boot0 to grow to more than one sector and the modified boot0 didn't work on some systems. > 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. Yes, you are basically stuck due to lack of space and lots of quirky BIOSen out there. boot1 can't really read your mind, so how is it supposed to pick which slice to boot from other than scanning the MBR as it currently does and preferring an active slice to a non-active slice? One thing you might be able to do is write your own boot1 that has the slice hard-coded in it and build a custom boot1 for each slice to bypass boot1's algorithm to search the MBR. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20031028144506.jhb>