Re: boot0cfg on does not set default selection on gmirror device

2016-10-24 Thread Patrick M. Hausen 
Hi, all,

> Am 24.10.2016 um 04:50 schrieb Ian Smith :
> 
> On Sun, 23 Oct 2016 15:53:59 +0200, Patrick M. Hausen wrote:
> 
>> Actual reboot of this production machine in two weeks when we run our
>> regular updates. But I expect that to "just work".
> 
> Warner expected the existing boot0cfg code to "just work" too.  And it 
> does, except that the upgrades to it failed to include a method to fix 
> existing installations retrospectively!

If the boot0 code 2.0 was severely broken, don't you think we would
have noticed? ;-)

One more thing, I just checked: the machines for which it did work
all the time are indeed younger and all have the 2.0 bootcode.

Thanks for your help.
Patrick
-- 
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de   http://www.punkt.de
Gf: Jürgen Egeling  AG Mannheim 108285

___
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"

Re: boot0cfg on does not set default selection on gmirror device

2016-10-23 Thread Ian Smith 
On Sun, 23 Oct 2016 15:53:59 +0200, Patrick M. Hausen wrote:
 > > Am 22.10.2016 um 05:36 schrieb Ian Smith :
 > > [...]
 > > I wonder two things:
 > > 
 > > Do 'boot0cfg -v ada0' and 'boot0cfg -v ada1' both report the same?

Summary: yes, both equally wrong!

 > > Might it work properly if you upgraded the boot sectors to version 2, 
 > > which is what you should get if you reinstall from current boot0cfg, 
 > > presumably without touching the MBR data, but you'll have backups ..
 > 
 > Well ...
 > 
 > root@hd45:~ # boot0cfg -B mirror/m0
 > root@hd45:~ # boot0cfg -s 2 mirror/m0
 > root@hd45:~ # boot0cfg -v mirror/m0
 > #   flag start chs   type   end chs   offset size
 > 1   0x80  1:  0: 1   0xa5   1022:254:6316065 16418430
 > 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
 > 3   0x00   1021:  0: 1   0xa5768:254:63 32852925   1920667140
 > 
 > version=2.0  drive=0x80  mask=0xf  ticks=182  bell=# (0x23)
 > options=packet,update,nosetdrv
 > volume serial ID b100-808f
 > default_selection=F2 (Slice 2)
 > 
 > root@hd45:~ # boot0cfg -v ada0
 > [...]
 > default_selection=F2 (Slice 2)
 > 
 > root@hd45:~ # boot0cfg -v ada1
 > [...]
 > default_selection=F2 (Slice 2)
 > 
 > Revert the change:
 > 
 > root@hd45:~ # boot0cfg -s 1 mirror/m0
 > root@hd45:~ # boot0cfg -v  mirror/m0
 > [...]
 > default_selection=F1 (Slice 1)
 > 
 > 
 > That did it! These machines have been in production for some time
 > starting with FreeBSD 8.x and have been upgraded via NanoBSD style
 > dd followed by reboot all the time up to 10.3, now. Hence I never touched
 > the bootcode.

Glad that one of my wild ill-informed wonderings was on target, and that 
gmirror is off the hook.

 > Actual reboot of this production machine in two weeks when we run our
 > regular updates. But I expect that to "just work".

Warner expected the existing boot0cfg code to "just work" too.  And it 
does, except that the upgrades to it failed to include a method to fix 
existing installations retrospectively!

cheers, Ian
___
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"

Re: boot0cfg on does not set default selection on gmirror device

2016-10-23 Thread Patrick M. Hausen 
Hi, Ian,

> Am 22.10.2016 um 05:36 schrieb Ian Smith :
> [...]
> I wonder two things:
> 
> Do 'boot0cfg -v ada0' and 'boot0cfg -v ada1' both report the same?

OK, situation before I try to change anything:

root@hd45:~ # boot0cfg -v mirror/m0
[...]
default_selection=F1 (Slice 1)

root@hd45:~ # boot0cfg -v ada0
[...]
default_selection=F1 (Slice 1)

root@hd45:~ # boot0cfg -v ada1
[...]
default_selection=F1 (Slice 1)


Now try to change it to F2 through the mirror device:

