Solved Can't read MOS of pool rpool - zpool not exported

[gqgunhed]

Hey guys,
I will quickly describe my situation here, that led to a very exciting morning ;-)
This post is intentionally a separate one as the others found here (like https://forums.freebsd.org/threads/cant-read-mos-of-pool-zroot.71517/ or https://forums.freebsd.org/threads/zfs-cant-read-mos-of-pool-rpool.57183/) seem to have another cause.

So the storyline to get things started:

• FreeBSD 12.1-RELEASE server, added current patches with freebsd-update fetch install.
• Server has a ZFS mirrored setup as "rpool".
• Reboot
• During services startup FreeBSD panicked (I have no clue why that happened. Haven't seen that before).
• Stack trace getting written to zpool
• FreeBSD reboots
• I switched to single user mode, checked zpool. Everything looks fine at zpool status.
• So I rebooted
• This lead to the mentioned error of "Can't read MOS of pool rpool"

I searched this forum here but couldn't find a solution for my situation. Cabling, BIOS (of the PC) could see all drives, everything ok and unchanged.

 

[gqgunhed]

I'll skip all the misleading tries and show what helped me to recover:

I used my previous approach (shown here) to geli() attach my disks.
After I got access to my disks I did the following:

• zpool import -o altroot=/tmp/mnt - led to an error that the zpool is already in use.
• Hmm, zpool status shows and verifies that no ZFS pool is in use
• So zpool import -o altroot=/tmp/mnt -f rpool - that forces to import the zpool
• zpool status shows that my ZFS pool is online and healthy, all devices work without errors, everything fine.

Solution (what made the difference):

• zpool export rpool - This was the critical step! By exporting I "freed" the ZFS pool from a previous lock, maybe left behind by the first panic.

After that I was able to reboot as before, unlock my geli disks and the system comes up as if nothing happened.

Hope this will help some others to recover from a ZFS lock, that looks like data loss.