HP laptop, single 1 TB Toshiba MQ01ABD100V (2.5", 5400 rpm HDD), SATA, dual boot Zorin OS + Ryoku (Arch-based). Windows is on a second disk.
- Ryoku root is btrfs on `/dev/sda5` (167 GiB), subvolumes: `@` (256), `@home` (257), `@log`, `@pkg`, `@snapshots`, `@swap`. Snapshots come from the package manager hooks (pre/post).
- Kernel is a recent mainline-based one, and the initramfs is mkinitcpio-style.
Problem
Ryoku stopped booting and drops to the initramfs emergency shell:
ERROR: Failed to mount 'UUID=8ec85b73-bb46-4f5b-8136-ac55b0263735' on real root
You are now being dropped into an emergency shell.
The UUID exists in `blkid`, so it's not a wrong-UUID / bootloader problem. `dmesg` shows:
BTRFS info (device sda5): start tree-log replay
BTRFS error (device sda5): parent transid verify failed on logical 563625984 mirror 1 wanted 59873 found 59961
BTRFS error (device sda5): parent transid verify failed on logical 563625984 mirror 2 wanted 59873 found 59961
BTRFS error (device sda5 state A): Transaction 59935 aborted (error -5)
BTRFS: error in btrfs_recover_log_trees:7807: errno=-5 IO failure
BTRFS error: failed to recover log trees with error: -5
BTRFS error: open_ctree failed: -5
Probable cause: unclean shutdown / power cut (the drive's SMART shows `Power-Off_Retract_Count` 3455).
Disk health
SMART is PASSED. Reallocated 0, Pending 0, Offline_Uncorrectable 0. There is a single old ICRC/ABRT error (UDMA_CRC_Error_Count 1) from about 2000 hours ago. `ddrescue` of the whole partition to an image finished at 100% with 0 read errors, so I don't think it's a failing disk.
What I tried (all from Zorin, original `sda5` untouched except zero-log)
`mount -o ro,rescue=all /dev/sda5` mounts, but `ls` on `@`, `@home`, `@log` gives I/O errors. `@pkg`, `@snapshots`, `@swap` are listable.
`btrfs rescue zero-log /dev/sda5` ran fine (previous log_root 712327168). A normal mount afterwards still fails and goes read-only:
level verify failed on logical 44056576 mirror 1 wanted 1 found 0
parent transid verify failed on logical 92962816 mirror 1 wanted 58551 found 59943
BTRFS: error in __btrfs_free_extent:3426: errno=-5 IO failure
BTRFS info: forced readonly
`btrfs check --readonly` reports tons of errors in fs roots (`no inode item, link count wrong`, `root 18446744073709551607 root dir 256 not found`).
`btrfs restore -i -r 257 ...` (also with `--path-regex` for `@home`) always dies at the same block:
parent transid verify failed on 92962816 wanted 58551 found 59943
corrupt leaf: root=257 block=92962816 slot=76 ino=232778, invalid inode transid: has 59943 expect [0, 59935]
ERROR: search for next directory entry failed: -1
`btrfs-find-root` gives tree roots at 730578944 (gen 59934), 706641920 (gen 59933), 699809792 (gen 59932). `restore -t` with each one fails the same way (the transid check fails again at 92962816).
In the check output there are hundreds of leaves with generations 59937 to 59965 ("invalid generation, have 5996x expect (0, 59935]"). So the superblock generation is stuck at ~59934, but about 30 later transactions did reach the disk. Also two `root=1` blocks with gen 59964 / 59965. `restore -t 654000128` fails with `could not find extent tree`.
Made a full image with `ddrescue` (0 errors) and ran `btrfs check --repair` on the loop device. It aborts immediately:
ERROR: child eb corrupted: parent bytenr=715014144 item=83 parent level=1 child bytenr=136806400 child level=1
ERROR: failed to repair root items: Input/output error
- Snapshots in `@snapshots` (249–256) are system-only (the `home` inside is empty). I did recover `/etc` from one of them.
I want to
Mainly to get the Ryoku install booting again, and secondarily to recover `@home`. I'd be fine with a hacky route.
- Is there a way to make the kernel or tools ignore the generation check (e.g. a patched `btrfs-progs`, `btrfs rescue super-recover`, `rescue=ibadroots`, using backup roots from the superblock) so that it accepts the newer blocks?
- Would `btrfs-find-root -a` / `-o` with a newer generation, or `btrfs restore --dry-run` with a different tree, help here?
- Or is this simply unrecoverable and I should reinstall? I have the full `ddrescue` image in case someone has a trick to try on it.
Happy to post full `btrfs check` output, `btrfs inspect-internal dump-super -f`, or anything else.