root@hd45:~ # boot0cfg -s 2 mirror/m0
# No error message or other indication that something went wrong!

root@hd45:~ # boot0cfg -v mirror/m0
[...]
default_selection=F1 (Slice 1)

root@hd45:~ # boot0cfg -v ada0
[...]
default_selection=F1 (Slice 1)

root@hd45:~ # boot0cfg -v ada1
[...]
default_selection=F1 (Slice 1)


> Might it work properly if you upgraded the boot sectors to version 2, 
> which is what you should get if you reinstall from current boot0cfg, 
> presumably without touching the MBR data, but you'll have backups ..

Well ...

root@hd45:~ # boot0cfg -B mirror/m0
root@hd45:~ # boot0cfg -s 2 mirror/m0
root@hd45:~ # boot0cfg -v mirror/m0
#   flag start chs   type   end chs   offset size
1   0x80  1:  0: 1   0xa5   1022:254:6316065 16418430
2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
3   0x00   1021:  0: 1   0xa5768:254:63 32852925   1920667140

version=2.0  drive=0x80  mask=0xf  ticks=182  bell=# (0x23)
options=packet,update,nosetdrv
volume serial ID b100-808f
default_selection=F2 (Slice 2)

root@hd45:~ # boot0cfg -v ada0
[...]
default_selection=F2 (Slice 2)

root@hd45:~ # boot0cfg -v ada1
[...]
default_selection=F2 (Slice 2)

Revert the change:

root@hd45:~ # boot0cfg -s 1 mirror/m0
root@hd45:~ # boot0cfg -v  mirror/m0
[...]
default_selection=F1 (Slice 1)


That did it! These machines have been in production for some time
starting with FreeBSD 8.x and have been upgraded via NanoBSD style
dd followed by reboot all the time up to 10.3, now. Hence I never touched
the bootcode.

Actual reboot of this production machine in two weeks when we run our
regular updates. But I expect that to "just work".

Patrick
-- 
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de   http://www.punkt.de
Gf: Jürgen Egeling  AG Mannheim 108285

___
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"

Re: boot0cfg on does not set default selection on gmirror device

2016-10-21 Thread Ian Smith 
On Fri, 21 Oct 2016 20:47:20 +0200, Patrick M. Hausen wrote:

Again, trouble quoting your message properly, so quotes by hand ..

 > I set the flag, then tried to change the slice from 1 to 2.
 > Result:
[..]
 > root@hd45:~ # boot0cfg -v mirror/m0
 > #   flag start chs   type   end chs   offset size
 > 1   0x80  1:  0: 1   0xa5   1022:254:6316065 16418430
 > 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
 > 3   0x00   1021:  0: 1   0xa5768:254:63 32852925   1920667140
 >
 > version=1.0  drive=0x80  mask=0xf  ticks=182  bell=  (0x7)
 > options=packet,update,nosetdrv
 > default_selection=F1 (Slice 1)
 >
 > So again, no change.

In my previous message I said that the boot selection would be stored in 
0x1b5.  That was ASSuming we'd be looking at a version=2.0 boot0, which 
from the above is not the case.  For version=1.0 that byte is at 0x1b9.

Discombobulating the dump:

0x1b0: 66 bb 44 72 69 76 65 20 b1 01 80 8f b6 00 80 00
  v2  v1 ^active
0x1c0: 01 01 a5 fe ff fe c1 3e 00 00 7e 86 fa 00 00 00
0x1d0: c1 ff a5 fe ff fc 3f c5 fa 00 7e 86 fa 00 00 00
0x1e0: c1 fd a5 fe ff 00 bd 4b f5 01 04 0e 7b 72 00 00
0x1f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa

So 0x1b9 = 1, +1 = 2 (for F2).  It appears correct in the dump but not 
in what boot0cfg then reports.

I wonder two things:

 Do 'boot0cfg -v ada0' and 'boot0cfg -v ada1' both report the same?

 Might it work properly if you upgraded the boot sectors to version 2, 
which is what you should get if you reinstall from current boot0cfg, 
presumably without touching the MBR data, but you'll have backups ..

Only noticing because I made a memstick with boot0 the other day from 
FreeBSD 9.3 and it showed version=2.0 with a (dummy) volume serial ID, 
the same time as finding that setting active with gpart had no effect.

