Issues with updating to kernels 6.1.5, 6.1.6, 6.1.7

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

@maverickofsurrey
Do you have a Realtek wifi?

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.

Another way to disable the wifi card that would be at a lower level than masking the service (but not quite as low as physically removing the card) would be to add something like modprobe.blacklist=rtl8821ae to the kernel command line. The rtl8821ae is just an example. You would need to substitute that with the right driver name for your specific wifi card. You could find the name in the output of the lsmod command while running one of your working kernels (I think all the Realtek WiFi card drivers should start with “rtl”). You can use modinfo -F description <driver-name> to view the description of any kernel module.

Masking wpa_service did enable me to boot into kernel 6.1.7. Once I unmasked the service I was able to check for updates. When I was rebooting the system got stuck at “Installing updates; this could take a while…”.

I forced a restart to grub and selected a fully-functioning kernel, then masked wpa_service again, before booting again into kernel 6.1.7, unmasking, updating via the command line and remasking. I have been able to update to 6.1.8 - but need to mask the wpa_service before logging off to retain access to that kernel. From running lsmod, there are a number of entries starting with rtw.

This type error is why I always disable (and mask) the automatic offline update.
systemctl disable packagekit-offline-update.service
systemctl mask packagekit-offline-update.service
This prevents the offline update during reboot and I am able to always control the updates personally rather than having the system decide when an update should be done.

1 Like

If masking the service works, then there is no need to use the lower-level method.

Also, you might be able to set a timeout on the wpa_supplicant.service instead of repeatedly masking and unmasking it. It would still be a workaround, but perhaps a less frustrating one. That service should not be blocking the startup of the system. If nothing else, I think you could file a bug report on that.

@maverickofsurrey
OKay looks like you figured out how to mask and unmask wpa_supplicant.service
This is what I suspected
This is a bug I think in the kennel or wpa_supplicant.service with the realtek wifi
Personally I am going to replace the wifi card with a Intel wifi card