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 the disk before booting normally. The next time I booted
the machine, the BIOS would then see that there was an active slice on
my first disk, load boot0 from it, and the machine would boot normally.
I think that this explains the behaviour I was seeing, and I certainly
have a slightly better grasp of what's going on now. I think that the
confusion was because I was assuming that the BIOS was executing boot0
from my first disk, which was *immediately* executing boot/mbr from the
second disk without giving me an option to intervene. In fact, boot0
was never being executed, and the BIOS itself was going straight to the
second disk, being the first one with an active slice.
I now intend to configure my mbrs as follows:
I'll keep boot0 on my first disk, with updates *disabled*, and the
default option as F1
I'll put boot0 on my USB drive, again with updates disabled, but the the
default option as F5. Hence, if I leave the USB drive in by mistake,
the system will still boot normally, although I can override that and
boot from the disk instead.
I'll put an empty mbr on my second and third disks, so that boot0 will
never allow me to try to boot from them. (dd if=/dev/zero
of=/tmp/zerombr count=1; fdisk -B -b/tmp/zerombr /dev/mirror/gm0)
Once again, many thanks for the advice,
Regards,
Chris
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
