Fedora KDE no longer booting, likely filesystem (BTRFS) corruption

Ask Fedora
, , , , ,
1

My laptop’s battery ran out, and after plugging it in back into power, it refuses to boot.
When trying to boot to the latest kernel 6.15.3-200, it shows the following:

1000002805
10000028054891×3259 2.67 MB

When trying to boot into kernel 6.14.11-300, it also refuses to boot, showing the following:

1000002806
10000028064941×2041 1 MB

The same thing is observed when trying to boot into the older kernel 6 14.9-300.
Can someone please provide help? I know that at the moment, there are various issues with the latest kernel and firmware, but I don’t think any of the posts here address the problem faced by me.

2

Could it be a filesystem)/ BTRFS issue that occurred when power was lost? If so, is there any hope of getting it fixed? Or is all my data gone?
I’m a noob by the way, so sorry if I ask dumb questions, just worried

3

Your last image seems to indicate this may be a filesystem error. It shows an error in btrfs on device nvme0n1p3 (which probably contains both / and /home subvolumes).

I am not an expert in btrfs, but I think you probably need to repair the filesystem by booting to a live usb media device and repair that file system before you can boot properly. Maybe someone who is experienced with btrfs can provide detailed guidance.

The indicated rdsosreport.txt file may provide more detailed information.

4

The amdgpu messages are normal and not errors.

5

Can you please explain more elaborately what steps you think I should take?

7

I have 3 usb drives, of which I think one might have MX Linux on it. But plugging a usb drive in and then booting doesn’t show any live usb options in GRUB. It is possible that none of the USBs have anything, and that I might have restored them. But I can’t confirm this as this is the only computer I have at hand.

When I attempt to boot into kernel 6.15, and then plug in a drive, it shows that it’s detected. But when I try to reboot on kernel 6.15, it hangs and doesn’t reboot…
When trying this on the 6.14 kernels, no message about the detection of USB drives is seen. But rebooting works on those kernels…

8

You would select this from the BIOS boot menu, not from GRUB.

There should be a hotkey that you hold during boot to get that. Alternatively, GRUB should have an option “UEFI Firmware Settings” that takes you into your BIOS config menus, where you can usually override the boot order to select a USB.

9

Ok, will try that in a little bit. Just said that because previously, live USBs used to show up in GRUB too

10

I do not recall that a bootable USB has ever shown up in a grub menu on fedora, unless fedora was installed on that usb and not on the internal drive.

I have only ever seen bootable USB devices displayed in the bios boot menu (and then only if booting from usb was enabled in the bios – some systems have usb booting disabled).

11

Ok, I successfully booted into MX live environment. What steps should I take now? Again, sorry for noob questions

12

You have a problem with the log tree, you could definitely fix it by deleting.

From a Fedora live session:
sudo btrfs rescue zero-log /dev/nvme0n1p3

WARNING:

Note

Clearing the log may lead to loss of changes that were made since the last transaction commit. This may be up to 30 seconds (default commit period) or less if the commit was implied by other filesystem activity.

Short explanation

2 Likes
13

Thank you so much! That worked.

1 Like
14

The “Failed to recover log tree” message tells me a couple of things:

There was a crash or power fail immediately before this boot. And there was write activity involving fsync at the time.

There is an upstream report about log tree issues in 6.15.x kernels, but developers have requested a complete dmesg and so far one has not been provided. It would be really helpful to get a dmesg for your mount failure with a 6.15.x kernel. This is not the easiest thing to do. But here you go…

Can you get a copy of the /run/initramfs/rdsosreport.txt posted somewhere publicly? Ideally a Fedora bug report, as an attachment. You can skip the template questionaire in the bug report description, delete that and just write:

kernel 6.15.3
BTRFS error Failed to recover log tree.

And attach the rdsosreport.txt to that bug report. And after that, reply to the btrfs list with the URL for the Fedora bug containing the dmesg, and say you’ve got a system with a 6.15.3 kernel, a log tree replay failure, and a dmesg attached to the bug. That’s it.

To get that text file, you’ll need to deal with the limited command line environment available in the initramfs.

You should be able to successfully save it to a USB stick (fat, ext4, btrfs formatted) or even the EFI system partition on the same drive. This txt file is only in memory so every time you boot it goes away. We just need it on stable media.

In the initramfs it’s not obvious where to mount because the available dir names are not what you’d expect. It’s safe to mount the volume you want to save to at /sysroot and then copy the txt file there.

As far as getting back up and running. I’d prefer to see a complete dmesg as well. Zeroing the log tree is not dangerous, as it’s not needed at all for file system consistency. However, the last seconds of file system writes will be lost as a result - most anything being written at the time of the last fsync will be lost.

If that’s concerning then you shouldn’t zero the log and we need to see what upstream says about your dmesg. And if there’s a safe way to recover. Very possibly trying to boot with a 6.14 series kernel is the way to go, but since we don’t know whether this is a bug with the recovery, the reading of the log, or the writing of the log, it’s speculation.

1 Like
15

Isn’t it a bit late for that now, with the issue having been resolved and me being able to boot without issues? Would the concerned files still be of any relevance at this stage, or should they have been backed up when the issue was still occurring?

16

I tend to respond to a thread before I’ve read the whole thing. :joy:

Once zero log has been run, the information needed is gone. So yeah ideally next time collect a complete dmesg (no trimming) for a bug report and upstream developers is the best approach.

1 Like