Update to 41.20250217.0 gives a Kernel Panic error on boot

Ask Fedora
1

First of all, I have a PC and Laptop with Onyx and a laptop with Silverblue.

My laptop with Onyx showed me this error:

1600×1200 134 KB

I thought: well, I will boot from previous deployment and see what’s going on.

I couldn’t bring up the grub menu in any way. I tried all the suggestions in the internet: ESC, Shift, F8, etc… Nothing worked.

Then I thought, It might be this hardware so I tried with my other laptop and PC running Silverblue and Onyx: nope, same thing.

I started looking for a way to edit grub on Atomic desktops and found to edit this file.

/boot/grub2/user.cfg

Ok, so I set timeout=3 in my still working PC and Laptop and then I was able to hit ESC and bring up the grub menu.

Taking a look at this file

/boot/grub2/grub.cfg

I can see that grub is set to timeout=0.

Onyx laptops were upgraded from Fedora 40, Silverblue was a Fedora 41 fresh install.

So, My question, How do I fix this error?

And, also, what is the point of having an atomic desktop if by default can’t boot in previous deployments because grub menu won’t show?

Info on deployments:

State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● fedora:fedora/41/x86_64/onyx
                  Version: 41.20250216.0 (2025-02-16T00:49:11Z)
               BaseCommit: 93741fe9e8b94c466ebcfdfd7f2c0f34ebd4f39b25c4d9a134a25b219c4d84e8
             GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1
          LayeredPackages: langpacks-es
            LocalPackages: cnijfilter2-6.40-1.x86_64
                   Pinned: yes

  fedora:fedora/41/x86_64/onyx
                  Version: 41.20250217.0 (2025-02-17T00:43:30Z)
               BaseCommit: 0dedc780b2943d66903808b4703be4978034edff96994e34f1d041697f5a1b7f
             GPGSignature: Valid signature by 466CF2D8B60BC3057AA9453ED0622462E99D6AD1
          LayeredPackages: langpacks-es
            LocalPackages: cnijfilter2-6.40-1.x86_64


ostree diff commit from: 93741fe9e8b94c466ebcfdfd7f2c0f34ebd4f39b25c4d9a134a25b219c4d84e8
ostree diff commit to:   0dedc780b2943d66903808b4703be4978034edff96994e34f1d041697f5a1b7f
Upgraded:
  distribution-gpg-keys 1.107-1.fc41 -> 1.110-1.fc41
  libxcrypt 4.4.38-3.fc41 -> 4.4.38-6.fc41
  nemo 6.4.3-1.fc41 -> 6.4.4-1.fc41
  nemo-extensions 6.4.3-1.fc41 -> 6.4.4-1.fc41
  nemo-search-helpers 6.4.3-1.fc41 -> 6.4.4-1.fc41
  python3-boto3 1.36.19-1.fc41 -> 1.36.21-1.fc41
  python3-botocore 1.36.19-1.fc41 -> 1.36.21-1.fc41

41.20250216.0: Works
41.20250217.0: Kernel Panic

Edit: relevant to this

1 Like
2

Well, same thing happened on my PC with Onyx after update to 20250217.

Luckily I had changed my grub settings so I could get to the grub menu and boot from 20250216. That booted with no problem.

3

Interesting. On both a Silverblue 41 fresh install, as well as on an upgraded one from Silverblue 40, I am always presented with the GRUB menu (with set timeout=1 in /boot/grub2/grub.cfg). It’s for this reason that I never change it to timeout=0, as I have noticed on a test VM that no key would reveal GRUB.

Can you boot with a live ISO (e.g. F41 Workstation), and from there mount the /boot partition, then create the /boot/grub2/user.cfg file (where you would add the set timeout=0 flag?

4

On Silverblue I changed it myself to timeout=0 on user.cfg a few weeks ago. So maybe that’s why grub.cfg said timeout=0. Now I changed user.cfg to timeout=3 just in case I need to bring up the grub menu.

Other two Onyx installs are default and in neither of them I could get the grub menu. I could change user.cfg in one of them before updating to 41.20250217.0 which is the one I get the kernel panic in both machines. But beacuse I changed it to timeout=3 in one of the PCs I could boot the previous 41.20250216.0 deploy, pinned it, rollback and undeploy the 41.20250217.0.

I disable auto updates too. So for now I have this PC running. The other one I can’t check what grub.cfg says. I can boot a Live USB but I don’t know how to mount /boot

Just using Disks would be ok?

5

You can check man mount for syntax details. But you might be able to mount the boot partition via GNOME Disks too.

6

I will try that.

But, the important thing, What happens with that update that breaks every installation?

7

Posssibly an issue that will be fixed with the next OSTree image. Let’s see tomorrow’s build.

8

Thanks for your help.

1 Like