CyberLeo Kitsana <cyber...@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? _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"