Date: Sun, 9 Jan 2011 19:33:16 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: Tom Judge <tom@tomjudge.com> Cc: freebsd-hackers@freebsd.org, luigi@freebsd.org Subject: Re: sys/boot/boot0/boot0.S - r186598 Message-ID: <20110109183316.GA92631@onelab2.iet.unipi.it> In-Reply-To: <4D295820.20807@tomjudge.com> References: <4D295820.20807@tomjudge.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 09, 2011 at 12:39:28AM -0600, Tom Judge wrote: > Hi, > > Today I ran into an issue where setting the default slice with boot0cfg > -s is broken. a few questions inline: > This is related to a section of this revision: > > + commit Warner's patch "orb $NOUPDATE,_FLAGS(%bp)" > to avoid writing to disk in case of a timeout/default choice; > > This issue is quite well documented in bin/134907 which has been open > since May 2009. > > Reproduced with a fresh nanobsd build: > > Boot 1 - Slice 1 active as set by nanobsd image builder: > > === > # boot0cfg -v ad0 > # flag start chs type end chs offset size > 1 0x80 0: 1: 1 0xa5 494: 15:63 63 498897 > 2 0x00 495: 1: 1 0xa5 989: 15:63 499023 498897 > 3 0x00 990: 0: 1 0xa5 992: 15:63 997920 3024 > > version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) > options=packet,update,nosetdrv > volume serial ID 9090-9090 > default_selection=F1 (Slice 1) > === > > Update the active slice to 2: > === > # boot0cfg -s 2 -v ad0 > # flag start chs type end chs offset size > 1 0x80 0: 1: 1 0xa5 494: 15:63 63 498897 > 2 0x00 495: 1: 1 0xa5 989: 15:63 499023 498897 > 3 0x00 990: 0: 1 0xa5 992: 15:63 997920 3024 > > version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) > options=packet,update,nosetdrv > volume serial ID 9090-9090 > default_selection=F2 (Slice 2) > === what do you get here if you re-run boot0cfg -v ad0 before rebooting ? It seems that boot0cfg does not re-read data from disk so if the write for some reason fails (e.g. kern.geom.debugflags=0) you don't see the actual configuration of the boot sector. Looking at the code there should be an error message if writing to disk fails, but maybe the error reporting oes not work well... > Reboot and let boot0 time out and boot default slice 2: > === > # boot0cfg -v ad0 > # flag start chs type end chs offset size > 1 0x80 0: 1: 1 0xa5 494: 15:63 63 498897 > 2 0x00 495: 1: 1 0xa5 989: 15:63 499023 498897 > 3 0x00 990: 0: 1 0xa5 992: 15:63 997920 3024 > > version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) > options=packet,update,nosetdrv > volume serial ID 9090-9090 > default_selection=F2 (Slice 2) > === > The system actually booted into slice 1 here. What does the system show as Default when it reboots ? F1 or F2 ? This is just to check if the update actually went to disk. > This was verified by dropping to the loader prompt and using show to grab: > loaddev=disk0s1a: > > Reboot and hit 2 at the boot0 prompt: > === > # boot0cfg -v ad0 > # flag start chs type end chs offset size > 1 0x00 0: 1: 1 0xa5 494: 15:63 63 498897 > 2 0x80 495: 1: 1 0xa5 989: 15:63 499023 498897 > 3 0x00 990: 0: 1 0xa5 992: 15:63 997920 3024 > > version=2.0 drive=0x80 mask=0x3 ticks=182 bell=# (0x23) > options=packet,update,nosetdrv > volume serial ID 9090-9090 > default_selection=F2 (Slice 2) > === > > This time we really boot into slice 2. > > The attached patch backs out the relevant part of r186598. > > There was a post on the embedded list that suggested this work around: > echo 'a 2' | fdisk -f /dev/stdin ad0 > boot0cfg -s 2 ad0 > > There are 2 issues with this: > 1) It can't be done without setting kern.geom.debugflags to 0x10. > 2) It resulted in most/all commands resulting in the error message > "Device not configured" including the second command and 'shutdown -r now'. > > Both of which leave this really work around fairly broken. > > > Tom > cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110109183316.GA92631>