Computer gets stuck booting after upgrade to F40

I’ve done several upgrades fo F40 and all went fine but last 2, where reboot to 6.8.10 F40 kernel get stuck looking for resume disk as it seems, but booting 6.8.10-200-F39 boots normally.
I’ve checked and it seems that /etc/default/grub have resume=UUID=xxxx which I presume is a swap file, and this swap file seems to be recreated on reboot as it uses /dev/zram, I was checking other servers and there I had physical swap partition, though I also see resume= command line to not have proper swap UUID, but it still boots normally.
I’ve played in updating proper UUID but no luck, as every reboot new swap file and UUID is created.
I’ve also noticed that Job dev-disk-by has “no-limit” with F40 kernel whereas “1m30s” with F39 kernel

so is this really about the swap file or something else? And how to at least limit time in F40 when searching for this disk?

1 Like

There was another thread with similar problems after upgrading and attempting to boot into an f40 kernel. The solution was simple.

The kernel command line had a resume option that pointed to a partition that no longer existed and using grubby to remove that option solved the problem.

Boot to the f39 kernel then run cat /proc/cmdline.
If there is an option in that command line that begins with resume=UUID=xxxx-xx... then use grubby to remove that option with
sudo grubby --remove-args=string-to-be-removed --update-kernel=ALL and replace the “string-to-be-removed” with the full text of that resume=UUID=.... option seen in the kernel command line.

It appears that with f39 and earlier the kernel would timeout on that fsck check you show and allow boot to continue but with f40 it now has no timeout on that failure


I can confirm that removing resume=UUID=xxxx option from:
and rebooting solved the problem. Probably running grub2-mkconfig would take care of last 2 entries
I had to also did following update for VBox driver
#echo "extra/VirtualBox/vboxnetflt.ko.xz: extra/VirtualBox/vboxdrv.ko.xz extra/VirtualBox/vboxnetadp.ko.xz: extra/VirtualBox/vboxdrv.ko.xz extra/VirtualBox/vboxdrv.ko.xz:" >>/lib/modules/$(uname -r)/modules.dep
#akmods --kernels $(uname -r) && systemctl restart vboxdrv.service
(this happens frequently when upgrading and older fedora kernel is same as newer fedora kernel, and same goes for nvidia drivers in my experience)

Do you maybe know if possible to set timeout of say 90s like it is with F39 kernel?
Is the resume option for the purpose of hibernation only, or for something else also?

1 Like

Doing all that manually leaves room for error – either with a missed entry or with a typo.
Using the grubby command as I showed does it all automatically with a single command and leaves no room for possible errors.

AFAIK the timeout can not be easily changed since it is part of the boot process. The resume seems to be for suspend/hibernation though I have never used it.

If there are problems with particular modules as you indicate I think that the command
sudo depmod -a would take care of all that.

This would do nothing for existing kmod packages unless used with both root privileges (sudo) and --force (and possibly --rebuild)

1 Like

Thanks @computersavvy , I have to test if depmod -a handles this issue with drivers.

I’ve also noticed that, this issue is not specifically connected to upgrade process. So if you upgraded to F40 before 6.8.10 kernel it will not appear until you update kernel to 6.8.10 and reboot.

Thanks! I spent hours yesterday and found this today. Fixed it for me


Thanks @computersavvy , I have tested it on another server and depmod -a solves the issue, so much easier than adding manually drivers.