So I did a dumb thing and hibernated my Win10 host with the Leap guest still running then woke it up, then hibernated again, repeatedly 3x. Now I get this:
and ultimately this:
While I think this is minor and easily fixed, I am not exactly sure where to go with this. I’ve copied the VHD and tried some fixes I found; but none solve the problem.
Has anyone successfully recovered this problem?
thanks,
No, this is the worst that can happen to btrfs and indicates real on-disk filesystem corruption. The best is to ask on btrfs mailing list, as repairing - if possible - needs deep inside knowledge of low level structures.
You did something, but you don’t tell what. Does this make sense?
Well, it made sense when I typed it. But that line would tell me that there exists an original .vhd with this issue and that any copies that had simplish fixes tried were deleted. I mean I did read the btrfs man pages to try and troubleshoot. And I did try to remount with usebackuproot. But the main effort was weeks ago and I did not keep a log.
I am betting that I am not the first person to have this issue here. When I looked for a similar issue, I did not find a Guest OS that was a couple of blocks off and not starting. Conflicting information tells me that if it is close it might be able to be zeroed, or that might break it completely.
How about we skip that line and start from scratch. I have a Leap OS(up to date as of 20221230) in a Vbox Guest on Win10…
What I was hoping for was a redirect to a solved thread or a COA
Following Arvidjaar’s link I see that there is probably a lot more wrong behind the scenes and I will need a better understanding of BTRFS.
What I could use right now is a method of getting dmesg.log out of the VM and onto the host shared folders. That way I can engage with the btrfs mail-list as per their required info when submitting an issue or bug.
Did you try btrfs check --init-csum-tree?
well now that looks like it is in the ‘not simpler’ category and probably did not try that. I was working from this page
https://btrfs.readthedocs.io/en/latest/btrfs-check.html
But if I were to try that, I would need to know exactly why I am getting this:
with the end of the log(after the 30ish warnings):
This is why I think this is a simple problem, but probably can be ‘fixed’ in the wrong way. Creating a new checksum tree and recalculate checksums in all files might fix this. But what if something is actually corrupted?
Yeah, --init-csum-tree ran 40hrs did not change a thing.
In case anyone cares; I got the system functioning enough to get VBox drag-n-drop working and copied out my /home folder with a lot of VM restarts whenever that got clogged up. Not sure how it happened because at some point a couple of weeks ago I realized I will never understand enough about BTRFS to fix this and just started applying fixes and reloading the .vhd until one of them did something. The lesson here for me is a) never trust any OS/FS no matter how much people sing it’s praises(backup and keep it updated), and 2) never expect anyone else to pull apart your problem to understand it and help(do your own homework). Also this house fire has shown me that I accumulate a lot of garbage. I might just burn it all down intentionally every couple years and hop distro.
