BTRFS volume broken

General system Newbie
1

Something messed up while trying to fix the current grub issue, now my encrypted BTRFS volume is broken. On startup after entering the passphrase it enters grub rescue with

error: file /0/boot/grub/x86_64-efi/normal.mod' not found.

Load the live usb back up, go through the same steps:

sudo cryptsetup open /dev/nvme0n1p2 mycryptdevice

enter in my passphrase and then

sudo mount /dev/mapper/mycryptdevice /mnt -o subvol=@

which errors

mount: /mnt: can't read superblock on /dev/mapper/mycryptdevice. dmesg(1) may have more information after failed mount system call.

I’ve tried running sudo btrfs rescue super-recover but it says All supers are valid, no need to recover

dmesg gives

BTRFS critical (device dm-0): corrupt leaf: 
root=1 block=30408704 slot=0, invalid root generation, have 104979 
expect (0, 104977] [  263.013964] BTRFS error (device dm-0): 
block=30408704 read time tree block corruption detected [  263.014256] 
BTRFS critical (device dm-0): corrupt leaf: root=1 block=30408704 
slot=0, invalid root generation, have 104979 expect (0, 104977] [  
263.014258] BTRFS error (device dm-0): block=30408704 read time tree 
block corruption detected [  263.014261] BTRFS warning (device dm-0): 
failed to read fs tree: -5 [  263.014962] BTRFS error (device dm-0): 
open_ctree failed

I run sudo btrfs check --repair /dev/mapper/mycryptdevice and get

Opening filesystem to check...
parent transid verify failed on 30408704 wanted 3228 found 104979
parent transid verify failed on 30408704 wanted 3228 found 104979
parent transid verify failed on 30408704 wanted 3228 found 104979
Ignoring transid failure
Checking filesystem on /dev/mapper/mcd
UUID: ****
[1/7] checking root items
parent transid verify failed on 36814848 wanted 104553 found 104980
parent transid verify failed on 36814848 wanted 104553 found 104980
parent transid verify failed on 36814848 wanted 104553 found 104980
Ignoring transid failure
parent transid verify failed on 155385856 wanted 104835 found 104982
parent transid verify failed on 155385856 wanted 104835 found 104982
parent transid verify failed on 155385856 wanted 104835 found 104982
Ignoring transid failure
parent transid verify failed on 111853568 wanted 104831 found 104981
parent transid verify failed on 111853568 wanted 104831 found 104981
parent transid verify failed on 111853568 wanted 104831 found 104981
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=101308071936 item=81 parent level=1 child bytenr=111853568 child level=1
ERROR: failed to repair root items: Input/output error

I really don’t know what else to do at this point? Is there any way of getting my data back?

2

fsck?

3

In the end I went on the BTRFS IRC channel where they gave me the bad news that the FS was toast. With a bit of help from them I was able to use the BTRFS tools to recover all my data onto another drive and had nuke the FS. Not a great experience after only using EndeavourOS a few months…

1 Like
4

I think the blame is more on BRTFS than EndeavourOS.
I have been using EndeavourOS with ext4 and haven’t had a FileSystem related problem since EnOS started 3 years ago.

Pudge

3 Likes
5

I would check the disk for defects before blaming BTRFS or reusing disk. Try to do something with the disk (ie. create new filesystem) and then run

sudo journalctl -b

and look for read / write errors. If there are any, stop using the disk.

6

Hopefully you have your data backed up on an external device. If not, this might be the perfect time to consider such an option.

7

I have never seen a compelling reason to not use any of the ext2, ext3, and ext4 filesystems. I have been using Linux since 2000 and not once has an ext filesystem let me down. I highly doubt I will ever be able to afford the storage resources that even approach the limits of ext4. :slight_smile:

8

@Pudge i’m not really blaming anything, just one of those unfortunate series of events (the broken grub update), an unsuccessful fix which then caused my machine to freeze and a hard reset which then caused my FS to implode. I’ve moved back to ext4 as a precaution.

@mrvictory thanks I wiped the FS, can’t see any disk errors in journalctl.

@eznix no I stupidly didn’t have a backup system running. I’ve since setup vorta/borgbackup/rclone system to backup to Google Drive. I’ll also be creating a local backup system on top when I get my hands on a large enough drive. I got away with it this time and was able to retrieve my data, won’t be taking that risk again! I’ve also gone back to ext4, BTRFS has some really interesting features, but I’d rather stick with something tried and tested for now.