Fedora 44 kernel 7.2.6 won't boot

Ask Fedora
, ,
1

I have Fedora 44 KDE Plasma. It’s up-to-date except for nvidia and the kernel.

Current kernel: 7.2.5
Current nvidia: 610.57.04

I first updated nvidia to 615.71.09 without updating the kernel, rebooted and it worked fine. Next, I updated the kernel to 7.2.6 and rebooted and it fails on boot (see screen output below). I had to hold the power button to turn off the laptop and reboot. I started the previous kernel (7.2.5) and it works fine.

I skipped a lot of “OK” messages, but included all the FAILED messages. I had to hand type this based on a video I took while booting.

I don’t think the first FAILED message (systemd-module-load.service) is related because it’s very early in the boot process and it happens even with the successful 7.2.5 kernel. In fact, looking back in /var/log/messages* it seems like it’s been there for a while. The rest of the messages are much later in the boot process and none of them happen while booting 7.2.5.

...
[FAILED] Failed to start systemd-module-load.service - Load Kernel Modules.
See 'systemctl status systemd-modules-load.service' for details.
...
[FAILED] Failed to mount boot-efi.mount - /boot/efi
See 'systemctl status boot-efi.mount' for details.
[DEPEND] Dependency failed for local-fs.target - Local File Systems.
[DEPEND] Dependency failed for selinux-autorelabel-mark.service - Mark the need to relabel after reboot.
...
[FAILED] Failed to mount proc-sys-fs-binfmt_misc.mount - Arbitrary Executable File Formats File System.
See 'systemctl status proci-sys-fs-binfmt_misc.mount' for details.
[FAILED] Failed to start systemd-binfmt.service - Set Up Additional Binary Formats.
See 'systemctl status systemd-binfmt.service' for details.
...
[FAILED] Failed to mount var-lib-nfs-rpc_pipefs.mount - RPC Pipe File System.
See 'systemctl status var-lib-nfs-pipefs.mount'  for details.
[DEPEND] Dependency failed for rpc_pipefs.target.
[DEPEND] Dependency failed for rpc-gssd.service - RPC security servier for NFS client and server.
...
[  OK  ] Stopped target emergency.target - Emergency Mode.
         Mounting boot-efi.mount - /boot/efi...
[  OK  ] Stopped emergency.service - Emergency shell.
[FAILED] Failed to mount boot-efi.mount - /boot/efi.
See 'systemctl status boot-efi.mount' for details.
[DEPEND] Dependency failed for local-fs.target - Local File Systems.
[DEPEND] Dependency failed for selinux-autorelabel-mark.service - Mark the need to relabel after reboot.
[  OK  ] Started emergency.service - Emergency shell.
[  OK  ] Reached target emergency.target - Emergency Mode.
         Starting systemd-binfmt.service - Set Up Additional Binary Formats...
         Mounting proc-sys-fs-binfmt_misc.mount - Arbitrary Executable File Formats File System...
[FAILED] Failed to start systemd-binfmt.service - Set Up Additional Binary Formats.
See 'systemctl status systemd-binfmt.service' for details.
[FAILED] Failed to start systemd-binfmt.service - Set Up Additional Binary Formats.
See 'systemctl status systemd-binfmt.service' for details.
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, or "exit"
to continue bootup.

Cannot open access to console, the root account is locked.
See sulogin(8) man page for more detials.

Press Enter to continue.

Reloading system manager configuration.
[   11.239488] zram_generator::generator[004]: modproblem "zram" failed, ignoring: code exit status: 1
Starting default.target
You are in emergency mode. After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, or "exit"
to continue bootup.

Cannot open access to console, the root account is locked.
See sulogin(8) man page for more detials.

Press Enter to continue.
2

7.2.6?

all i had is 7.2.5 then straight to 7.2.7 but i am on fedora 45, could you check again to confirm if the new kernel is available for fedora 44 now?

3

You’re on f45 beta, update more frequently or at least check for available updates and decide what you want to pull from updates-testing

