Post Fangtooth upgrade, can't destroy invalid duplicate boot-pool [SOLVED]

OpenZFS TrueNAS
1

I just performed a TrueNAS upgrade via the GUI from 24.10.2.4 (EE) to 25.04.2.6 (FT).

When it rebooted after the upgrade, I’m now getting an error when it tries to import “boot-pool”

It says there are more than one pool named boot-pool and to mount the correct one by ID and then exit. /sbin/zpool import shows both boot-pools (and the data pool). One boot-pool is the proper one and the other looks like so:

  pool: boot-pool
    id: 1885521082526155599
 state: UNAVAIL
status: One or more devices contains corrupted data.
action: The pool cannot be imported due to damaged devices or data.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E
config:

        boot-pool    UNAVAIL  insufficient replicas
          nvme0n1p4  UNAVAIL  invalid label

It is indeed invalid as the partition it’s pointing to is the swap partition. I’m now stuck. I can’t rename it with zpool import because it’s invalid and won’t import and I can’t zpool destroy it using the ID. Obviously I don’t want to destroy it by name because real boot-pool would likely go poof.

I could really use some suggestions.

Thanks in advance
-Pyrroc

2

(post deleted by author)

3

(post deleted by author)

4

Okay… Having slept on it…

Figured I’d boot Ubuntu 24.04 Live Desktop and have a look at the zpools. I should be able to import the good boot-pool renamed to temp, nuke the bad boot-pool, export temp, import temp renamed as boot-pool, then export boot-pool. Easy peasy.

Ubuntu 24.04 doesn’t show the ghost pool… D’oh.

Hmm, maybe it’s a newer openzfs thing. Grab Ubuntu 25.10 Live Desktop, boot that. Ah-ha! There it is. Import the good boot-pool by ID renamed to temp. zpool destroy -f boot-pool.

zpool destroy -f boot-pool
cannot open 'boot-pool': no such pool

but zpool import still shows my gremlin of a pool… Grrr.

So now I targeted ‘zpool destroy “no such pool”’ in Google… and found on a FreeBSD forum thread, the last post, last sentence: “When worse comes to worst you can always look into the labelclear option.”

I researched the labelclear option. It was pretty nuclear, but since I knew the partition referenced by the ghost pool was truly a Linux swap partition, I did a:

zpool labelclear -f nvme0n1p4

and magically it was gone. YAY!