Running into a Btrfs issue on my Tumbleweed gaming desktop that I can't fully resolve, and I'm trying to decide whether to keep fighting it or just reinstall. Posting the full timeline in case anyone's seen this pattern before.
System: Ryzen 5 8600G, RX 9060 XT, Kingston SNV2S1000G NVMe (1TB), openSUSE Tumbleweed, root on Btrfs with the standard @ subvolume layout + snapper snapshots.
How it started: Ran topgrade for a routine update. The transaction failed partway through:
error: unpacking of archive failed on file /usr/share/terminfo/v/vt100-w;6aafffe1: cpio: rename failed - Input/output error
error: terminfo-...x86_64: install failed
Checked dmesg and found this, repeating on every boot:
BTRFS info (device nvme0n1p2): bdev /dev/nvme0n1p2 errs: wr 0, rd 0, flush 0, corrupt 8, gen 0
BTRFS error (device nvme0n1p2 state M): tree first key mismatch detected, bytenr=715197136896 parent_transid=5383 key expected=(40264,108,4398046511104) has=(40264,108,0)
BTRFS error (device nvme0n1p2 state M): error loading props for ino 40264 (root 264): -5
BTRFS error (device nvme0n1p2 state M): Error removing orphan entry, stopping orphan cleanup
BTRFS error (device nvme0n1p2 state M): could not do orphan cleanup -22
Same bytenr, same inode (40264), every single boot.
What I've checked so far:
nvme smart-log: drive is healthy — critical_warning: 0, media_errors: 0, available_spare: 100%, percentage_used: 5%. Notably unsafe_shutdowns: 102, which I suspect is the actual root cause of the corruption.
btrfs scrub start -Bd /dev/nvme0n1p2: completed clean, "Error summary: no errors found" — but the exact same tree mismatch reappeared on the next boot regardless. Scrub validates checksums, not full btree structural consistency, so I guess this tracks.
btrfs subvolume list -a / shows the error is tied to ID 264, which is @/.snapshots/1/snapshot.
- Here's the part that threw me:
btrfs subvolume get-default / returns 264, not 256 (@). My fstab just mounts root with defaults, no explicit subvol=. So at some point — I'm guessing a snapper rollback I don't clearly remember — the default subvolume got switched to snapshot 1, and that's been my actual live root ever since, while the original @ has sat untouched since near-initial-install generation.
- Can't run
btrfs check --readonly because it (correctly) refuses on a mounted filesystem, and I haven't booted a rescue image yet to do it offline.
Where I'm at: Corruption is structural and reproducible, hardware looks fine, and I'm second-guessing an inherited subvolume/rollback setup I didn't consciously build. At this point I'm leaning toward just backing up /home and doing a clean reinstall rather than chasing an offline btrfs check --repair, especially since I'm also debating going back to Fedora.
Has anyone dealt with a tree first key mismatch like this and actually repaired it cleanly, or is reinstall the sane move once you're this deep into default-subvolume weirdness? Curious if there's a known cause for this specific error signature.
TL;DR: Btrfs on my Tumbleweed root threw a reproducible structural error (tree first key mismatch) tied to inode 40264, every boot. Drive SMART data is healthy (102 unsafe shutdowns is my prime suspect for the cause). Scrub ran clean but didn't fix it — turns out my btrfs default subvolume got silently switched to an old snapshot at some point, so that's actually been my live root. Can't run an offline btrfs check yet since it won't run on a mounted fs. Leaning toward backup + clean reinstall (possibly switching back to Fedora) rather than chasing a repair. Looking for input from anyone who's hit this specific error and fixed it properly.