Failed to mount /dev/mapper/root on real root: fixing btrfs “parent transid verify failed”

I sat down in the morning and VMware Workstation was not running, as if the PC had restarted overnight. It had. I started my Omarchy VM, typed the disk encryption password, and instead of the desktop I got this:

ERROR: Failed to mount '/dev/mapper/root' on real root
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
[rootfs ~]#

Applies to: any Linux with a btrfs root filesystem. Mine was Arch Linux (Omarchy) with LUKS full-disk encryption, running as a VMware Workstation VM on a Windows host. Every command below runs at the emergency shell prompt as root, unless it says otherwise.

What is going on

The [rootfs ~]# prompt is the initramfs, the small system that runs before your real one. Its job is to unlock the disk and mount your root filesystem. It got the first part done: /dev/mapper/root only exists after the LUKS unlock succeeds. It failed at the second part.

So this is not a password or encryption problem. Something is wrong with the filesystem itself, or with the initramfs’s ability to read it. The kernel log tells you which.

Diagnosis

1. Read the kernel log

dmesg | tail -30

The lines that mattered:

BTRFS error (device dm-0): parent transid verify failed on logical 35523330048 mirror 1 wanted 11509 found 11514
BTRFS error (device dm-0): parent transid verify failed on logical 35523330048 mirror 2 wanted 11509 found 11514
BTRFS warning (device dm-0): couldn't read tree root
BTRFS error (device dm-0): open_ctree failed: -EIO

Every btrfs write carries a generation number (the transid). The superblock, the record btrfs reads first, said the tree root should be generation 11509. The block on disk was generation 11514. Btrfs refuses to trust a tree that does not match, so the mount fails.

If instead you see nothing from BTRFS, or a message about an unknown filesystem type, the problem is the initramfs (usually a kernel update that did not rebuild it), not the filesystem. That is a different fix.

2. Try the backup tree roots, read only

Btrfs keeps a few older copies of the tree root. This mount changes nothing on disk:

mount -t btrfs -o ro,rescue=usebackuproot /dev/mapper/root /new_root && ls /new_root

Mine failed with can't read superblock, and dmesg showed every backup slot failing the same way:

Root	Wanted	Found
Primary	11509	11514
Backup slot 1	11508	11512
Backup slot 2	level verify failed
Backup slot 3	11507	11513

Look at the pattern. Every tree block on disk is newer than the superblock expects. The data kept being written. What got lost was the superblock update that should have recorded it.

3. Compare the superblock copies

Btrfs keeps mirrors of the superblock at fixed offsets: 64 KiB, 64 MiB and 256 GiB (the last only exists on disks larger than that). This command only reads:

btrfs inspect-internal dump-super -a /dev/mapper/root | grep -E '^superblock|^generation'

superblock: bytenr=65536, device=/dev/mapper/root
generation      11509
superblock: bytenr=67108864, device=/dev/mapper/root
generation      11515

The mirror at 64 MiB was at generation 11515, newer than every tree block on disk. That copy was written; the primary was not.

Root cause

Windows Update restarted the host at 2:25 in the morning. A host restart closes VMware Workstation, and a running VM does not get a clean shutdown: from the guest’s point of view, somebody pulled the power cord. The VM’s own log confirms it. The last boot simply stops at 2:25, with no shutdown messages at all.

The power was cut in the middle of a btrfs commit. The tree blocks and the superblock mirror made it to disk; the primary superblock write did not. Btrfs is designed to survive a crash, but it relies on the storage honouring write ordering and cache flushes, and virtual disks and consumer drives with write caching do not always do that.

The filesystem was not destroyed. It had a stale pointer at its front door and a good one 64 MiB in.

The fix

Before you touch it: snapshot the VM, or image the disk on physical hardware. The next step writes to the disk. And do not run btrfs check --repair: on transid errors it can make the damage worse, and the btrfs documentation says to use it only as a last resort, on advice.

Copy the good superblock mirror back over the primary:

btrfs rescue super-recover -v /dev/mapper/root

It lists the good and bad superblocks and asks whether to restore. Answer y.

That was all it took. The next boot unlocked the disk and mounted the root filesystem normally, at generation 11516: one past the mirror’s 11515, so btrfs had picked up exactly where the good superblock left off.

Verification

From the emergency shell, mount it read-write and look at the top level:

mount -t btrfs /dev/mapper/root /new_root && ls /new_root

On Omarchy you should see the subvolumes, such as @, @home, @log and @pkg. Then:

umount /new_root
reboot -f

Once the system is up, check the rest of the disk. A scrub reads every block and checks it against its checksum; the stats show the error counters:

sudo btrfs scrub start -B /
sudo btrfs device stats /

Files that were being written at the moment the power went can still be damaged after the filesystem mounts. The scrub is how you find them. If it names a file, restore that file from a backup or let the program that owns it rebuild it.

Stop it happening again

• Set Active hours on the host. Settings, Windows Update, Advanced options, Active hours. Windows will not restart automatically inside that window, so set it to cover when the VM usually runs.
• Restart the host on your own terms. When Windows Update says a restart is required, shut the guest down from inside first, then restart Windows.
• Shut the guest down from inside, rather than powering it off from VMware, whenever you are done with it for the day.
• Keep your work in git. Everything I cared about was pushed to GitHub, so the worst case here was a rebuilt VM, not lost work.

Notes

• Confirm the host restart. On the Windows host, Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074} -MaxEvents 5 | Format-List TimeCreated, Message lists recent restarts and who asked for them. Once the VM is back, journalctl -b -1 -n 20 shows how its previous boot ended.
• Typos are easy at this prompt. The shell has no tab completion and no history worth having. /dev/mappter/root gives special device ... does not exist, which looks like a new problem and is not.
• A btrfs check with no device does nothing. It prints exactly 1 argument expected, 0 given and exits, so an accidental btrfs check --repair on its own has not touched your disk.
• If every superblock copy shows the same generation as the primary, super-recover has nothing better to copy. Stop trying to repair and get the data off first: mount -o ro,rescue=all on the device, or btrfs restore to another disk.
• The boot that fails into the emergency shell leaves no log behind, because the disk it would have written to was never mounted. The evidence is on either side of it.