13.1 (and possibly 13.0) appears unable to mount a filesystem by the name of "tank/.". My pattern has been to set mountpoint=/ and canmount=off for tank. Then I create a descendent filesystem called "tank/." and let it inherit the mountpoint. Why? Using "tank" for / is troublesome because it cannot be renamed, and any special properties get inherited by all others (which some would argue is appropriate but I find necessitates override settings on all other filesystems). Having the mountpoint inherit instead of explicitly setting it to / allows such a rename to be performed without a "tripping hazard" of forgetting to update the mountpoint property. I totally understand if there's a new reason this can't be supported. I can endure losing my clever trick. However, I believe there at least needs to be a path to recovery, short of using 12.3 boot media; that is, `zfs rename` needs to work. Everything I could think of post-upgrade has failed. Here are details of what happened. After upgrading from 12.3 to 13.1, the kernel successfully mounted the root filesystem and booted, but rc failed to mount any other ZFS filesystems, such as tank/home. # mount tank/. on / (zfs, local, noatime, nfsv4acls) devfs on /dev (devfs) fdescfs on /dev/fd (fdescfs) procfs on /proc (procfs, local) Baffled as to what was going on, I wondered if the other filesystems were intact: # zfs list internal error: cannot iterate filesystems: Invalid argument Abort trap (core dumped) I was able to mount them explicitly: # zfs mount tank/home # ls /home [correct output, redacted] Wondering if something in the upgrade failed, I tried rollback: # zfs rollback -r tank/.@2023-01-07.12.3-RELEASE-p5 cannot open 'tank/.': self reference, '.' is found in name This thankfully told me the problem with a correct error message, so I figured I needed to rename from my clever name of `tank/.` to something else, but I couldn't: # zfs rename -u tank/. tank/_ cannot open 'tank/.': self reference, '.' is found in name # zfs set mountpoint=/ tank/. cannot open 'tank/.': self reference, '.' is found in name My only recourse appears to be booting 12.3 media and renaming the filesystem. Happily I was able to rename it using 12.3 and set the explicit mountpoint without rollback or other hassle.
Consider this, from <https://openzfs.github.io/openzfs-docs/man/8/zfs.8.html>: [A-Za-z_.:/ -] Was bectl(8) in 12.3 used before the attempted upgrade? <https://www.freebsd.org/cgi/man.cgi?query=bectl&sektion=8&manpath=FreeBSD+12.3-RELEASE>
No, I've never used boot environments...although they look handy.
9c7da9a95aaaecced0a1cfc40190906e7a691327 is probably what's making you sad, if I had to guess, or a side effect of implementing it and assuming it would be true, since that commit postdates 12.0 and thus I would guess you first saw it in 13, since 12.4 doesn't seem to have it. [1] Probably wouldn't be unreasonable to plumb in a special case allowing renaming _from_ these so people aren't stuck on upgrade if they were doing it before, as well as better error reporting... [1] - https://github.com/freebsd/freebsd-src/commits/releng/12.4/sys/cddl/contrib/opensolaris/common/zfs/zfs_namecheck.c
(In reply to Rich Ercolani from comment #3) Thanks for identification. I see <https://www.illumos.org/issues/8254> in illumos. jpaetzel@ please, do you have an opinion on how to proceed here? Historically (casting my mind back to the era of Ten's Complement), I thought it was fairly well-known that a dataset name must begin with an alphanumeric character. <https://docs.oracle.com/cd/E19253-01/819-5461/gbcpt/index.html>, and so on.