zfs root snapshot not found after updating to zfs 2.2.6

[MangoIV]

Describe the bug

my blank snapshot that I roll back to at every boot is not found after switching to zfs 2.2.6 - I have confirmed it is neither the kernel nor the disko / impermanence version causing this.

we boot successfully but we get some issues later for e.g. mounting changes permanent datasets

i have tried with kernels 6.10 and 6.6

Expected behavior

zfs successfully rolls back to blank snapshot

Additional context

something else I don't know if it's supposed to happen is that it fails to find the blank snapshot before prompting for decryption - afaiu this should be part of the same pool

my disk config can be found here:

https://git.mangoiv.com/mangoiv/dotfiles/src/branch/main/modules/nixos/p14/disko.nix

Notify maintainers

@amarshall

---

Add a 👍 reaction to issues you find important.

[MangoIV]

the file descriptor error is "file descriptor leaked on lvm invocation" and it does that for a couple of different numbers...

[amarshall]

This doesn’t appear to be related to the ZFS upgrade, as it still occurs when reverting to 2.2.5. I can repro this, but I’m trying to make a VM test repro so I can iterate and bisect without having to deal with real hardware.

[amarshall]

The culprit here appears to be #208037, as that moved zpool import to postResumeCommands. Changing the snapshot rollback to happen there instead of in postDeviceCommands resolves the issue.

I’m trying to figure out if there are any ill effects from that, but initially I don’t think so.

[MangoIV]

thank you ~ I must have somehow missed this commit, I could not find any commits otherwise related to this so I assumed it must have been 2.2.6 since I tried it out with different kernels etc.

[MangoIV]

that fixed the part where it cannot find the blank snapshot but it still says "leaked file descriptor in lvm invocation"

[amarshall]

Yea I believe that’s a totally separate issue. There was an LVM package update that may be relevant, but LVM causes a near-mass-rebuild so testing a revert would take some time to build.

[MangoIV]

woof ~ I guess I got really unlucky :P

[amarshall]

Well, I don’t think it actually causes any problems—are you seeing any?

Also you may wish to consider switching to initrd.systemd.enable = true that may make the rollback more reliably ordered in the boot process (see also this thread for some guidance on specifying the unit).

[amarshall]

Release notes were updated to mention the backwards incompatibility in #346247. As such, closing, feel free to reopen if you believe this is in error.

[MangoIV]

Thank you.