I’ve had to revert to earlier kernels as updating to each of the above puts my system into the position of not being able to get as far as the account login screen. I am able to enter the hard disk encryption password but the system hangs. I would appreciate guidance on how to resolve this, please. Thank you. I had removed the problem kernels via the command line.
Did you find this earlier post? It might be related.
1 Like
I have not been able to access the full post - so no details on full path and terminal commands that will need to be run. My system runs Fedora 37.
You’ll probably need to find an error message of some sort before you’ll be able to successfully troubleshoot the problem. If you remove quiet and rhgb from the kernel command line you should see more information about what is happening when the system fails.
1 Like
What is the path for the kernel command line?
I think it can be a little different depending on which bootloader you are using, but assuming you are using the default grub bootloader, I think you can get to it by pressing e while the kernel you want to boot is highlighted. It should bring up an editor of sorts and some grub bootloader code. Scroll to the line containing the word linux and at the end of that line you will probably find the words rhgb (Red Hat graphical boot) and quiet. Backspace out those two words and then press Ctrl x and I think you should see a lot of status messages as the system boots. Hopefully one of the messages near the end will give some indication as to what has gone wrong.
(Sorry that working with the grub bootloader is so complex. Some of the others are better in that they just show the kernel command line and nothing else when you go into edit mode.)
1 Like
Thank you. The last line that 6.1.7 gets to when loading is “amdgpu 0000:05:00.0: [drm] fb0: amdgpudrmfb frame buffer device”.
That sounds like a problem with the video driver then. Can you boot if you add nomodeset to the list of kernel parameters? That should cause the video driver to run in a “fallback” mode with limited abilities (e.g. no 3D rendering or video acceleration). You probably don’t want to keep it that way, but if it works, then that would be a pretty solid indication that the video driver is the problem.
P.S. If nomodeset does work, then (based on this report) it looks like the problem might be due to an incompatibility between your AMD firmware revision and the amdgpu driver.
2 Likes
With the addition of nomodeset, the loading process freezes at started wpa_supplicant.service. What step should I try next?
That sounds like a pretty late-stage service. At that point, whatever the problem is should be logged in the system journal. So boot it up once with the failing kernel and nomodeset, then reboot into a known-good kernel and run journalctl -b -1. The -b -1 should cause it to show the bootup logs for the previous boot. Again, hopefully you will find a helpful hint as to what went wrong near the end of the log.
From running the journalctl command, the last line of output is fedora kernel: NX (Execute Disable) protection: active
It’s not necessarily the very last line of the journal that indicates what went wrong. Are there any slightly earlier lines that look suspicious?
The preceding entries are about usable, reserved memory, ACPI.
Well, ACPI (power management) could cause that sort of hang. You might try adding acpi=off to your list of kernel parameters if you suspect that that is the problem.
Also, since you are getting past the switch root phase, you should be able to add 3 to the list of kernel parameters (in addition to nomodeset) and then you should be able to sign in on the system in text mode. At runlevel 3, you should have multiple virtual terminals available. You can switch between them by pressing Alt F2 for virtual terminal 2, Alt F3 for virtual terminal 3, etc. Among the text on the VT should be a tty2 or tty3, etc. indicating which virtual terminal you are on.
So, I would try this. I would boot into runlevel 3 by adding 3 on the kernel command line, switch to VT 2 by pressing Alt F2, sign on at the text prompt, and then on VT 2 enter sudo journalctl -f. That last command will open the system log files in “follow” mode where every newly logged event will be written directly to the screen.
Next, switch back to VT 1 by pressing Alt F1, then sign in again on that terminal and enter sudo init 5. That last command will cause the system to continue booting to full graphical mode, but you will still have a console open on VT 2 that you can switch back to and try to troubleshoot the problem when it hangs. So after you enter sudo init 5, press Alt F2 to switch back to virtual console 2 and you should see events being logged as the system trys to init into full graphical mode. Watch for anything that might be an error code (e.g. some errors might start with EE, lines that are color-coded red are also errors). While journalctl is still running, you can press Shift PgUp to scroll back thought the history. If you see something that might be a clue as to what went wrong, you can press Ctrl C to cancel the journalctl command and go back to the command line and perhaps correct the problem (e.g. by tweaking a line in a configuration file or restarting a system service).
Also, you can go back and forth between runlevel 3 (multi-user mode) and runlevel 5 (graphical mode) by entering sudo init 3 or sudo init 5 as necessary without haveing to reboot the whole system and edit the kernel command line each time. When you change runlevels, it will often auto-switch the focus back to VT1, but you should always be able to switch to another terminal with Alt F<1-6> to troubleshoot and restart things unless it is really hung.
1 Like
FYI, it looks like AMD has been working on the iommu subsystem in recent 6.1 kernel patches. You might try adding amd_iommu=off instead of nomodeset to the list of kernel parameters. I think that has worked around similar bugs in the past.
Using 3, nomodeset and acpi=off, started WPA_supplicant.service is still the last message showing. An earlier message from there shows “No native access to PCI extended config space, falling back to CSI”.
Never be afraid to trust an unknown future to a known God.
Corrie Ten Boom
Yes, the laptop does have a Realtek wi-fi adapter.
Can You remove it and try booting?
I had a similar problem and after removing the wifi card it worked Problems launching Fedora
You can also try masking wpa_supplicant.service
sudo systemctl mask wpa_supplicant.service
Just don’t forget to unmask wpa_supplicant.service
sudo systemctl unmask wpa_supplicant.service
I think it would be better to remove the wifi card and try booting
How do I disable the WiFi card? I’ve gone through the settings but can only find airplane mode.