Possibly I guess. I’ll go through the commandline, just a min …
[jakfrost /]$ cat /proc/cmdline
initrd=\c1d0698d3ac34d00ae714cc01ea5140f\6.8.9-300.fc40.x86_64\initrd root=UUID=17d62767-03c0-4f34-8038-65136eaa7a5c ro rootflags=subvol=fedora-root-sub resume=UUID=4c9bbdab-9aaa-461f-a0c6-3d583e2caf5d rhgb quiet nosmt fips=0 systemd.machine_id=c1d0698d3ac34d00ae714cc01ea5140f
Well there’s the cuplrit, the resume, I’ll just snip that one out
So now how does this correlate with @hackguy , @privacyfreak84 & @oliver111 ? they can’t all have the same set up right?
I have successfully booted into my newer kernel by removing the kernel command line that set the resume=(my old swap partition ID), and man does it boot quicker! 
!
@hackguy and @oliver111 should review their command line. As for @privacyfreak84 their problem is a kernel panic that needs further troubleshooting now.
Anyone who has configured hibernation (and possibly suspend) would likely have that resume in the kernel command line. It may be the issue for all and they should check it out.
I can see where that would be the issue and it probably exists in the GRUB_CMDLINE_LINUX= line in the /etc/default/grub file so gets written by default into the kernel command line when the kernel is updated.
I suspect the fix is to
resume part of the GRUB_CMDLINE_LINUX= linesudo grub2-mkconfig -o /boot/grub2/grub.cfgThe fix could be confirmed by also looking at the kernel command line with cat /etc/kernel/cmdline after performing step 3 and verifying the line has been changed as expected. If not then edit that file as well before rebooting.
Yes, that was the issue! What I did to fix it (DISCLAIMER: I tried various things until it worked, not all steps might be necessary):
/etc/kernel/cmdline, remove resume=UUID=... argument.dracut --kver 6.8.10-300.fc40.x86_64 --force as root./etc/default/grub, remove resume=UUID=... argument.grub2-mkconfig -o /boot/grub2/grub.cfg as root.So even though this was technically solved for the kernel update, I had the issue repeat after installing the test kernels. This confused me a bit, but it is due to the fact that the command line for the kernel is derived from the file /etc/kernel/cmdline which gets created when you install systemd-boot and set it up to boot your system, but never gets updated throughout the kernel updates since. So when I installed the recent 6.9.1 and 6.9.2 kernels to test them, I was left with an indefinitely waiting system, again. I have since removed the resume= line from the kernel args in the offending configuration file.
I have found out that for those using grub to boot the “grubby” command solves all this.
sudo grubby --remove-args=<the full string to be removed here> --update-kernel=ALL
That command edits all the affected files. /etc/default/grub, /etc/kernel/cmdline, /boot/loaders/entries/*.conf, and maybe even the grub.cfg file if needed. Thus the change works for the next boot regardless of which kernel is used as well as being integrated into the next kernel upgrade.
How it works for a systemd-boot system I cannot say.
Interestingly, it is sort of easier to do in systemd-boot. For every entry created, the kernel arguments are derived from /etc/kernel/cmdline file. If you need to change your commandline arguments you do it there if they’re intended to be permanent, or like with grub2, press ‘e’ to edit it at boot menu time for oneshot. You use bootctl to do pretty much everything admin related to the boot loader. It is more manual than Grub2 as far as in system setup and use. The one big caveat for most would be kernel updates don’t automatically select the new kernel for booting, you have to set it manually. But kernel updates are the only updates that will cause an entry to be added (which happens automatically) to the list of entries. It (systemd-boot) also doesn’t give a care about graphics display capability and is text only as far as menu.
That depends how you configure the loader.conf file. Normally, the entries are sorted according to name and version, and the top one is selected for booting. This would normally be the latest installed kernel.
I haven’t made any changes to that file, but after the kernel was updated to 6.8.9, my system didn’t automatically update it to boot as the new default, even though it was listed as first. But I did set the default to 6.8.8 while I was troubleshooting why the newer kernel(s) were supposedly hanging, maybe that interfered with the auto-assigning function. 