Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 08 Jan 2023 20:36:11 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 268830] After 12.3 to 13.1 upgrade, failed to mount zfs filesystems
Message-ID:  <bug-268830-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268830

            Bug ID: 268830
           Summary: After 12.3 to 13.1 upgrade, failed to mount zfs
                    filesystems
           Product: Base System
           Version: 13.1-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: leif@ofWilsonCreek.com

13.1 (and possibly 13.0) appears unable to mount a filesystem by the name of
"tank/.". My pattern has been to set mountpoint=3D/ and canmount=3Doff 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 set=
ting
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 b=
e a
path to recovery, short of using 12.3 boot media; that is, `zfs rename` nee=
ds
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, su=
ch
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=20
  # 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 figu=
red
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=3D/ tank/.
  cannot open 'tank/.': self reference, '.' is found in name

My only recourse appears to be booting 12.3 media and renaming the filesyst=
em.
Happily I was able to rename it using 12.3 and set the explicit mountpoint
without rollback or other hassle.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-268830-227>