SOLVED! (post formerly titled as "BTRFS issue: open_ctree failed; bad tree block start; unmountable"

Help
1

EDIT:
While I was in the middle of writing this post, I was also trying a list of solutions I found on this link:
https://en.opensuse.org/SDB:BTRFS#How_to_repair_a_broken/unmountable_btrfs_filesystem

The solution to my problem was the btrfs rescue zero-log /dev/sda1 method.

I was incredibly skeptical at first, because one solution after the other was not fixing it, until I came across the aforementioned one.

If anyone come across any issues with BTRFS, consider these solutions!
This guide also does an amazing job indicating “warnings” on the solutions as well, especially with the “forbidden” check --repair one, which I hope no one ever has to “roll the dice” on.

I remember doing it once, and it really messes up your drive. I had no idea what I was doing back then…

Hope this helps folks!

Cheers!

I’ve come across this issue a few times; not sure why or how it happens. Usually occurs after running sudo nixos-rebuild switch --upgrade and alike.

Here’s the details:

NVMe SSD; luks2 encrypted btrfs drive.
I usually use it externally via M.2 NVMe drive.

Whenever I try to mount the drive, sudo dmesg shows the following output:

[ 1369.382763] BTRFS: device label @ devid 1 transid 15560 /dev/mapper/luks-71971fba-64ae-4ae3-bfcc-5e45763220c4 (254:1) scanned by mount (8635)
[ 1369.383695] BTRFS info (device dm-1): first mount of filesystem 4c00058d-3dbb-4155-9223-f1255e998ec6
[ 1369.383714] BTRFS info (device dm-1): using crc32c (crc32c-intel) checksum algorithm
[ 1369.383719] BTRFS info (device dm-1): using free-space-tree
[ 1369.559590] BTRFS info (device dm-1): start tree-log replay
[ 1369.559890] BTRFS error (device dm-1): bad tree block start, mirror 1 want 139771904 have 18010944275479632007
[ 1369.560183] BTRFS error (device dm-1): bad tree block start, mirror 2 want 139771904 have 12059563138185019958
[ 1369.560207] BTRFS warning (device dm-1): failed to read log tree
[ 1369.563843] BTRFS error (device dm-1): open_ctree failed

I ran btrfs check to see more details, and got this:

[nprevail@nixos:~]$ sudo btrfs check /dev/mapper/luks-71971fba-64ae-4ae3-bfcc-5e45763220c4
Opening filesystem to check...
checksum verify failed on 139771904 wanted 0xc29506c0 found 0x1bdac36f
checksum verify failed on 139771904 wanted 0x5dacb8de found 0xb7459c97
checksum verify failed on 139771904 wanted 0x5dacb8de found 0xb7459c97
bad tree block 139771904, bytenr mismatch, want=139771904, have=12059563138185019958
Couldn't setup log root tree
ERROR: cannot open file system
3 Likes
2

Adding some info here for future readers because I ran into this problem on a LUKS encrypted drive and it seems that a bug may have been (re)introduced in somewhat recent kernel updates.

My error output was slightly different because I was forced to diagnose via an ISO environment so I’m also adding that here to improve search results for others.

BTRFS: Transaction aborted (error -17)
BTRFS: error (device dm-0 state A) in __btrfs_run_delayed_items:1168: errno=-17 Object already exists
BTRFS: error (device dm-0 state EA) in btrfs_replay_log:2100: errno=-17 Object already exists (Failed to recover ...
BTRFS error (device dm-0 state EA): open_ctree failed: -17
mount: /mnt: fsconfig() failed: File exists.

Like the OP, running # brfs rescue zero-log /dev/foo on the device worked for me.

Here is some related references that may be of additional assistance:

https://lore.kernel.org/linux-btrfs/fce139db-4458-4788-bb97-c29acf6cb1df@cachyos.org/

1 Like