m...@petermann-it.de (Matthias Petermann) writes: >wedges at boot time unnecessarily endangers the RAID in the event of a=20 >disk change. Therefore the question: is there a better possibility=20 >besides using the wedges? I remember that I had also tried the variant=20 >with the label NAME=3Dzfs2 when I created it (as it works with newfs, for= >=20 >example), but it didn't work. Ok - as a workaround I could have prepared =
>the disk on another system - for the next time I know that now. One solution is to use devpubd to create symlinks in /dev/wedges, e.g. lrwxr-xr-x 1 root wheel 8 Jul 17 22:03 /dev/wedges/0d2c1666-075f-4a70-bd04-c3f2913fbc80@ -> /dev/dk7 lrwxr-xr-x 1 root wheel 8 Jul 17 22:03 /dev/wedges/41993b4b-180c-4df3-bd6b-25b5cbc036cb@ -> /dev/dk6 The zpool can then be created using these links. For this to work, devpubd needs to run before zfs by changing the start script from # REQUIRE: DAEMON # BEFORE: LOGIN to e.g. # REQUIRE: root # BEFORE: zfs ccd cgd lvm raidframe The devpubd hooks also used commands from /usr, then (with netbsd-9 or older -current) /usr must not be a separate partition. I have updated the hooks in -current to avoid /usr, but for custom hooks that still might be an issue. N.B. recent -current is broken, zfs cannot access such symlinks.