Re: FreeBSD MBRs
Ivan Voras wrote: Christopher Key wrote: I've a machine with 3 SATA drives. The first (ad8) with a standard FreeBSD install in a single slice with /boot/boot0 MBR. The remaining two drives (ad10, ad12) are in a RAID1 mirror with 3 slices, and used for storing data. They have the /boot/mbr MBR. Ok. Let's call them the first (ad8), second (ad10) and third (ad12) drive After booting off various USB flash drives to try and update the BIOS on my machine, it got into a state where during startup, it would display 'Missing operating system' and hang. What seems to have been happening is that it was trying to boot from one of my data store drives, despite the boot order of the disks set in the BIOS. Flashing the BIOS often resets all settings, including boot order. Depending on your BIOS, controller and motherboard, you might need to first select the active controller, then the drive on the controller. In your case, you need to finally tell BIOS to boot of the first drive (ad8). Another thing that might be happening (though judging from what you said elsewhere it's not probable) is that the changed BIOS code enumerates devices differently than it used to, so ad8 is no longer the drive with boot0. This case will not hurt your RAID if you used gmirror, it might for other systems. The only solution that I found was to start booting from a USB flash drive with a boot0 MBR, and to hit F5 to change to booting from my first drive After this, the machine then reboots quite happily until I hit F5 again, in which case I get the same 'Missing operating behavior'. This persists even while power cycling the machine. Ok, so now you're booting from the first drive, and with F5 you're telling your boot loader to skip it and move on to the second drive, which has the standard mbr (this mbr is what's displaying the Missing operating system message). I had imagined the boot process to be entirely stateless, certainly across power cycles. The BIOS executes the MBR on the first drive in its boot boot. The boot0 MBR then allowed you to either execute the boot sector from any of the slices on the current drive, or to execute the MBR from the next drive in the list. boot0 will by default remember what's the last option you booted from and use it as the default for the next time. It may not be the best thing for you, but I found it to be extremely useful behaviour in several cases, since it allowed me to script a boot order when the BIOS and the disk controller didn't get along for booting. However, this clearly isn't what's happening. Is it boot0 remembering my F5 key stroke, or is it more likely that the BIOS is remembering something? Does anyone have any recommendations to avoid this in the future? Is putting boot0 on all three drives a good idea perhaps? It will not hurt in any case to put boot0 on any drives (as long as you do it with the appropriate utility, else you may destroy the partition table). In your case, it will only be useless. Here's something to try (I didn't try it): Do you have active partitions on the second and the third drive? If so, you might want to unmark them, and hopefully the boot loader won't display the drives in the boot menu. Maybe. Or, if you're seriously worried about hitting F5 during boot, you might try an alternative boot loader such as sysutils/extipl or sysutils/grub. Hello All, Many thanks Ivan, Lowell, Jerry and Alex for your feedback. I've done some experimentation, and had a read of the boot0 and mbr source code, and I think I know what's going on now: When executed, boot0 retains a copy of the partition (slice) table in memory, and in it, marks each slice as being inactive. When you hit F1-F4 to boot one of those partitions, it marks the selected slice as active, rewrites the partition table to the disk, and executes the appropriate boot sector for that slice. If on the other hand you hit F5, it writes the partition table back out *without an active slice*, and executes the MBR from the next disk. In my case, when I hit F5, boot/mbr was executed from my second disk, which displays 'Missing operating system' if there is an active slice but no magic number in the boot sector for that slice. Now, as far as I can tell, when I next attempted to boot my system having hit F5 previously, the BIOS didn't attempt to boot from my first drive because there was no active slice. It instead tried to boot from my second drive, hence giving me the message 'Missing operating system'. Now, when I inserted the USB drive and tried to boot, the BIOS saw the there was an active slice on it, and executed boot0 from it. When I then hit F5 to switch to my first harddrive, boot0 was loaded fro it, and showed its default option as F5, having remembered that from last time. If I then hit F1 to boot from the first slice on that disk, boot0 would mark the first slice as active in the partition table and write that back to
Re: FreeBSD MBRs
Jerry McAllister wrote: You only need an MBR on disks that will be booted. I don't know as it will actually hurt anything to write an MBR on non-boot, data only disks, but it can garbage up you menu with non-functional choices. What you need is an MBR on every disk which is *passed through* or actually booted from. So if you have disks 1, 2 3, if you want to boot from disk3 you need an MBR on disks 1 2 as well, even if you never boot from them. If you boot from disk 1, then 2 3 do not *need* an MBR. Those other disk with an MBR show up as an F5 and maybe F6, etc ( F5 is the *next* disk. There is no F6, F7 etc. If you boot from disk 3, for example, you'd go through three menus e.g. Disk1: F5 - disk2 Disk2: F5 - disk3 Disk3: F1 - boots FreeBSD If those were your only 3 disks, then F5 on disk3 takes you back to disk1. You can probably change the boot order of those disks in your BIOS to make disk3 be disk1, avoiding the intermediate menus. That's not always possible for other reasons. For example, in the setup above, if disk 1 has Windows on it and that really does work best as disk1. If disk 2 is on the same controller as disk 1 your BIOS might not allow that to be changed independently. I know of no reason why you wouldn't want the MBR on all your disks, even if you don't technically need it. Sorry, no idea if this helps with the original question, which I too had trouble following. --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MBRs
Alex Zbyslaw wrote: Jerry McAllister wrote: You only need an MBR on disks that will be booted. I don't know as it will actually hurt anything to write an MBR on non-boot, data only disks, but it can garbage up you menu with non-functional choices. What you need is an MBR on every disk which is *passed through* or actually booted from. So if you have disks 1, 2 3, if you want to boot from disk3 you need an MBR on disks 1 2 as well, even if you never boot from them. If you boot from disk 1, then 2 3 do not *need* an MBR. Those other disk with an MBR show up as an F5 and maybe F6, etc ( F5 is the *next* disk. There is no F6, F7 etc. If you boot from disk 3, for example, you'd go through three menus e.g. Disk1: F5 - disk2 Disk2: F5 - disk3 Disk3: F1 - boots FreeBSD Thanks Jerry, Lowell and Alex, That clarifies a few points. Sorry the original post wasn't clear, I'll have a go at rexpressing my original questions using the above for context. Firstly, when you hit F5, does it, a) Load the partition table from the next disk and update the displayed list of slices, or b) Execute the MBR from the next disk? I'll assume the latter. Secondly, does boot0 'remember' that you pressed F5, and hence do the same the next time you boot, even after a power cycle? In this case, having done, Disk1: F5 - disk2 Disk2: F5 - disk3 Disk3: F1 - boots FreeBSD the next time, it will appear as, Disk3: F1 - boots FreeBSD The behaviour that I was experiencing was as follows: Disk1: F1 - boots FresBSD reboot Disk1: F5 - disk2 Disk2: Has /boot/mbr on it, and hence attempts to boot the active slice. As there is no active slice on the disk, simply fails with the message 'Missing operating system' Now, subsequent attempts to boot simply display the message 'Missing operating system'. Hence, I concluded that either, a) boot0 was rembering the F5 keystroke, and passing me on to disk 2 automatically, or b) That the BIOS was rememering something and booting straight from disk2 despite the boot order having disk1 first. The only was that I found to rectify this was use a boot from a USB device with boot0 on it: USB: F5 - disk1 Disk1: F1 - boots FreeBSD And now, subsequent reboots work fine: Disk1: F1 - boots FresBSD I hope the above is a little more clear now. Regards, Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MBRs
Christopher Key wrote: Sorry the original post wasn't clear, I'll have a go at rexpressing my original questions using the above for context. It was a complicated series of events, so it's easy to end up with a confusing description (and the fault might lie with us being too dumb to understand :-)) Firstly, when you hit F5, does it, a) Load the partition table from the next disk and update the displayed list of slices, or b) Execute the MBR from the next disk? I'll assume the latter. b). If there is no MBR on the next disk then F5 will beep (might depend on MBR version) and do nothing. Secondly, does boot0 'remember' that you pressed F5, and hence do the same the next time you boot, even after a power cycle? In this case, having done, Disk1: F5 - disk2 Disk2: F5 - disk3 Disk3: F1 - boots FreeBSD the next time, it will appear as, Disk3: F1 - boots FreeBSD Everything is remembered. However, the sequence will always start with disk1 - whatever the BIOS thinks is the boot disk - and then default to exactly what you pressed the last time *for that disk*. So you would see Disk1: F5 - disk2 Disk2: F5 - disk3 Disk3: F1 - boots FreeBSD exactly as above. (There is an option when writing the MBR to *not* remember - man bsdlabel would tell you. And you can change the default for a particular disk, again with bsdlabel, but there are issues with doing this on mounted disks: IIRC you can set sysctl kern.geom.debugflags=16 before writing MBR and set it back to 0 afterwards, if you are having problems. It's just a magic incantation which I have no deep understanding of :-(). The behaviour that I was experiencing was as follows: Disk1: F1 - boots FresBSD reboot Disk1: F5 - disk2 Disk2: Has /boot/mbr on it, and hence attempts to boot the active slice. As there is no active slice on the disk, simply fails with the message 'Missing operating system' The missing OS message makes sense for a disk with no active slice, but the rest simply doesn't accord with my expectations unless perhaps you somehow wrote an MBR which does not remember. For the record, I have 4 SATA disk in my workstation and regularly boot off disk 3 (because disk 1 has Windows). If I boot windows (F1 on disk1) then the next time I reboot I have to remember to press F5 to get to disk 2 and on to FreeBSD, because it does remember the F1 from the previous boot. DIsk 2 will remember it's F5 and disk 3 it's F1, irrespective of what I do on disk 1. (And yes, if every disk were set to F5, you'd go round in a loop forever, never booting anything :-)) Now, subsequent attempts to boot simply display the message 'Missing operating system'. Hence, I concluded that either, a) boot0 was rembering the F5 keystroke, and passing me on to disk 2 automatically, or b) That the BIOS was rememering something and booting straight from disk2 despite the boot order having disk1 first. The memory for the key you pressed is *per disk* because (IIUC) it is actually stored on the the disk somewhere in the MBR. It's not unheard of for a BIOS to completely change the boot order when the devices attached to the machine are changed. So, if you set your BIOS to boot from a USB stick, then disk X; if you then removed the USB stick I would not be at all surprised if the BIOS reverted to some apparently random boot order where disk X was *not* the first disk. I've had immense trouble with this in th past trying to boot from CD where the BIOS would not reliably spot that the CD was actually attached. If the boot order with a CD was e.g. CD Disk X Disk Y The boot order when the CD was *not* recognised could easily end up as: Disk Y Disk X It might have been controller order or somesuch, but was *not* the same order just minus the CD. Could this have happened? If your disk2 from the original boot order had become disk1, would that explain what you saw? The only was that I found to rectify this was use a boot from a USB device with boot0 on it: USB: F5 - disk1 Disk1: F1 - boots FreeBSD And now, subsequent reboots work fine: Disk1: F1 - boots FresBSD --Alex ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MBRs
Christopher Key wrote: I've a machine with 3 SATA drives. The first (ad8) with a standard FreeBSD install in a single slice with /boot/boot0 MBR. The remaining two drives (ad10, ad12) are in a RAID1 mirror with 3 slices, and used for storing data. They have the /boot/mbr MBR. Ok. Let's call them the first (ad8), second (ad10) and third (ad12) drive After booting off various USB flash drives to try and update the BIOS on my machine, it got into a state where during startup, it would display 'Missing operating system' and hang. What seems to have been happening is that it was trying to boot from one of my data store drives, despite the boot order of the disks set in the BIOS. Flashing the BIOS often resets all settings, including boot order. Depending on your BIOS, controller and motherboard, you might need to first select the active controller, then the drive on the controller. In your case, you need to finally tell BIOS to boot of the first drive (ad8). Another thing that might be happening (though judging from what you said elsewhere it's not probable) is that the changed BIOS code enumerates devices differently than it used to, so ad8 is no longer the drive with boot0. This case will not hurt your RAID if you used gmirror, it might for other systems. The only solution that I found was to start booting from a USB flash drive with a boot0 MBR, and to hit F5 to change to booting from my first drive After this, the machine then reboots quite happily until I hit F5 again, in which case I get the same 'Missing operating behavior'. This persists even while power cycling the machine. Ok, so now you're booting from the first drive, and with F5 you're telling your boot loader to skip it and move on to the second drive, which has the standard mbr (this mbr is what's displaying the Missing operating system message). I had imagined the boot process to be entirely stateless, certainly across power cycles. The BIOS executes the MBR on the first drive in its boot boot. The boot0 MBR then allowed you to either execute the boot sector from any of the slices on the current drive, or to execute the MBR from the next drive in the list. boot0 will by default remember what's the last option you booted from and use it as the default for the next time. It may not be the best thing for you, but I found it to be extremely useful behaviour in several cases, since it allowed me to script a boot order when the BIOS and the disk controller didn't get along for booting. However, this clearly isn't what's happening. Is it boot0 remembering my F5 key stroke, or is it more likely that the BIOS is remembering something? Does anyone have any recommendations to avoid this in the future? Is putting boot0 on all three drives a good idea perhaps? It will not hurt in any case to put boot0 on any drives (as long as you do it with the appropriate utility, else you may destroy the partition table). In your case, it will only be useless. Here's something to try (I didn't try it): Do you have active partitions on the second and the third drive? If so, you might want to unmark them, and hopefully the boot loader won't display the drives in the boot menu. Maybe. Or, if you're seriously worried about hitting F5 during boot, you might try an alternative boot loader such as sysutils/extipl or sysutils/grub. signature.asc Description: OpenPGP digital signature
Re: FreeBSD MBRs
On Thu, Aug 23, 2007 at 11:33:02AM +0100, Christopher Key wrote: Alex Zbyslaw wrote: Jerry McAllister wrote: You only need an MBR on disks that will be booted. I don't know as it will actually hurt anything to write an MBR on non-boot, data only disks, but it can garbage up you menu with non-functional choices. What you need is an MBR on every disk which is *passed through* or actually booted from. So if you have disks 1, 2 3, if you want to boot from disk3 you need an MBR on disks 1 2 as well, even if you never boot from them. If you boot from disk 1, then 2 3 do not *need* an MBR. Those other disk with an MBR show up as an F5 and maybe F6, etc ( F5 is the *next* disk. There is no F6, F7 etc. If you boot from disk 3, for example, you'd go through three menus e.g. Disk1: F5 - disk2 Disk2: F5 - disk3 Disk3: F1 - boots FreeBSD Thanks Jerry, Lowell and Alex, That clarifies a few points. Sorry the original post wasn't clear, I'll have a go at rexpressing my original questions using the above for context. Firstly, when you hit F5, does it, a) Load the partition table from the next disk and update the displayed list of slices, or b) Execute the MBR from the next disk? I'll assume the latter. The latter is the next step if you hit F5 (which can cause an updated menu to be displayed based newly current configuration of the information on that next disk). Secondly, does boot0 'remember' that you pressed F5, and hence do the same the next time you boot, even after a power cycle? In this case, having done, It remembers, if and only if you don't hit anything during boot time. If you hit something - like F1, that becomes the choice that it works on regardless of what was hit in any previous boot. Disk1: F5 - disk2 Disk2: F5 - disk3 Disk3: F1 - boots FreeBSD the next time, it will appear as, Disk3: F1 - boots FreeBSD The behaviour that I was experiencing was as follows: Disk1: F1 - boots FresBSD reboot Disk1: F5 - disk2 Disk2: Has /boot/mbr on it, and hence attempts to boot the active slice. As there is no active slice on the disk, simply fails with the message 'Missing operating system' Now, subsequent attempts to boot simply display the message 'Missing operating system'. Hence, I concluded that either, a) boot0 was rembering the F5 keystroke, and passing me on to disk 2 automatically, or b) That the BIOS was rememering something and booting straight from disk2 despite the boot order having disk1 first. This is the behavior I would expect, but seems somewhat to contradict Alex's response. The first part seems correct that it cycles around through disks in boot order, but he said that you should see another F5 choice instead of a missing OS error.I have not had a string of disks more than two bootable disks and those being disk 0 and disk 1, so I can't be sure and would be inclined to accept Alex's response. But, then it should not have a problem with that disk 2, so without a chance to experiment, I don't know how else to respond. I think the next experiment I would be inclined to try, at least if there was nothing on that second disk (actually called disk 1 as in 0..n disks) that I needed, I would overwrite that MBR with zeros (from /dev/zero, so it has no MBR and no other boot type info and then slice and partition it and see what happens. You could just overwrite the MBR with dd and it shouldn't affext the rest of the disk, but that would make me really nervous if I had anything valuable on it. But if you are unconcerned, try dd if=/dev/zero of=/dev/ad1 bs=512 count=1 ad1 being the second disk or da1 if it is SCSI of SAS That should wipe the MBR on it. Then, the previous MBR might not try to look at that second disk, or if Alex is completely correct, then it will and not find it and get another error. So, experiment. jerry The only was that I found to rectify this was use a boot from a USB device with boot0 on it: USB: F5 - disk1 Disk1: F1 - boots FreeBSD And now, subsequent reboots work fine: Disk1: F1 - boots FresBSD I hope the above is a little more clear now. Regards, Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD MBRs
Hello, I've a machine with 3 SATA drives. The first (ad8) with a standard FreeBSD install in a single slice with /boot/boot0 MBR. The remaining two drives (ad10, ad12) are in a RAID1 mirror with 3 slices, and used for storing data. They have the /boot/mbr MBR. After booting off various USB flash drives to try and update the BIOS on my machine, it got into a state where during startup, it would display 'Missing operating system' and hang. What seems to have been happening is that it was trying to boot from one of my data store drives, despite the boot order of the disks set in the BIOS. The only solution that I found was to start booting from a USB flash drive with a boot0 MBR, and to hit F5 to change to booting from my first drive After this, the machine then reboots quite happily until I hit F5 again, in which case I get the same 'Missing operating behavior'. This persists even while power cycling the machine. I had imagined the boot process to be entirely stateless, certainly across power cycles. The BIOS executes the MBR on the first drive in its boot boot. The boot0 MBR then allowed you to either execute the boot sector from any of the slices on the current drive, or to execute the MBR from the next drive in the list. However, this clearly isn't what's happening. Is it boot0 remembering my F5 key stroke, or is it more likely that the BIOS is remembering something? Does anyone have any recommendations to avoid this in the future? Is putting boot0 on all three drives a good idea perhaps? Regards, Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MBRs
On Wed, Aug 22, 2007 at 12:27:51PM +0100, Christopher Key wrote: Hello, I've a machine with 3 SATA drives. The first (ad8) with a standard FreeBSD install in a single slice with /boot/boot0 MBR. The remaining two drives (ad10, ad12) are in a RAID1 mirror with 3 slices, and used for storing data. They have the /boot/mbr MBR. After booting off various USB flash drives to try and update the BIOS on my machine, it got into a state where during startup, it would display 'Missing operating system' and hang. What seems to have been happening is that it was trying to boot from one of my data store drives, despite the boot order of the disks set in the BIOS. The only solution that I found was to start booting from a USB flash drive with a boot0 MBR, and to hit F5 to change to booting from my first drive After this, the machine then reboots quite happily until I hit F5 again, in which case I get the same 'Missing operating behavior'. This persists even while power cycling the machine. I had imagined the boot process to be entirely stateless, certainly across power cycles. The BIOS executes the MBR on the first drive in its boot boot. The boot0 MBR then allowed you to either execute the boot sector from any of the slices on the current drive, or to execute the MBR from the next drive in the list. However, this clearly isn't what's happening. Is it boot0 remembering my F5 key stroke, or is it more likely that the BIOS is remembering something? Does anyone have any recommendations to avoid this in the future? Is putting boot0 on all three drives a good idea perhaps? I am having a little trouble following the narrative here, but maybe I can comment on a couple of specific questions. The system does record your most recent menu choice and the next time it will be the default if you don't hit another one during the countdown. This makes it default to trying to boot the way it last booted. You only need an MBR on disks that will be booted. I don't know as it will actually hurt anything to write an MBR on non-boot, data only disks, but it can garbage up you menu with non-functional choices. Those other disk with an MBR show up as an F5 and maybe F6, etc (I've never had more than two at a time) in the menu, but then if you hit F5, it won't be able to go anywhere, because there is no real boot stuff on that disk. jerry Regards, Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD MBRs
Christopher Key [EMAIL PROTECTED] writes: I've a machine with 3 SATA drives. The first (ad8) with a standard FreeBSD install in a single slice with /boot/boot0 MBR. The remaining two drives (ad10, ad12) are in a RAID1 mirror with 3 slices, and used for storing data. They have the /boot/mbr MBR. After booting off various USB flash drives to try and update the BIOS on my machine, it got into a state where during startup, it would display 'Missing operating system' and hang. What seems to have been happening is that it was trying to boot from one of my data store drives, despite the boot order of the disks set in the BIOS. The only solution that I found was to start booting from a USB flash drive with a boot0 MBR, and to hit F5 to change to booting from my first drive After this, the machine then reboots quite happily until I hit F5 again, in which case I get the same 'Missing operating behavior'. This persists even while power cycling the machine. I had imagined the boot process to be entirely stateless, certainly across power cycles. The BIOS executes the MBR on the first drive in its boot boot. The boot0 MBR then allowed you to either execute the boot sector from any of the slices on the current drive, or to execute the MBR from the next drive in the list. However, this clearly isn't what's happening. Is it boot0 remembering my F5 key stroke, or is it more likely that the BIOS is remembering something? Does anyone have any recommendations to avoid this in the future? Is putting boot0 on all three drives a good idea perhaps? The boot process isn't completely stateless at the best of times; it uses the partition (as in slice) table to tell it what to boot by default. I think that explains the behaviour when you boot from the flash drive, but not when you try to boot from the SATA disk. It won't hurt, and might help, to put the FreeBSD boot manager on more of the disks. You could also try other boot managers; at the expense of having a boot manager that doesn't fit completely into the MBR, you could get something more user-friendly. Good luck. -- [Greetings to Cambridge; I spent a term in the city as a teenager (fifth form), and I loved the place.] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