$ ll /boot/vmlinuz-*
-rwxr-xr-x. 1 root root 19040616 Sep 18 19:17 /boot/vmlinuz-0-rescue-567c7e0e03b242e4b5d672cc22fffe54
-rwxr-xr-x. 1 root root 19024232 Sep 11 02:00 /boot/vmlinuz-7.2.5-300.fc45.x86_64
-rwxr-xr-x. 1 root root 19048808 Sep 14 02:00 /boot/vmlinuz-7.2.6-200.fc44.x86_64
-rwxr-xr-x. 1 root root 19040616 Sep 14 02:00 /boot/vmlinuz-7.2.6-300.fc45.x86_64
-rwxr-xr-x. 1 root root 19007848 Sep 21 02:00 /boot/vmlinuz-7.2.7-300.fc45.x86_64
4

Did you wait until the nvidia kernel modules were build successfully?

you could try running sudo depmod 7.2.6-200.fc44.x86_64.
Otherwise you could try reinstalling the kernel packages for 7.2.6
sudo dnf reinstall 'kernel*7.2.6*' followed by a sudo akmods.
Last command will only return when system finished building the nvidia kernel modules and it’s safe to reboot.

7.2.6 is probably no longer available, so try sudo dnf up kernel\* to upgrade to 7.2.7. Again, when the prompt returns run sudo akmods and only then reboot the system.

5

If akmods has previously run that command will do nothing.
I always recommend to run sudo akmods --rebuild --force so akmods will remove the previous version of the drivers as well as build & install the new drivers with a single command

6

please read again… sudo akmods will wait as long as the triggered akmods process is buildiing and installing the kmods for the new kernel.

this is an easy workaround to see exactly when it’s safe to reboot.

7

True, but if it has completed and did not create a viable driver even though it thinks it did; it then does not repeat unless at least the ---force is used.

DESCRIPTION
       Checks the akmod packages and rebuilds them if needed

OPTIONS

       --force             -- try all, even if they failed earlier

       --kernels <kernel>  -- build and install only for kernel <kernel>
              (formatted the same as 'uname -r' would produce)

       --rebuild           -- rebuild all, even if they are up to date

       --akmod <akmod>     -- build and install only akmod <akmod>

       --quiet

       --verbose

To be certain of a proper rebuild both the --force and --rebuild options should be used.

8

Yes. And checked the logs. Pretty sure it’s not nvidia related, but could be wrong.

If I recall, nvidia 615.71.09 showed up (at least for me) on Mon (9/21). I planned to test it, but didn’t get around to it until Tue (9/22) and that’s when kernel 7.2.6 showed up. Now today (9/23) I see kernel 7.2.7 is available, so perhaps there was a problem with 7.2.6 since it only seemed to be around for 1 day.

I’ll try to test 7.2.7 today and see if it works.

I have a separate partition I sometimes use for testing, particularly when it comes to new nvidia releases and sometimes new kernels. It’s a copy of my existing root partition with a different UUID. I can recreate it quite easily, so it’s simple to try different scenarios.

Yesterday, I tried all of the following and in all cases waited until the nvidia akmods rebuilld was complete before rebooting. And in all cases below the only packages available for update were kernel 7.2.6 and nvidia 615.71.09. All other packages were up-to-date.

Copy current root partition to test partition and boot test partition:

kernel 7.2.5, nvidia 610.57.04 - current system - works
kernel 7.2.5, upgrade nvidia 615.71.09, reboot - works
upgrade kernel 7.2.6, nvidia 615.71.09, reboot - FAILS

Copy current root partition to test partition and boot test partition:

kernel 7.2.5, nvidia 610.57.04 - current system - works
upgrade kernel 7.2.6, upgrade nvidia 615.71.09, reboot - FAILS

Copy current root partition to test partition and boot test partition:

kernel 7.2.5, nvidia 610.57.04 - current system - works
remove kernel (7.1.8), upgrade kernel 7.2.6, nvidia 610.57.04, reboot, FAILS

That last one is why I think it’s not nvidia related. I had to remove the older (no longer needed) 7.1.8 kernel and associated kmod-nvidia package because of a conflict (see below), but after that I was able to update the kernel w/o updating nvidia.

# dnf update --exclude '*nvidia*'
Updating and loading repositories:
Repositories loaded.
Failed to resolve the transaction:
Problem: installed package kmod-nvidia-7.1.8-200.fc44.x86_64-3:610.57.04-1.fc44.x86_64 requires kernel-uname-r = 7.1.8-200.fc44.x86_64, but none of the providers can be installed
  - conflicting requests
  - problem with installed package
