Kernel oops on zfs create, or later when copying files #13005
Labels
Comments
|
In case it's useful, in userspace I was seeing some stuck processes, which I killed and started again, and it showed me failing to get a lock (probably after the BUG has happened): |
|
Some more: |
|
|
I initially suspected this was the dm-crypt/luks layer in between (had a Produced the following one: I also left a memtest running on this machine over night to rule some hardware issues, which passed (and this machine has ECC RAM) @behlendorf, do you have any idea what's going on here? |
flokli
changed the title
|
On the same box, I created the zpool with an older ZFS version/OS: I was able to proceed the installation, and after that, am now able to use the pool without problems from the more recent system (zfs-2.1.2-1, NixOS, 5.16.2). No kernel OOPses so far.
|
|
I would be surprised if it were the new features, from those stack traces, though you could always bisect between the point where 2.0-rc1 forked from master and 2.1.2. Someone recently came around on IRC with similarly wild stacktraces and pointer dereferences, though theirs happened earlier, and it turned out the underlying issue was they had made some changes to their kernel config and recompiled the kernel, but not the modules, and it went away once they rebuilt the modules against the changed kernel. So I would wonder if a clean rebuild of 2.1.2 against your kernel might make the issues vanish? (I don't think it's incredibly likely unless you know you recently updated it, but the example was too similarly surprising to not mention.) I'll try to think more about this one later, those are just two remarks that came quickly. |
|
I'm super sure the zfs modules were compiled against the same kernel sources as the running kernel. I built the whole system with NixOS, and tried multiple kernel versions, and the corresponding zfs module built against that kernel. Using a mismatching kernel is actually harder ;-)
The only other thing i did do different was that I kexec'ed into those kernel and system images from the rescue image, rather than directly booting from them (but the initially booted kernel didn't touch the disks, and also didn't even have the zfs kernel modules).
The succeeding installation was directly from the rescue system, manually compiling (older) zfs modules (some recent debian with some zfs install script).
|
|
This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
System information
Describe the problem you're observing
Did a NixOS installation, which copies a lot of files around, and failed to get a sqlite database lock.
I poked in dmesg, and was greeted by the following:
Describe how to reproduce the problem
Unsure. Didn't want to immediately reboot, in case you want to further investigate this.
This smells similar to #4608, but contrary to there, the machine is running with ECC ram:
The text was updated successfully, but these errors were encountered: