nanobsd boot slice selection does not work

[Paul Schenkeveld]

On Tue, May 12, 2009 at 02:45:26PM -0400, John Baldwin wrote:
> On Tuesday 12 May 2009 1:15:55 pm Paul Schenkeveld wrote:
> > 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.
> 
> Yes, it is done by boot0.
> 
> > 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.
> 
> Ok, so can you verify if 'update' is enabled for boot0 in the 7.2 case?

Yes (although I'm sure this only influences boot selection thru keyboard
input when booting, not switching thru boot0cfg).

Another strange observation, after a fresh nanobsd build using 7.2R, this
is the output of boot0cfg:

  # boot0cfg -v ad0
  #   flag     start chs   type       end chs       offset         size
  1   0x00      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  bell=# (0x23)
  options=packet,update,nosetdrv
  default_selection=F1 (Slice 1)

Note that none of the slices is marked active.

Switching using boot0cfg yields:

  # boot0cfg -v -s 2 ad0
  #   flag     start chs   type       end chs       offset         size
  1   0x00      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  bell=# (0x23)
  options=packet,update,nosetdrv
  default_selection=F2 (Slice 2)
  #

During reboot, boot0 suggests that slice 2 is default:

   1 Seconds to automatic boot.   Press Ctrl-P for entering Monitor.

   1   FreeBSD
   2   FreeBSD
   5   Drive 1

   Boot:   2

It looks like the kernel on ad0s1a gets loaded however.  To be sure I
upgraded the kernel on ad0s2a with a newer one, still the same behaviour.

To summarize 7.2 boot0 behaviour:

  - Pressing [F]1 or [F]2 at the boot0 prompt selects slice 1 or 2 and
    boots off that slice.  If the update option is on, default_selection
    is set in sector0, the active flage is set on the requested slice
    and cleared from the other slice.

  - Boot0cfg -s N sets default_selection to N and does not affect the
    active flag in MBR record.

  - Boot0 does not look at default_selection at all, the slice marked
    active is booted, if no slice is marked active, slice 1 is booted.

Pressing a key during boot0 is kind of hard if the box is thousends of
kilometers away, boot0 not looking at default_selection seems wrong
because it exists to allow more control than just the active flags can
achive (like defaulting to boor from the second disk.

-- Paul Schenkeveld