zpool export fails with pool is busy

[sempervictus]

System information

Type	Version/Name
Distribution Name	Arch
Distribution Version	Current
Kernel Version	6.6
Architecture	amd64
OpenZFS Version	2.2.7 (built into the kernel binary)

Describe the problem you're observing

A pool atop an encrypted volume residing on a ZVOL always fails to export after upgrading 2.2.7 despite none of its datasets being mounted. Pool is imported with -t as its actual name clashes with an existing pool in the host (rpool):

Describe how to reproduce the problem

1. Decrypt the dm-crypt partition on the ZVOL
2. import the zpool within it using a temporary pool name - -t flag and mount prefix (-R)
3. chroot into the FS, run updates, exit the chroot
4. unmount the datasets mounted during import
5. try to export the pool

Include any warning/errors/backtraces from the system logs

cannot export 'temp-name-pool': pool is busy

[n0xena]

how EXACTLY do you chroot?
from several uses of rescue system I learned that in order to cleanly unmount the temp system the kernel-mounts /dev /sys and so on have to be mounted in a specific way and order - otherwise you wil always end up with something within the mount is still busy
as you given arch as OS: use arch-chroot - it manages all the bind mounts and clean unmount after exit chroot
for opensuse for example this often happens when running yast update which in turn causes the cgroup2 stuff to get mounted which then for some reason are not possible to cleanly unmount again - even when explicitly following https://www.suse.com/de-de/support/kb/doc/?id=000018770
btw: although I'm aware why you use dm-crypt - ZFS was never designed to be stacked inside other containers but with direct full drive access - so although I don't think this is at play here it's not how zfs is supposed to be used

[sempervictus]

Bind mounts are removed on exit, arch wrapper around the manual bind mounting and removal. It can get stuck if gpg daemon locks dev but that is not the case here. There are no holders.

[justinpryzby]

You said "after upgrading to 2.2.7" -- what was the previous version?
Could you check again whether there's an issue with the old version?
This would show whether the problem is related to 2.2.7 itself, or is something else that changed between the last time that you did the chroot stuff, and upgrading zfs.

Please check that there's nothing using the chroot.
sudo ls -l /proc/*/root |grep -v ' -> /$'

Also check /proc/*/mounts, especially for processes started since chrooting.