Apart from these errors, I also experienced “job dev disk by x2duuid device start running” running indefinitely.
What I’ve already tried
Ran dnf update.
Reinstalled all the kernels with dnf reinstall kernel\\*.
Removed “rhgb”, “quiet” and nvidia-related boot args with grubby --remove-args="rghb quiet rd.driver.blacklist=nouveau,nova_core modprobe.blacklist=nouveau,nova_core" --update-kernel /boot/vmlinuz-6.16.9-200.fc42.x86_64.
Important note
The system boots fine with kernel-6.15.10-200.
Just to be sure that the entry for that kernel remains available even after further updates, I’ve added installonly_limit=5 to /etc/dnf/dnf.conf (maybe not optimal due to the small EFI partition size, approx ~500mb, but correct me if I’m wrong).
Any help would be really appreciated, thanks in advance!
As James said, the kernels are stored in /boot. The default of /boot is 1GB. I use the default and always have 5 kernels, already for long. 1 GB is fine for that, I currently have 267,9 MB free in /boot despite 5 kernels being installed. So don’t worry about that part
Can you add at a working boot what the output of cat /proc/sys/kernel/tainted is? That could be relevant for interpreting the error of a broken boot, so you might add this to the bug ticket if you write one.
Given what you say, it is unclear if root has been mounted at all, but it might be worth a try and therefore, boot a broken kernel into a failed boot and check out the time when you do this (you might use your normal clock when it roughly corresponds to system time or so), and then boot a working kernel and get sudo journalctl -k --no-hostname --boot=-1 (-1 is the then-last boot, not the current one) and check if the broken boot is documented (by containing the errors you see or by the system time that is documented of the very boot that is output) or not. If it is contained, it definitely needs to be part of the bug report. Beyond, stick with the bug report template and ensure that all sections are filled with the requested data. If you test the rawhide kernel, ensure to have backups and such of your stuff, as this is experimental and should be considered as such.
I’ve added the line “blacklist intel_oc_wdt” to /etc/modprobe.d/blacklist.conf.
Then I’ve also installed the latest kernel available — 6.16.10-200 — which was probably released today.
I can confirm that upgrading the kernel probably helped, because on version 6.16.9-200 the boot phase only succeeded once. When I retried to boot a second time, errors and some long timeouts popped up like mushrooms (see pic below).
However, removing the blacklist file also prevented the new kernel from booting, due to the same RIP message you mentioned earlier. So your solution was definitely spot on.
Fun fact: the person you mentioned had the exact same PC as mine — only the processor differs (mine’s an i7-4790). Glad to see others still keeping these machines alive!