cheers, ian
___
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"

Re: boot0cfg on does not set default selection on gmirror device

2016-10-21 Thread Patrick M. Hausen 
Hi, Warner,

> Am 21.10.2016 um 20:25 schrieb Warner Losh :
> Can you give us the strace output?

amd64 - no strace. I need a hand here, what precisely do I need to enter?

> It looks like it is reading the current blocks, setting the options,
> and then writing it back to the device. If the write back fails, it
> opens the device with geom and sends either the bootcode verb to geom
> (for the PART (aka gpart)) case or the data for the MBR case. strace
> should show that clearly. There's nothing in dmesg, right? Try this
> again but set geom.debug_flags to 128 instead of 16. This will give a
> verbose error in dmesg if there's any errors from the control message.

I set the flag, then tried to change the slice from 1 to 2.
Result:

Dump of gctl request at 0xfe02392bd9e0:
  param:"class" [R5] = "PART"
  param:"arg0" [R10] = "mirror/m0"
  param:"verb" [R9] = "bootcode"
  param:"bootcode" [R512] =  fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c 89 e6 
bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab fe 45 f2 e9 00 8a f6 46 bb 20 75 08 
84 d2 78 07 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 07 31 d2 88 6f fc 
0f a3 56 bb 73 19 8a 07 bf 87 07 b1 03 f2 ae 74 0e b1 0b f2 ae 83 c7 09 8a 0d 
01 cf e8 c5 00 42 80 c3 10 73 d8 58 2c 7f 3a 06 75 04 72 05 48 74 0d 30 c0 04 
b0 88 46 b8 bf b2 07 e8 a6 00 be 7b 07 e8 b2 00 8a 56 b9 4e e8 8e 00 eb 05 b0 
07 e8 b0 00 30 e4 cd 1a 89 d7 03 7e bc b4 01 cd 16 75 0d 30 e4 cd 1a 39 fa 72 
f2 8a 46 b9 eb 16 30 e4 cd 16 88 e0 3c 1c 74 f1 2c 3b 3c 04 76 06 2c c7 3c 04 
77 c9 98 0f a3 46 0c 73 c2 88 46 b9 be 00 08 8a 14 89 f3 3c 04 9c 74 0a c0 e0 
04 05 be 07 93 c6 07 80 53 f6 46 bb 40 75 08 bb 00 06 b4 03 e8 59 00 5e 9d 75 
06 8a 56 b8 80 ea 30 bb 00 7c b4 02 e8 47 00 72 86 81 bf fe 01 55 aa 0f 85 7c 
ff be 85 07 e8 19 00 ff e3 b0 46 e8 24 00 b0 31 00 d0 eb 17 0f ab 56 0c be 78 
07 e8 eb ff 89 fe e8 03 00 be 85 07 ac a8 80 75 05 e8 04 00 eb f6 24 7f 53 bb 
07 00 b4 0e cd 10 5b c3 8a 74 01 8b 4c 02 b0 01 56 89 e7 f6 46 bb 80 74 13 66 
6a 00 66 ff 74 08 06 53 6a 01 6a 10 89 e6 48 80 cc 40 cd 13 89 fc 5e c3 20 20 
a0 0a 44 65 66 61 75 6c 74 3a a0 0d 8a 00 05 0f 01 06 07 0b 0c 0e 83 a5 a6 a9 
0d 0c 0b 0a 09 08 0a 0e 11 10 01 3f bf 44 4f d3 4c 69 6e 75 f8 46 72 65 65 42 
53 c4 66 bb 44 72 69 76 65 20 b1 01 80 8f b6 00 80 00 01 01 a5 fe ff fe c1 3e 
00 00 7e 86 fa 00 00 00 c1 ff a5 fe ff fc 3f c5 fa 00 7e 86 fa 00 00 00 c1 fd 
a5 fe ff 00 bd 4b f5 01 04 0e 7b 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 55 aa
  param:"flags" [R2] = "C"

root@hd45:~ # boot0cfg -v mirror/m0
#   flag start chs   type   end chs   offset size
1   0x80  1:  0: 1   0xa5   1022:254:6316065 16418430
2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
3   0x00   1021:  0: 1   0xa5768:254:63 32852925   1920667140

