Any workaround for a pool that panics txg_sync after a device removal? (SCALE 25.04.2.6)

TrueNAS General
, ,
1

On 2026-07-25 I ran zpool remove on a top-level data vdev of pool0. Since that day the box panics from txg_sync inside vdev_indirect_mapping_duplicate_adjacent_entries() — NULL dereference, CR2=0x8 — about 230 s after import, as soon as a write touches a block pointer that still references the removed vdev. Reboot loop, ~140 pstore dumps, identical signature across three episodes eight days apart.

Root cause is established and filed upstream with the full trace: openzfs/zfs #18930 (decoded dump). I am not looking to re-litigate the diagnosis here.

Both pools scrub clean — zero read/write/checksum errors, no data errors, ever. Hardware is exonerated: over 21 days I swapped the PSU, bypassed the UPS, ran the box on battery under full galvanic isolation, detached every network cable, and cleared thermals, RAM, C-states, ASPM and the LSI 9300-8i. zfs_condense_indirect_vdevs_enable=0 was verified live on the running boot and panicked anyway at 231 s. So: please, not the cables and not the PSU.

The box is powered off. My question is purely operational — is there a known workaround that makes this pool safe enough to touch, so I can zfs send 16.2 TiB off it?

  1. Read-only import. Does zpool import -o readonly=on reliably keep txg_sync out of the remap path? A send is a pure read on the source side, so if that holds, the problem is solved. And what is the clean way to do it on SCALE without middleware re-importing the pool or fighting the mount?
  2. Booting without importing one pool. Is there a supported way to stop a single pool auto-importing at boot? My only working method is modprobe.blacklist=mpt3sas, which also hides my other pool.
  3. Newer build. Does any later SCALE / OpenZFS ship a fix on the vdev_indirect_remap path? Upgrading beats a 16 TiB migration if one exists.

If the answer is “no workaround, evacuate”, that is fine — drives are budgeted and the plan is ready. I would just rather not spend the weekend on it if there is a known trick.

And out of interest: has anyone else hit a panic after a successful device removal, days later, on an otherwise clean pool?

2

I would install or upgrade to the latest version of TrueNAS, which ships with OpenZFS 2.3.4.

IIRC, version 2.3.4 contains backported fixes related to indirect vdevs. I don’t remember if it fixes preventing the issue in the first place or if it fixes the kernel panic on import, but it’s worth a shot.

Have you recently exported your config file? If you have a recent config file (with the secret seed) you can do a fresh installation of the latest TrueNAS and then import your config.

Try this first before giving up or attempting anything complex. Please make sure your exported config also contains the secret seed.

This has happened before, but it was related to a combination of vdev removal and the usage of block-cloning.

3

Thanks for your response, I looked into 2.3.4, it does carry a preventive indirect-vdev fix — commit 0a73e91d2, “Block remap for cloned blocks on device removal.” Its message describes exactly the obsolete-miscount → premature-free → condense-drop sequence that produces this hole, tied to block cloning. The line that causes the panic is still unguarded in that release tho.

Config is backed up with secrets - I did reinstallation in the past, always worked out. That’s the only area where I feel confident in my abilities :upside_down_face:

So new TrueNAS version is a given for when I rebuild, still need to figure out a way to fix the existing pool. Just zfs send / receive to a new pool likely will run into the same issue for the affected dataset (which I’m trying to identify using RescueOS+zfs).

I thought changing a PSU when everything is wired in a new case was bad…

4

How are you going to send/recv a pool that you cannot import without triggering a kernel panic?

Why not just try to see if you can import the pool on the latest TrueNAS? If it doesn’t work, you can move on to more complex options.

5

You are right, will try that first and report back.

6

That depends on what you’re referring to.

It’s not inherently bad.
It is bad if you try to dodge the chore of replacing a modular PSU:s cables, unless you are 100% sure they are fully compatible.