From owner-freebsd-embedded@FreeBSD.ORG Tue May 12 17:16:03 2009 Return-Path: Delivered-To: freebsd-embedded@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B17D1065676 for ; Tue, 12 May 2009 17:16:03 +0000 (UTC) (envelope-from fb-embedded@psconsult.nl) Received: from mx1.psconsult.nl (psc11.adsl.iaf.nl [80.89.238.138]) by mx1.freebsd.org (Postfix) with ESMTP id 828BF8FC18 for ; Tue, 12 May 2009 17:16:02 +0000 (UTC) (envelope-from fb-embedded@psconsult.nl) Received: from mx1.psconsult.nl (localhost [80.89.238.138]) by mx1.psconsult.nl (8.14.2/8.14.2) with ESMTP id n4CHFuDU005377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 May 2009 19:16:01 +0200 (CEST) (envelope-from fb-embedded@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.2/8.14.2/Submit) id n4CHFu4g005376 for freebsd-embedded@freebsd.org; Tue, 12 May 2009 19:15:56 +0200 (CEST) (envelope-from fb-embedded@psconsult.nl) Date: Tue, 12 May 2009 19:15:55 +0200 From: Paul Schenkeveld To: freebsd-embedded@freebsd.org Message-ID: <20090512171555.GA4985@psconsult.nl> Mail-Followup-To: freebsd-embedded@freebsd.org References: <200904201535.21191.nick@van-laarhoven.org> <200905110940.31187.jhb@freebsd.org> <20090512075254.GA88230@psconsult.nl> <200905121008.19196.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200905121008.19196.jhb@freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: nanobsd boot slice selection does not work X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 17:16:03 -0000 On Tue, May 12, 2009 at 10:08:18AM -0400, John Baldwin wrote: > On Tuesday 12 May 2009 3:52:54 am Paul Schenkeveld wrote: > > On Mon, May 11, 2009 at 09:40:31AM -0400, John Baldwin wrote: > > > On Tuesday 05 May 2009 10:49:38 am Paul Schenkeveld wrote: > > > > On Mon, Apr 20, 2009 at 03:55:23PM +0200, Matthias Teege wrote: > > > > > Moin, > > > > > > > > > > > I've seen this problem as well, but can't for the life of me > remember > > > what I > > > > > > > > > > I'm relieved to hear that. > > > > > > > > Ok, a bit late (interrupt storm generated by device $WORK) but I just > > > > tested with a clean 7.2-RELEASE source tree. I too can report this > > > > regression in boot0 which now looks at the active flag in a MBR table > > > > entry instead of its own default partition byte when not choosing the > > > > partition by pressing 1 or 2 at the prompt. This is a regression. > > > > > > > > The boot0 source code appears to have had a complete overhaul between > > > > 7.1 and 7.2. > > > > > > > > As a workaround, use the 7.1 boot0 source (or even use 7.1 completely > > > > if you care about the anticipated eol of the release). > > > > > > > > I hope Luigi will have some time to look at the default drive delection > > > > algorithm again zome time soon. > > > > > > I think you can simply re-enable the 'update' flag using boot0cfg in 7.2 > to > > > fix this? > > > > The update flag is on, besides it controls whether the first sector is > > written back or not after selecting another slice than the default using > > the keyboard. The problem above shows that the 'default' slice variable > > in sector 0 is not read anymore but the MBR records are searched for > > an active flag. Using the (M$DOS-compatible) active flag only slices > > 1-4 can be set as default, the boot0 default variable also allows for > > selection 5 (next disk) and probably also 6 (pxe boot) to be saved as > > default. > > Err, so one of the things you need to keep in mind, is that boot1 re-reads the > MBR and uses the "active" flag to determine where to load boot2 from (and > where boot2 loads /boot/loader from and /boot/loader loads the kernel > and /etc/fstab from). boot1 prefers an active slice to a non-active slice, > so if boot0 doesn't write back an updated MBR with the active slice changed, > then even if you load the boot1 from slice 2, it will still boot slice 1 if > the active flag is set on slice 1. Note that this is not in boot0, but in > boot1. However, having 'update' enabled should fix this. But on a FB7.1 (and 7.0, 6.[43210] and some 5.x and 4.x releases too) it used to work like this (just tried on a live 7.1p5 system): # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5 333: 14:48 48 240432 2 0x00 334: 1: 1 0xa5 667: 14:48 240528 240432 3 0x00 668: 0: 1 0xa5 670: 14:48 480960 2160 4 0x00 671: 0: 1 0xa5 693: 14:48 483120 16560 version=1.0 drive=0x80 mask=0x3 ticks=182 options=packet,update,nosetdrv default_selection=F1 (Slice 1) # boot0cfg -v -s 2 ad0 # flag start chs type end chs offset size 1 0x80 0: 1: 1 0xa5 333: 14:48 48 240432 2 0x00 334: 1: 1 0xa5 667: 14:48 240528 240432 3 0x00 668: 0: 1 0xa5 670: 14:48 480960 2160 4 0x00 671: 0: 1 0xa5 693: 14:48 483120 16560 version=1.0 drive=0x80 mask=0x3 ticks=182 options=packet,update,nosetdrv default_selection=F2 (Slice 2) # reboot Note that default_selection has changed, but slice 1 is still marked active in the MBR. After rebooting, the kernel in /dev/ad0s2a is loaded (verified by uname -a, both slices have a kernel with a different timestamp) and: # boot0cfg -v ad0 # flag start chs type end chs offset size 1 0x00 0: 1: 1 0xa5 333: 14:48 48 240432 2 0x80 334: 1: 1 0xa5 667: 14:48 240528 240432 3 0x00 668: 0: 1 0xa5 670: 14:48 480960 2160 4 0x00 671: 0: 1 0xa5 693: 14:48 483120 16560 version=1.0 drive=0x80 mask=0x3 ticks=182 options=packet,update,nosetdrv default_selection=F2 (Slice 2) # The active marker has moved from slice 1 to slice 2, most likely this was done by boot0 but I cannot verify this easily. Trying the same on FB7.2 will show that default_selection has changed and slice 1 still marked active in the MBR after 'boot0cfg -v -s 2 ad0' just like on FB7.1 but during the reboot the kernel from slice 1 gets loaded and ad0s1a becomes the root partition. I just cannot but conclude that this is a regression from 7.1 and before. Unfortunately my x86 assembly knowledge is not enough to completely understaand boot0.S (I tried to compare the 7.1 and 7.2 source but had to give up) but boot0.S appears to have changed quite a lot in 7.2 so I'll keep pointing my finger at the boot0.S changes until proven wrong. > -- > John Baldwin Paul Schenkeveld