version=1.0  drive=0x80  mask=0xf  ticks=182  bell=  (0x7)
options=packet,update,nosetdrv
default_selection=F1 (Slice 1)

So again, no change.

Thanks,
Patrick
-- 
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de   http://www.punkt.de
Gf: Jürgen Egeling  AG Mannheim 108285

___
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"

Re: boot0cfg on does not set default selection on gmirror device

2016-10-21 Thread Warner Losh 
On Fri, Oct 21, 2016 at 11:57 AM, Patrick M. Hausen  wrote:
> Hi, all,
>
>> Am 21.10.2016 um 16:41 schrieb Warner Losh :
>> Any chance you can migrate to using gpart? Is boot0cfg still
>> referenced in NanoBSD somewhere?
>
> Not in NanoBSD but how would you configure boot0's default
> slice with gpart? It doesn't pay attention to the "active" flag.
> See Miroslav's mails for all the details.
>
> gpart would only be an option if we did not use the FreeBSD
> boot manager.

Ah! OK, I thought this was the active flag issue, not the default in
boot0 issue.

> But we need the "F1 ..., F2 ..." prompt, because
> being able to roll back to the last known-good system via the
> console is the entire point of using this NanoBSD setup.
> There's a presentation on the EuroBSDCon 2010 page about
> motivation and setup. Wonder who did that talk ... :-)))

I think I sat in the talk :)

> BTW: thanks, Miroslav. As for your question: it does work on
> the only two systems that use hardware RAID, yet have a
> gmirror built of only a single component to get consistent
> device names accross all servers.
>
> I'm not quite sure if it works from time to time, I've come to
> accept the "kern.geom.debugflags" dance.
>
> I had opened a similar discussion years ago for 7.x/8.x and
> I was told that geom was to provide an API for fdisk, boot0cfg
> and friends to manipulate the MBR. Because back in the days
> boot0cfg and fdisk both threw an error message when trying
> to work on a whole-disk mirror.

It certainly looks like this code has that conversion in it. Looks
like it's been there quite a while. I'd have expected it to "JUST
WORK" [tm].

> I thought that was long solved - at least no error, anymore.
> But it's still not working in 10.x.

Can you give us the strace output?

It looks like it is reading the current blocks, setting the options,
and then writing it back to the device. If the write back fails, it
opens the device with geom and sends either the bootcode verb to geom
(for the PART (aka gpart)) case or the data for the MBR case. strace
should show that clearly. There's nothing in dmesg, right? Try this
again but set geom.debug_flags to 128 instead of 16. This will give a
verbose error in dmesg if there's any errors from the control message.

Warner
___
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"

Re: boot0cfg on does not set default selection on gmirror device

2016-10-21 Thread Patrick M. Hausen 
Hi, all,

> Am 21.10.2016 um 16:41 schrieb Warner Losh :
> Any chance you can migrate to using gpart? Is boot0cfg still
> referenced in NanoBSD somewhere?

Not in NanoBSD but how would you configure boot0's default
slice with gpart? It doesn't pay attention to the "active" flag.
See Miroslav's mails for all the details.

gpart would only be an option if we did not use the FreeBSD
boot manager. But we need the "F1 ..., F2 ..." prompt, because
being able to roll back to the last known-good system via the
console is the entire point of using this NanoBSD setup.
There's a presentation on the EuroBSDCon 2010 page about
motivation and setup. Wonder who did that talk ... :-)))

BTW: thanks, Miroslav. As for your question: it does work on
the only two systems that use hardware RAID, yet have a
gmirror built of only a single component to get consistent
device names accross all servers.

I'm not quite sure if it works from time to time, I've come to
accept the "kern.geom.debugflags" dance.

I had opened a similar discussion years ago for 7.x/8.x and
I was told that geom was to provide an API for fdisk, boot0cfg
and friends to manipulate the MBR. Because back in the days
boot0cfg and fdisk both threw an error message when trying
to work on a whole-disk mirror.
I thought that was long solved - at least no error, anymore.
But it's still not working in 10.x.

Thanks to all and take care,
Patrick
-- 
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de   http://www.punkt.de
Gf: Jürgen Egeling  AG Mannheim 108285

