System acts weird after kernel 6.13.4 upgrade

Ask Fedora
,
1

After the upgrade to kernel 6.13.4, the system acts weird. If I open app Secrets, is just freezes. After that I cannot open System monitor to kill the app. The camera doesn’t work, LibreOffice freeze (after using it for 20 min), Thunderbird freezes if sending an e-mail. Several apps freeze and nothing but hard reset (pressing the power button for 10 seconds) helps.

If I choose an older kernel in GRUB, then everything works as expected.
Computer:
Thinkpad X1 Carbon 9th generation
Fedora Workstation 41 with GNOME

1 Like
2

Have a look in the system journal for errors.

If you avoid using gui tools and work from the terminal where it is more likely you can get information when things are going bad.

1 Like
3

I had the same and htop didnt launch either lol.

@lapor are these apps Flatpak apps?

This seems to be the upstream bug in kernel 6.13

I recommend to install the longterm kernel and use that, as there is no other safe and reliable way to use a different kernel on fedora

https://copr.fedorainfracloud.org/coprs/kwizart/kernel-longterm-6.12

The 6.12 LTS kernel built the first time, thanks @kwizart ! This would be the safest way to not use 6.13, or what @ledeni said below

1 Like
4

Thanks for the info. Yes, all the apps were Flatpak apps. I will use kernel 6.12 for now, because I don’t have time do dig into reverting kernels. But I will have to revert it sooner or later :slight_smile:

2 Likes
5 
sudo dnf versionlock add kernel-6.12.15-200.fc41.x86_64 to lock 6.12.* kernel my kast kernel is 6.12.15
2 Likes
6
2 Likes
7

Just an FYI, if you are going to use dnf versionlock you will probably have to add all of the individual kernel components to keep kernel packages in sync. If I just version locked kernel all of the others still updated. For example, I have all of the following installed (you may have some or all of these):

kernel-core-6.12.15-200.fc41.x86_64
kernel-modules-core-6.12.15-200.fc41.x86_64
kernel-modules-6.12.15-200.fc41.x86_64
kernel-tools-libs-6.12.15-200.fc41.x86_64
kernel-devel-6.12.15-200.fc41.x86_64
kernel-devel-matched-6.12.15-200.fc41.x86_64
kernel-tools-6.12.15-200.fc41.x86_64
kernel-modules-extra-6.12.15-200.fc41.x86_64
kernel-6.12.15-200.fc41.x86_64

Instead, I added the following into /etc/dnf/dnf.conf:

[main]
# Don't move to kernel 6.13 yet
excludepkgs=kernel*-6.13.*

This will ignore all kernel packages related to 6.13. xx.

1 Like
8

Ok, I have added:

sudo dnf versionlock add kernel-6.12.15-200.fc41.x86_64

and to /etc/dnf/dnf.conf:

[main]
# Don't move to kernel 6.13 yet
excludepkgs=kernel*-6.13.*

But when (if) they fix the bug in 6.13, I’ll have to delete the entry in /etc/dnf/dnf.conf’ and somehow unlock the kernel.

Thanks for your help!

9

It is actually one method or the other. With versionlock and dnf you should create and entry for all of the associated packages related to the kernel version you are locking to.
-OR-
You can put the line in dnf.conf to exclude the related packaged from being seen by dnf.

They both do basically the same thing in slightly different ways. The dnf versionlock does not seem to accept wildcards which is why I prefer the dnf.conf method. Either will work, though, you do not need both.

FYI: To clear the versionlock entries, run dnf versionlock clear to clear all of the entries. When you want to start getting the kernel updates again, just remove the line from dnf.conf and run dnf update --refresh and you will see the kernel updates.

10

This kernel seems to be causing me problems in Kinoite. I keep getting crashes in the Google Chrome Flatpak.

To solve for now, I’m running the old deployment, which I have pinned:

Good:

Version: 41.20250224.0 (2025-02-24T00:49:43Z)

Bad:

Version: 41.20250226.0 (2025-02-26T00:52:21Z)

11

Thanks for your help and the commands for reversing the blocking of kernel upgrading.

Now I have another issue. If I want to update Flatpak apps, I get this:

Warning: opendir(refs/remotes): file or directory with this name does not exist
Error: opendir(refs/remotes): file or directory with this name does not exist

Is this unrelated issue or somehow related?

Thanks

12

I highly doubt it is related to anything in this thread (kernel or fuse related). It looks like you have a configuration issue with the flatpak remotes. I don’t do a lot with flatpaks or similar, so not going to be much help.

13

Kernel 6.13.4 breaks flatpaks and FUSE. There is a fix on testing 6.13.5, I had to revert back to 6.12.15 cause of the bugs in 6.13.4

14

The issue being discussed in this thread is regarding references in page_cache when running flatpaks, as the bug affects user-space fuselib and kernel space fuse. As far as I am aware, it does not affect running the flatpak binary to update flatpak “images” (e.g. flatpak update).

The error messages last provided do not allude to any kernel issue, they look like an error with the remotes provided by stderr of the flatpak binary. Also, I assumed (probably incorrectly) that the person had already reverted their kernel to a previous release as that was the last conversation. Hence, my response that it was highly unlikely to be related.

But hey, I’m just another dude providing some input… what the heck do I know. :slight_smile:

15

6.13.4 broke flatpak apps. If you try and load most flatpaks with the kernel then it panics. The kernel will throw a bunch of kernel: BUG: Bad page state in process ... Arch already patched it out. Also get RIP with a 64 bit code

16

I can see that 6.13.5 is being released on Fedora. Are we on the safe side with this version? Or do I have to wait more?
Thanks

17

You are fine with 6.13.5-200, the fix related to the issue is applied:

- fuse: revert back to __readahead_folio() for readahead (Joanne Koong)
1 Like