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]"

Reply via email to