___
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"

Re: boot0cfg on does not set default selection on gmirror device

2016-10-21 Thread Miroslav Lachman 

Ian Smith wrote on 2016/10/21 16:43:

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:6316065 16418430
  > 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
  > 3   0x00   1021:  0: 1   0xa5768: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'?


We are using gmirror for whole drives mirroring from the time when it 
was introduced. It was always working with MRB/BSD.


gmirror label gm0 ada0 ada1

And then you can use fdisk + bsdlabel or gpart to create slices and 
partitions and set it bootable on /dev/mirror/gm0.


I didn't tried it with FreeBSD 10.3, but it works with 8.x (we skipped 
9.x and all 8.x boxes were upgraded to 10.2 then 10.3)


Miroslav Lachman
___
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"

Re: boot0cfg on does not set default selection on gmirror device

2016-10-21 Thread Arrigo Marchiori via freebsd-stable 
Hello all,

On Fri, Oct 21, 2016 at 08:41:33AM -0600, Warner Losh wrote:

> On Fri, Oct 21, 2016 at 5:39 AM, 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:6316065 16418430
> > 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
> > 3   0x00   1021:  0: 1   0xa5768: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.
> >
> > 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)
> >1606516418430  1  freebsd  [active]  (7.8G)
> > 1643449516418430  2  freebsd  (7.8G)
> > 32852925  1920667140  3  freebsd  (916G)
> >   19535200655102 - free -  (2.5M)
> >
> > But the "active" flag alone is not enough to convince boot0 to actually 
> > boot that partition.
> >
> > 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
> >  NameStatus  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:6316065 16418430
> > 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
> > 3   0x00   1021:  0: 1   0xa5768: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.
> 
> Any chance you can migrate to using gpart? Is boot0cfg still
> referenced in NanoBSD somewhere?

Ahem... For what it's worth... I cannot help not pointing this old PR
out: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186030

Best regards,
-- 
rigo

http://rigo.altervista.org
___
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"

Re: boot0cfg on does not set default selection on gmirror device

2016-10-21 Thread Ian Smith 
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:6316065 16418430
 > 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
 > 3   0x00   1021:  0: 1   0xa5768: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)
 >1606516418430  1  freebsd  [active]  (7.8G)
 > 1643449516418430  2  freebsd  (7.8G)
 > 32852925  1920667140  3  freebsd  (916G)
 >   19535200655102 - 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
 >  NameStatus  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:6316065 16418430
 > 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
 > 3   0x00   1021:  0: 1   0xa5768: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"

Re: boot0cfg on does not set default selection on gmirror device

2016-10-21 Thread Warner Losh 
On Fri, Oct 21, 2016 at 5:39 AM, 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:6316065 16418430
> 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
> 3   0x00   1021:  0: 1   0xa5768: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.
>
> 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)
>1606516418430  1  freebsd  [active]  (7.8G)
> 1643449516418430  2  freebsd  (7.8G)
> 32852925  1920667140  3  freebsd  (916G)
>   19535200655102 - free -  (2.5M)
>
> But the "active" flag alone is not enough to convince boot0 to actually boot 
> that partition.
>
> 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
>  NameStatus  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:6316065 16418430
> 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
> 3   0x00   1021:  0: 1   0xa5768: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.

Any chance you can migrate to using gpart? Is boot0cfg still
referenced in NanoBSD somewhere?

Warner
___
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"

boot0cfg on does not set default selection on gmirror device

2016-10-21 Thread Patrick M. Hausen 
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:6316065 16418430
2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
3   0x00   1021:  0: 1   0xa5768: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.

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)
   1606516418430  1  freebsd  [active]  (7.8G)
1643449516418430  2  freebsd  (7.8G)
32852925  1920667140  3  freebsd  (916G)
  19535200655102 - free -  (2.5M)

But the "active" flag alone is not enough to convince boot0 to actually boot 
that partition.

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
 NameStatus  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:6316065 16418430
2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
3   0x00   1021:  0: 1   0xa5768: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.


Thanks and kind regards,
Patrick
-- 
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de   http://www.punkt.de
Gf: Jürgen Egeling  AG Mannheim 108285

___
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"