Rich Ercolani
Rich Ercolani
You cannot replace the rootfs of a pool, no, that's one reason it's commonly suggested not to use it for storing anything, just as a source for property inheritance. As...
I can try to work up something to forcibly trigger it, but I'm wary of sharing minimally tested patches for encryption issues after a few rounds of attempts...so I guess...
I suppose you could see if a "zfs rollback [latest snapshot]", or "zfs clone [latest snapshot] some/where", or the like might be a terrible workaround - or taking a new...
So, first of all, I have no idea how to try reproducing this from your report - it's extremely disjointed, I have no idea what you changed between situation A...
Is there a message before or after the trace that might be informative about the nature of the problem? Usually Linux prints something about why it's upset when these come...
Nope. Darn, guess it's bisect and spelunking time.
So, I tried this with 5.10.48 and 2.0.5 on Debian bullseye x86_64 (because it's what my testbed was running), and prodding it different ways with various x86_64 (and one sparc64)...
I've not, but particularly with the release of libutp, it doesn't seem infeasible to do.
[sparc64] Encrypted datasets erroring with "Unable to handle kernel NULL pointer dereference errors"
I would suggest treating the encryption code as unmaintained going forward, as that's what it's been the past 3 years.
[sparc64] Encrypted datasets erroring with "Unable to handle kernel NULL pointer dereference errors"
If you're volunteering, I would suggest #11679 and #12614 as the ones that get the most duplicates. I would warn you, though, that the list of unfixed difficulties with it...