I am not able to boot any of the 6.14 kernels. You can see the error messages in the attached image. I have never had that issue with previous kernels.
As a result, the boot process gets stuck and it does not go beyond the job dev-disk-by stage.
I have no immediate solutions, but this could be a kernel module error that would have to be fixed upstream.
Perhaps you want to list your hardware as well for information. You can install and use the command inxi for that to print an overview:
$ inxi -Fzxx
If you want to get a boot log more easily you can use the journalctl command with the -b parameter to show a previous boot, and -p for a specific error severity.
For example
# show log of previous boot
$ journalctl -b -1
# show log of 2 boots back
$ journalctl -b -2
# show log of previous boot and show only errors of the level [error] and [critical]
$ journalctl -b -1 -p 2 -p 3
Yes, it does seem like a tricky one. I have a hard time uploading all the output since the discussion board limits messages to a certain length.
Let’s start with inxi:
Apr 24 10:44:43 buba kernel: ee1004 4-0056: Failed to select page 0 (-6)
Apr 24 10:44:43 buba kernel:
Apr 24 10:44:44 buba /usr/bin/nvidia-powerd[1581]: Found unsupported configuration. Exiting...
Apr 24 10:44:45 buba abrtd[1690]: '/var/spool/abrt/Python3-2024-04-29-16:52:38-20372.new' is not a problem directory
Apr 24 10:44:45 buba abrtd[1690]: '/var/spool/abrt/Python3-2024-05-12-12:32:34-8163.new' is not a problem directory
Apr 24 10:44:46 buba abrtd[1690]: '/var/spool/abrt/oops-2024-12-11-09:44:16-2398-1' is not a problem directory
Apr 24 10:44:46 buba abrtd[1690]: '/var/spool/abrt/oops-2024-12-14-00:39:07-2412-1' is not a problem directory
Apr 24 10:44:51 buba firewalld[1687]: ERROR: NAME_CONFLICT: new_policy_object(): 'docker-forwarding'
Apr 24 10:45:08 buba polkitd[1583]: Error converting subject to JS object: Process 2575 terminated
Apr 24 10:45:08 buba dbus-broker-launch[1566]: Activation request for 'org.freedesktop.nm_dispatcher' failed.
Apr 24 10:45:09 buba kernel: watchdog: watchdog0: watchdog did not stop!
Apr 24 10:44:43 buba kernel: ee1004 4-0056: Failed to select page 0 (-6)
Apr 24 10:44:43 buba kernel:
Apr 24 10:44:44 buba /usr/bin/nvidia-powerd[1581]: Found unsupported configuration. Exiting...
Apr 24 10:44:45 buba abrtd[1690]: '/var/spool/abrt/Python3-2024-04-29-16:52:38-20372.new' is not a problem directory
Apr 24 10:44:45 buba abrtd[1690]: '/var/spool/abrt/Python3-2024-05-12-12:32:34-8163.new' is not a problem directory
Apr 24 10:44:46 buba abrtd[1690]: '/var/spool/abrt/oops-2024-12-11-09:44:16-2398-1' is not a problem directory
Apr 24 10:44:46 buba abrtd[1690]: '/var/spool/abrt/oops-2024-12-14-00:39:07-2412-1' is not a problem directory
Apr 24 10:44:51 buba firewalld[1687]: ERROR: NAME_CONFLICT: new_policy_object(): 'docker-forwarding'
Apr 24 10:45:08 buba polkitd[1583]: Error converting subject to JS object: Process 2575 terminated
Apr 24 10:45:08 buba dbus-broker-launch[1566]: Activation request for 'org.freedesktop.nm_dispatcher' failed.
Apr 24 10:45:09 buba kernel: watchdog: watchdog0: watchdog did not stop!
Two boots back seems to be tricky to post since it is too long and I cannot attach it as a text file. @litemotiv , what would be the best way to to share it with you?
You would only have to post the log for a boot that failed with the 6.14 kernel, it should probably not be very long since the boot fails quite early.
If you boot once with a 6.14 kernel and afterwards into a working 6.13 kernel, then the -b -1 parameter would show the previous (failed) boot. If you boot twice into a working 6.13 kernel then the -b parameter would show the log of a working 6.13 kernel, which wouldn’t be needed at this point.
Does that make a difference? If the log is still too long you can also use an online pastebin to temporarily save the log.
I just tried booting 6.14 and then come back to 6.13. It does not seem that journalctl is able to pick up the fact that I have tried booting 6.14. It only comes up with information about booting 6.13.
I just wanted to clarify that I get the exact same issue when trying to boot the Fedora live usb. I have a laptop that boots it without any problems and I have not had any issues with kernel 6.14 on the laptop.
Interestingly enough, our machines are in many ways similar. Mine has a 28-core i9-7940x + 128 gb ram + 1080ti, so both are high core count / high memory machines with higher end nvidia GPU’s. Also, both of our machines have the root filesystem on a nvme drive. Not sure why, but I have a gut feeling that i important.
I was able to get into a dracut emergency shell and look around a bit. The problem seems to be that a handful of kernel modules arent getting loaded because they fail to decompress properly. running dmegs/journalctl also tells me that iscsi was requested but that the kernel/initrd doesnt support iscsi (even though the dracut iscsi module is included and the iscsi kmods are present in the initrd).
a bunch of block devices are also missing from/dev. My sata HDDs are showing up ok e.g., as /dev/sda1). But, my nvme drives arent appearing as block devices, and plugging in a usb flash drive doesnt do anything either. Notably, /dev/disk is missing entirely. Assuming we are htting the same underlying bug, this would explain why your boot freezes on accessing /dev/disk/by-uuid/...
I finally managed to get kernel 6.14 to work on my machine. I needed modify the BIOS settings so that my NVME does not run in RAID mode. After making that change reinstalling the kernel was necessary. Now everything seems to run smoothly.