a gmirror disappears after adding gjournals to its partitions

[perryh at pluto.rain.com]

CyberLeo Kitsana <cyberleo at cyberleo.net> wrote:
> ... I hope it makes sense!

No problem with the explanation making sense; what I don't follow
is the behavior of bsdlabel.  Given the way I set it up this drive
_should_ contain _two_ labels, but for some unfathomable reason
bsdlabel seems to be using the second (inner) one while ignoring
the first (outer) one entirely.

The device itself is ad0.  Its MBR contains a slice table, defining
ad0s1 and ad0s2.  (ad0s1 is FAT32 and AFAIK need not be considered
further at this point.)

ad0s2 starts with a bsdlabel, which defines ad0s2a and ad0s2b.
(ad0s2b is intended to be used as swap and, like ad0s1, need not be
considered further at this point -- but it _should_ be instantiated
along with ad0s2a.)

ad0s2a is supposed to be the provider for gm0, and it starts with a
bsdlabel that is intended to partition gm0 into gm0[ade], but since
geom_mirror.ko hasn't been loaded yet gm0 doesn't exist and ad0s2a
is just a partition that happens to start with a bsdlabel and end
with gmirror metadata.

I could understand if bsdlabel tasted ad0s2a, found the label, and
(recursively) instantiated ad0s2aa, ad0s2ad, and ad0s2ae; but that
doesn't seem to happen.  Instead, bsdlabel seems to ignore (or
forget) the first label it tasted -- the one on ad0s2 -- and treats
the one on ad0s2a as applying to ad0s2.  We end up with ad0s2a
containing the disk blocks intended for gm0a, ad0s2d containing the
disk blocks intended for gm0d, ad0s2e containing the disk blocks
intended for gm0e; and the blocks intended for ad0s2b (swap) --
which were not supposed to have been involved with any mirror or
journal -- seem to have disappeared entirely.  This seems like a bug.

Now gjournal gets into the act, consuming the phony ad0s2[ade]
before gmirror gets a chance to taste the real ad0s2a and instantiate
gm0.  That explains why gm0 and /dev/mirror are missing, but not why
ad0s2b is missing, nor why we have ad0s2[ade] (and the corresponding
.journal's) rather than ad0s2a[ade] (and their .journal's).

> > (This machine is likely too old to understand GPT.)
>
> The machine's bios does not need to understand GPT to use it on a
> pure data disk; only as a boot disk.

This is, however, intended as a boot disk -- gm0a, gm0d, and gm0e
are supposed to be root, /var, and /usr respectively -- and it does
seem to boot OK until it tries find the root FS (because /etc/fstab
is set up to use gm0[ade].journal instead of ad0s2[ade].journal).

I suppose I could try partitioning ad0s2a with gpt instead of with
bsdlabel, but would the loader still be able to find the kernel?