sys/boot/boot0/boot0.S - r186598

[Luigi Rizzo]

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