Problem mounting root during boot

Issues & Assistance
1

Hi, today I downgraded to the kernel 5.12.12 because I saw that the kernel 5.12.13 has some problems with the amdgpu driver.
After downgrading the kernel I booted into my system and everything was fine. Sometimes, my screen suddenly freezes (and sometimes shows a black screen) and I have to wait (for a graphics reset) or turn off the computer by resetting it (pushing the button). This time I hadn't time to wait, so I pushed the button to turn everything off.
When I booted again my pc, I received this error:

mount: /new_root: wrong fs type, bad option, bad superblock on /dev/nvme0n1p5, missing codepage or helper program, or other error.
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off

Restoring shapshots and trying other kernels didn't worked (including linux-zen, linux-xanmod-anbox and linux-lts, with their respective initramfs entries).
Booting Windows 10 works.
If I try to chroot from a live build with the tool provided by Garuda it doesn't work (it spawns a new terminal that closes immediately, so i can't read anything).
If I try to mount the partition from the live iso in dolphin, the same error appears in the u
UI.
If I do sudo btrfs check --readonly /dev/nvme0n1p5 the following error pops up:

Opening filesystem to check...
bad tree block 66703343616, bytenr mismatch, want=66703343616, have=66693906432
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system

What I can do?

2

When you downgraded did you also downgrade the headers?

I don't think downgrading the kernel is a good way to work around a new kernel incompatibility. Best to use an alternate kernel IMO.

You may possibly have corrupted your file system. I'll leave it to others more experienced than myself to try and correct those errors.

3 Likes
3

Yes, I also downgraded the headers with the kernel.
This time downgrading the kernel was the only solution i had, since these buggy commits were backported also to the lts version and I already updated every kernel I had on my system.

4

The linux-hardened or sometimes the linux-rt kernel lags behind other kernels as far as updates, so some times they are worth testing.

3 Likes
5

I am not an expert on btrfs but that looks bad to me.

First I would check the smart status of that drive from the live session(or windows) to make sure it isn't reporting any issues.

If there are no issues, you might read through this and see if there is anything that would help you:
https://btrfs.wiki.kernel.org/index.php/Restore

My guess is that this has nothing to do with your kernel downgrade but instead the fact that due to your system issues you are having to shutdown improperly and/or failing hardware somewhere.

5 Likes
6

Hard power-offs will eventually end up breaking the filesystem (e.g. you do it during a superblock write); I agree with dalto that this may be a symptom of another issue.

3 Likes
7

I was only on my cell, so I did not read the output too carefully and I am not by any means an expert with btrfs. Indeed that does not look good.

OT.

Very nice to see you pop in for a visit @dalto. Don't be a stranger.

4 Likes
8

I checked using CrystalDiskInfo and this is the output:

CrystalDiskInfo_20210629081655
CrystalDiskInfo_20210629081655842×806 49.1 KB

As you can see, there aren't any errors, so, what happened? The SSD didn't have time to record the error?

I think so, the bootup process shows udev starting up so I think that something corrupted on the SSD.

Thanks! I didn't run any restore/repair command because I could do even more damage.
The "simple" usage doesn't have any effect so I think I'll figure out how to use the "advanced" one.
If none of the methods specified on the page will work I'll chat in their libera.chat and report back here the solution that worked for me.
Thanks to all that responded to this post :smile:!

1 Like
9

I successfully recovered my data (or, at least, most of them) by using the "advanced" solution in the wiki page specified above by @dalto.
One note to all that might have the same issue in the future: since when you are going to use restore you are probably using a live session, make sure you specify a different destination instead of /mnt/restore, maybe an external drive would be better since it will fill up tmpfs (which is your ram, at least in arch and derivatives) with all recovered data.
Unfortunately my partition was unrecoverable, i tried all steps from this article but none of them worked (I tried also with btrfs rescue fix-device-size and mounting with -o rescue=all, which are not included in the guide).
I decided to erase my garuda partition and reinstall everything.
Again, thanks to everyone that helped me!

2 Likes
10

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.