9

just try

sudo depmod 7.2.6-200.fc44.x86_64`

then try booting 7.2.6…

another, idea:
do you have ntfs volumes listed in /etc/fstab?

kernel 7.2.6 removed the ntfs3 kernel driver.. Maybe add ‘nofail’ to all ntfs volumes

10

Kernel 7.2.7 is already out for f44. Try another update.
Possibly remove kernel 7.2.6 first with sudo dnf remove kernel\*7.2.6\*

11

Tested 7.2.7 and it works. Given that, and the fact 7.2.6 wasn’t around very long it sure looks like there was some problem with it… maybe it was only a problem for specific hardware configs.

Basically, I did the same thing I did yesterday:

On main partition

# dnf update --exclude '*kernel*' --exclude '*nvidia*'
copy main partition to test partition, update UUID and reboot to test partition

Only updates available at this point are kernel 7.2.7 and nvidia 615.71.09, all other packages are up-to-date.

On test partition

# dnf remove kernel-core-7.1.8 (removes all kernel/kmod-nvidia packages for 7.1.8)
# dnf update --exclude '*nvidia*' (updates kernel to 7.2.7)
wait for akmod to build kmod-nvidia, check log, reboot - WORKS
# dnf update (updates nvidia to 615.71.09)
wait for akmod to build kmod-nvidia, check log, reboot - WORKS
12

Allo, This is useless information on my part but i should say i am in the same boat i have base fedora 44 KDE i have an rtx 5070 ti mobile and i too manually built the newer nvidia driver 615 on kernel 7.2.4 but contrary wise did not have these issues with kernel updates i did unlike some also briefly have 7.2.6 but everything worked normally so Since i stumbled on this thread as today’s fix of the day in the fedora homepage figured id at least mention it since i think its pretty interesting and that the issue could’ve been specific but it could have been anomalous perhaps or maybe gen specific depending on the rtx gen?

13

that was my point

your comments here seem to be a bit of lost, i think you were not reading most of what was happening here.

14

that was directed to you.
7.2.6 was available for many days for f45 users.
read the context.

7.2.7 was pushed early, because it has some security fixes. Usually kernels remain longer in updates-testing.

15

i checked, it was not there for me, so i clearly said from 7.2.5 to 7.2.7, and keep in mind, i am not the op, so tell me that just made things messier, confusing, wasted time.

16

that’s why I wrote you should check more often. In F45beta the updates-testing repositories are enabled as default, unless you disabled those.

and line shows kernel was a week ago on Sep 14 and available in updates-testing.

-rwxr-xr-x. 1 root root 19048808 Sep 14 02:00 /boot/vmlinuz-7.2.6-200.fc44.x86_64
17

stop repeating that, that is my point, what you say and how you say matters, focus on the op, the solution was what i said at the beginning.

18

and how did this contribute?

19

there, a third chance to read all the comment, quote me incomplete tells alot about your intention here

basically you are just annoying me here and i will stop getting notifications from this thread so i dont have to read your replies anymore, because this kind of attitude on a forum where people come to help or find help, is far from ok.

20

From my testing I don’t think the problem had anything to do with nvidia. But that’s just my best guess based on what I saw… I certainly could be wrong.

What I should have tested, but didn’t think of it yesterday:

Copy my current partition to my test partition (kernel 7.2.5, nvidia 610.57.04)
Boot to test partition
dnf remove '*nvidia*' (or something like that... maybe not the firmware package)
Reboot test partition and check kernel 7.2.5 w/o nvidia
dnf update kernel (to 7.2.6)
Reboot test partition and see if it still fails on boot

Presumably that would eliminate nvidia from the equation assuming 7.2.6 still failed to boot.

Unfortunately, 7.2.6 is no longer available, so I can’t test it. It’s not even in updates-archive, or does it take a while for packages that have been removed from updates to arrive in updates-archive?

# dnf list --showduplicates --enablerepo=updates-archive kernel | grep ' 7.2'
Updating and loading repositories:
Repositories loaded.
kernel.x86_64 7.2.5-200.fc44   updates
kernel.x86_64 7.2.4-200.fc44   updates-archive
kernel.x86_64 7.2.5-200.fc44   updates-archive
kernel.x86_64 7.2.7-200.fc44   updates