From owner-freebsd-questions@FreeBSD.ORG Thu Aug 23 10:59:57 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B0B016A41A for ; Thu, 23 Aug 2007 10:59:57 +0000 (UTC) (envelope-from xfb52@dial.pipex.com) Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by mx1.freebsd.org (Postfix) with ESMTP id F03F113C469 for ; Thu, 23 Aug 2007 10:59:56 +0000 (UTC) (envelope-from xfb52@dial.pipex.com) Received: from [192.168.23.2] (62-31-10-181.cable.ubr05.edin.blueyonder.co.uk [62.31.10.181]) by blaster.systems.pipex.net (Postfix) with ESMTP id 0F108E00028E; Thu, 23 Aug 2007 11:59:54 +0100 (BST) Message-ID: <46CD68AA.4020709@dial.pipex.com> Date: Thu, 23 Aug 2007 11:59:54 +0100 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7.13) Gecko/20061205 X-Accept-Language: en MIME-Version: 1.0 To: Christopher Key References: <46CC1DB7.7040506@cam.ac.uk> <20070822152326.GF56142@gizmo.acns.msu.edu> <46CD58BB.9080001@dial.pipex.com> <46CD625E.7090508@cam.ac.uk> In-Reply-To: <46CD625E.7090508@cam.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jerry McAllister , freebsd-questions@freebsd.org Subject: Re: FreeBSD MBRs X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2007 10:59:57 -0000 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