BTRFS Error: Can't read tree root, bad tree blcok start

Hi all.

I have a bit of an issue here.

I’m working on adapting a website based software: as such, I needed the whole LAMPS, but as I didn’t want that eating resources on my main machine I created a virtual(box) machine with LAMPS installed, and just installed the new software to start the modifications. It was working fine but I’ve got bored with the repos errors in packakit. After some updates in the repositories (but no system update!), I found a black screen. Restarting did not work.

Since it did not occur to me to backup the modifications I was doing on the software running inside the virtual machine, I have no other option than resurrecting this!

@JulinaB and @susejunky helped me as far as they could at https://forums.opensuse.org/showthread.php/558839-Leap-15-2-Grub-error-on-virtualized-machine-after-repos-update. However, the error was identified to be related to a btrfs error, preventing / from being mounted, and I was suggested to open this new thread.

Following some instructions found somewhere else, I got the following:


#btrfs check --readonly /dev/sda2
Opening filesystem to check...
checksum verify failed on 147865600 found 4653BB36 wanted 464C457F
checksum verify failed on 147865600 found 4653BB36 wanted 464C457F
checksum verify failed on 147865600 found 4653BB36 wanted 464C457F
bad tree block 147865600, bytenr mismatch, want=147865600, have=15762873573703680
Couldn'r read tree root
ERROR: cannot open file system


#dmesg
...
 7807.849496] BTRFS error (device sda2): bad tree block start, want 147865600 have 15762873573703680
 7807.857000] BTRFS error (device sda2): bad tree block start, want 147865600 have 15762873573703680
 7807.857013] BTRFS warning (device sda2): failed to read tree root
 7807.893221] BTRFS error (device sda2): open_ctree failed

Anybody has any idea on what should be my next step to (as safely as possible) recover the this (virtual) machine and raise it back from its (virtual) death? Should I now go straight to “btrfs check --repair” or should I try something else before? (I’ve read something, maybe outdated, that the tools are not as good as they should and as such there is a higher risk of loosing data)

Thanks a lot in advance for any suggestions!

Of course the great thing about it being a VM is that you can make a backup copy of the Virtual Hard Drive and experiment knowing that you can always restore if you totally break it.

Yes, but I didn’t: I was going to that later, on a more advanced point of the work.

Definitely, my mistake. Now I have to solve it, finding a way to repair the btrfs… Any clues? Should my next step be the “btrfs --repair” or may I take some other measures before?

I think your next step should definitely be - as already proposed by JulinaB - to make a copy of your current virtual machine (even if the machine itself is not working).

This will allow you to test various repair scenarios. If one does not work you can just go back to your current state and restart with testing some other approach.

Regards

susejunky

Ok, I should have understood that.

Took me a while because I needed some free space to freely duplicate the virtual machine. I used the “clone” option from virtualbox to do that. Came back into the installation disk repair mode, and tested btrfs check --repair (vanilla and each one of the four additional options available") on the /dev/sda2 drive with no results. :frowning:

Also tried to scrub it. No effect, always the very same output message concerning the “checksum verify failed” and the “bad tree block”, “couldn’t read tree root” and “cannot open file system”… :frowning:

Any additional suggestions, please?

Perhaps this thread my allow you to access your data"
https://forums.virtualbox.org/viewtopic.php?f=7&t=88266

Thanks for the suggestion, but it did not help.

I tried on both the rescue from the opensuse installation dvd (image) and from the virtual machine with that extra disk added. In both cases:
It can’t be mounted with both mount and btrfs restore due to the errors
btrfs scrub was not possible because it was not mounted
btrfs rescue zero-log, super-recover and chunk-recover failed for the same reason
btrfs check --repair also was not successful. :frowning:

Does it seems that I must give up? :cry:

Or someone has any final and hopeful suggestion?

Hi folks.

Guessing I’m out of luck this time, and it can’t be recovered. I’ll have to proceed with the creation and configuration of a whole new virtual machine from scratch.:’(

Thanks for all time and efforts anyway. Unfortunately, this time it seems I’ve hit a dead end, not a more common roadblock that someone knows any kind of workaround.

But still, thank everybody for trying.:slight_smile:

Best wishes.