On Fri, 21 Oct 2016 13:39:57 +0200, Patrick M. Hausen wrote:
 > Hi, all,
 > 
 > we are repeatedly bitten by the following misbehaviour of boot0cfg:
 > 
 > root@hd45:/usr/local # boot0cfg -s 1 mirror/m0
 > root@hd45:/usr/local # boot0cfg -v mirror/m0
 > #   flag     start chs   type       end chs       offset         size
 > 1   0x80      1:  0: 1   0xa5   1022:254:63        16065     16418430
 > 2   0x00   1023:  0: 1   0xa5   1020:254:63     16434495     16418430
 > 3   0x00   1021:  0: 1   0xa5    768:254:63     32852925   1920667140
 > 
 > version=1.0  drive=0x80  mask=0xf  ticks=182  bell=  (0x7)
 > options=packet,update,nosetdrv
 > default_selection=F2 (Slice 2)
 > 
 > So, while it should have set the default to slice 1, it simply didn't.

boot0cfg isn't mirror-aware as such and thinks it's using BIOS services 
to write to a specific drive, and likely did write to one of the disks, 
but it seems gmirror isn't updating both disks' MBRs - which might not 
be too surprising.  Does it work 'sometimes'?

 > gpart on the other hand works as expected:
 > 
 > root@hd45:/usr/local # gpart set -a active -i 1 mirror/m0
 > active set on mirror/m0s1
 > root@hd45:/usr/local # gpart show mirror/m0
 > =>        63  1953525104  mirror/m0  MBR  (932G)
 >           63       16002             - free -  (7.8M)
 >        16065    16418430          1  freebsd  [active]  (7.8G)
 >     16434495    16418430          2  freebsd  (7.8G)
 >     32852925  1920667140          3  freebsd  (916G)
 >   1953520065        5102             - free -  (2.5M)
 > 
 > But the "active" flag alone is not enough to convince boot0 to 
 > actually boot that partition.

boot0cfg stashes -s selected nextboot slice (-1) at 0x1b5, using that to 
choose the default boot slice - if nothing else was selected. It doesn't 
set the active flag (0x80) until just before booting via BIOS, when it 
also updates the selection if another slice, or disk, were chosen.

That is, boot0 doesn't care which active flag was set before setting it, 
and gpart doesn't know about non-MBR bytes in the boot sector, so can't 
influence boot0's behaviour.

 > Additional info:
 > 
 > root@hd45:/usr/local # uname -a
 > FreeBSD hd45.hosting.punkt.de 10.3-RELEASE-p10 FreeBSD 10.3-RELEASE-p10 #0 
 > r306942: Mon Oct 10 10:29:14 UTC 2016     
 > root@:/usr/obj/nanobsd.hosting/usr/src/sys/GENERIC  amd64
 > root@hd45:/usr/local # gmirror status
 >      Name    Status  Components
 > mirror/m0  COMPLETE  ada0 (ACTIVE)
 >                      ada1 (ACTIVE)
 > 
 > 
 > The only way to actually switch the boot0 default selection is:
 > 
 > root@hd45:/usr/local # sysctl kern.geom.debugflags=16
 > kern.geom.debugflags: 0 -> 16
 > root@hd45:/usr/local # boot0cfg -s 1 ada0
 > root@hd45:/usr/local # boot0cfg -s 1 ada1
 > root@hd45:/usr/local # boot0cfg -v mirror/m0
 > #   flag     start chs   type       end chs       offset         size
 > 1   0x80      1:  0: 1   0xa5   1022:254:63        16065     16418430
 > 2   0x00   1023:  0: 1   0xa5   1020:254:63     16434495     16418430
 > 3   0x00   1021:  0: 1   0xa5    768:254:63     32852925   1920667140
 > 
 > version=1.0  drive=0x80  mask=0xf  ticks=182  bell=  (0x7)
 > options=packet,update,nosetdrv
 > default_selection=F1 (Slice 1)
 > 
 > 
 > Any hints what's going on, here? Obviously it is possible to manipulate
 > the MBR of a gmirror device - as gpart proves. The boot0cfg pops up
 > since FreeBSD 8 when we started using a mirrored NanoBSD setup.

You might need to script the above, ie setting -s on both disks, unless 
someone who actually knows something about gmirror has a better clue.

cheers, Ian

PS sorry for busted threading, my pine had trouble quoting your message.
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to