TL;DR:

After converting a 2-device mirror pool from btrfs to ZFS (and upgrading to 7.2.7), the pool came up Unmountable: wrong or no file system on the first reboot. Root cause: both SSDs had lost their entire partition table, so sdX1 never appeared and ZFS couldn't find its labels, but every byte of data was intact. Fix was to rebuild the partition table at the exact original offset. Pool imported ONLINE, scrub clean, zero data loss. Posting in case it helps the next person, and to ask whether this is a known conversion/upgrade edge case.

Environment

• Unraid 7.2.7 (kernel 6.12.90), ZFS 2.3.4 (upgrading from 7.2.0)

• Pool transfer: 2x Samsung 870 EVO 1TB, ZFS mirror, recently converted from btrfs

• First boot since the btrfs->zfs conversion

Symptom

GUI showed the pool device as Unmountable: wrong or no file system (fs type zfs). Syslog on array start:

emhttpd: /usr/sbin/zpool import -f -m -N -o autoexpand=on (null) POOL-GUID transfer
emhttpd: shcmd (155): exit status: 2
emhttpd: transfer: mount error: wrong or no file system

Diagnosis (all read-only)

zpool import # state UNAVAIL, "insufficient replicas", both devices "invalid label"
zdb -l /dev/sdX # labels 0/1 "failed to unpack"; labels 2/3 present but "Bad label cksum"
blkid /dev/sdX # TYPE="zfs_member" on the WHOLE DISK - not on a partition
lsblk /dev/sdX # no sdX1 child partition at all
gdisk -l /dev/sdX # "MBR: not present / GPT: not present" - no partition table, no backup GPT

The giveaway: zdb showed the pool member was a partition (path: '/dev/sdX1', whole_disk: 0), but there was no partition table, so the kernel never created sdX1. ZFS labels were being read off the whole disk at the wrong offsets (front labels missing, end labels checksum-mismatched). The data was sitting there untouched, just no longer addressable as a partition. It only broke on reboot because the running kernel had held the partition layout in memory until then.

Step 1 — find the original partition start (read-only)

ZFS label L0 sits at the exact partition start, and its checksum only validates when read at the true offset. I didnt know the correct partition start, so looped over candidate start sectors, dd 256 KiB into a temp file, and zdb -l it:

for S in 34 64 128 256 1024 2048 4096; do
dd if=/dev/sdX bs=512 skip=$S count=512 of=/tmp/l0 2>/dev/null
echo "sector $S:"; zdb -l /tmp/l0 2>&1 | grep -E "name:|Bad label|failed"
done

A clean name: '<pool>' with no "Bad label cksum" = the real start sector. Mine was 2048. Then confirm the table format from a healthy drive (sgdisk -p /dev/<good-disk>) so the rebuild matches — GPT vs MBR, type code, and the last-usable sector (from gdisk -l).

Step 2 — rebuild the partition (one mirror half first)

#start = sector you found; end = last usable sector from gdisk -l

sgdisk -n 1:2048:1953525134 -t 1:8300 /dev/sdX
partprobe /dev/sdX
zdb -l /dev/sdX1 # want: labels = 0 1 2 3

Step 3 — read-only import to verify the data, then export

zpool import -o readonly=on -R /mnt/verify -f transfer
zpool status transfer # DEGRADED (one half) but "No known data errors"
zfs list -r transfer # datasets + used space all present
zpool export transfer

Step 4 — repeat on the second disk, import the full mirror, hand back to Unraid

sgdisk -n 1:2048:1953525134 -t 1:8300 /dev/sdY
partprobe /dev/sdY
zdb -l /dev/sdY1
zpool import -o readonly=on -R /mnt/verify -f transfer
zpool status transfer # both devices ONLINE, state ONLINE, no errors
zpool export transfer

Then Stop/Start the array so Unraid imports it normally, and run a scrub.

Critical cautions

• Do NOT click Format on the unmountable device — that's the one button that turns this into real data loss.

• Import read-only first (-o readonly=on -R /mnt/verify) and verify your data before anything writes.

• On a mirror, rebuild and verify one disk before touching the second, so you always keep one untouched intact copy.

• The sector numbers above are specific to a 1 TB 870 EVO — find your own with the probe and gdisk -l. Recreating the GPT only writes the first/last few sectors; it does not touch the data region at 2048+.

Resolution (confirmed)

• Pool imported ONLINE, both mirror halves, mounted at /mnt/transfer.

• Scrub completed in 00:10:21 with 0B repaired, 0 errors — every block verified across the mirror.

• Rebuilt partitions are real on-disk GPTs, so they persist across reboots.

• Net data loss: none.

Open question for the community

What in the btrfs->zfs conversion (or the 7.2.x upgrade) leaves pool devices with no on-disk partition table, surfacing only on the next reboot?

Edited June 1Jun 1 by ctrlbreak

10 hours ago, ctrlbreak said:

What in the btrfs->zfs conversion (or the 7.2.x upgrade) leaves pool devices with no on-disk partition table, surfacing only on the next reboot?

This should not happen, possibly an issue with the devices, or they were busy. Would need the diags to see.

Yeah, I don't have diags from the time unfortunately :(.

I did a clean restart from the web UI following the upgrade, which seemed to complete successfully. Those log line excerpts were from trying to bring up the transfer zfs pool after that restart. It's odd that there were no partition tables on the drives at all. I wonder if the original conversion from BTRFS to ZFS somehow never wrote them properly but they were in memory/kernel somehow? Don't know enough about ZFS to really understand...

Anyway, maybe not useful in general, but thought I'd post my experience - especially as I was able to recover the data rather than have to reformat.