On 2009-02-13 16:01, John Baldwin wrote: >>> Any chance you might have both GEOM_MBR and GEOM_PART_MBR in your >>> kernel configuration? >> I have both GEOM_PART_GPT and GEOM_MBR, but not GEOM_PART_MBR. > Since GEOM_PART_MBR is in DEFAULTS you effectively do have both of them in > there, however. Hmm, on my -CURRENT test box, I get this problem with duplicated /dev entries when I kldload GEOM_BSD (while GEOM_PART_BSD is already statically linked into the kernel). It seems GEOM_MBR isn't even needed: $ ls -l /dev/ad0* crw-r----- 1 root operator 0, 81 Feb 13 17:05 /dev/ad0 crw-r----- 1 root operator 0, 84 Feb 13 17:05 /dev/ad0a crw-r----- 1 root operator 0, 84 Feb 13 17:05 /dev/ad0a crw-r----- 1 root operator 0, 92 Feb 13 17:09 /dev/ad0aa crw-r----- 1 root operator 0, 93 Feb 13 17:09 /dev/ad0ab crw-r----- 1 root operator 0, 94 Feb 13 17:09 /dev/ad0ac crw-r----- 1 root operator 0, 85 Feb 13 17:05 /dev/ad0b crw-r----- 1 root operator 0, 85 Feb 13 17:05 /dev/ad0b crw-r----- 1 root operator 0, 97 Feb 13 17:09 /dev/ad0c Especially the ad0a[a-c] entries are funny, it seems to find a disklabel within a disklabel. :) Probably each of the geom modules registers the device(s) it found with devd, causing nodes to appear in devfs. Maybe these geom modules could be exclusionary, e.g. GEOM_PART_BSD should refuse to load, if GEOM_BSD is loaded, and vice versa? (And possibly the same for GEOM_PART_MBR and GEOM_MBR.)Received on Fri Feb 13 2009 - 15:13:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:42 UTC