My problem boils down to what I wrote in the Heading.
I can boot my laptop, but I cannot get past gdm, since as soon as I type in the password (or sometimes a bit after) the computer becomes unresponsive. I am running a fresh install of fedora 42 Workstation and essentially ran sudo dnf update and the system is broken.
A typical boot into the broken state starts with the same error. I have no clue how to use journalctl to find the source of the problem, that’s what I am here for, but the output of journalctl --since=today -p3 always starts with the same line.
Oct 07 19:20:54 fedora kernel: platform AMDI0020:00: AMD-Vi: [Firmware Bug]: No ACPI device matched UID, but 4 devices matched HID.
I have already looked around the internet and tried some different options when booting, unfortunately with no success. I would be very grateful if you help me with this, I need my laptop for Uni in 4 days.
Reboot into Linux and try to log in as normal. When the system appears to be unresponsive, can you switch to a spare TTY with Ctrl+Alt+F2 or F3 (doesn’t matter which Fn key you use).
If you can, log in and run fpaste --sysinfo and note down the URL it gives you.
Dive back into Windows and paste that URL in here.
If you truly have a completely crashed and unresponsive machine we might have to get a little tricksie with a Live USB image, so you might as well make suer you have one to hand when you’re in Windows…
Hi, thanks for your quick reply! I have already tried out going to tty but it sadly did also crash after running a command. Maybe I can get lucky and get the command to run, but I am pessimistic.
EDIT: I can log in, but as soon as I hit return on the command it has the blinking underscore, but nothing happens
OK - boot into linux - try to log in and watch it hang. When it does, try hitting Ctrl-Alt-Delete to try to encourage a clean shutdown by anything which may still be listening.
If it fails to shutdown encourage it more vigorously, by resetting the machine
I’m hoping that may have left some information about what is happening in the journal.
When grub pops up after the reboot, edit the kernel parameters and append systemd.unit=rescue.target at the end. That will perform the next boot in rescue mode - it only starts up services that are essential. The filesystem will be read only to begin with and I don’t think there will be any networking, but you can always try the fpaste command from there. It’ll give us something to work with.
If there is no networking started the next best option is to dump the journal to the screen and take a picture on a phone. something you can easily paste in here. So…
Run the command journalctl --no-pager --no-hostname -b -1. This will display the journal for the previous boot - the one we just had fail on us. Take a picture and paste it in here.
OK - nothing massively interesting in the log other than a little bit of amdgpu weird mesages.
Can you try booting with the kernel parameter nomodeset added to grub init line. At the grub screen, hit e to edit the kernel parameters and scroll to the end of the of the vmlinuz and add nomodeset to the flags and settings which are already there. It’s a temp change and will only last for this specific boot.
OK - I’m assuming that now we delay the modesetting of the amdgpu driver you can log in and actually use stuff.
That implies it’s the amdgpu driver which is causing the issues.
Let’s have a look at the output from inxi -Fzxx to get a detailed look at your hardware and see if there’s any reason why whatever kit you have in this machine is causing such issues. If nothing else, it’s a record of “this kit doesn’t play well with this version of this software” for other to find and give me a chance to poke around on the net for others with the same issue and equipment.
Whilst I have a little bit of a hunt for better solutions, you can encourage grub to always apply the nomodeset parameter to every kernel with the command sudo grubby --update-kernel=ALL --args="nomodeset" (I believe this is the correct command, I’ve never had to use it myself).
Hi Flynn, did you have any success looking into the problem?
I know, you are doing this in your free time, so do not feel pressured to do anything, but I feel kind of lost with that issue.
I have been using fedora for about one and a half years on this computer - without problem, but now Linux just seems to turn on me.
It has definitely something with the 2 most recent kernel updates, i think kernel 6.16.8 or earlier worked for me. Is there something that you can recommend, so that I can use my work computer for the semester?
I did have a bit of a poke around - didn’t really find anything conclusive though.
I’m not an AMD GPU user so I don’t have the drivers installed at all, therefore I don’t know how frequently they get updated aside from being kept in step with the kernel releases.
By using the kernel parameter nomodeset you’re telling the kernel to not try to fire up and initialise the AMD GPU when the kernel starts - let the drivers do that for themselves when they get loaded and turned on. You probably end up using software rendering - llvmpipe.
Assuming that they do that, as you now get a display and can log in, you should be able to use them as normal - setting up graphics modes, colour profiles and video resolutions.
Are you saying that’s not working for you and you’re stuck in some low resolutions blurry mess of a desktop?
I see - as my mother would have said, that’s NFG.
The poor performance will be because you’re not loading the amdgpu driver (as it isn’t playing nicely with your iGPU and this current kernel series) and are falling back to software rendering - Gnome is probably telling you that it’s using llvmpipe I imagine… there’s some Gnome panel that displays that but no idea how to tell you to find it.
Try running a firmware update - we might strike lucky.
Could also try a boot with amdgpu.dcdebugmask=0x10 (remove nomodeset so the real amdgpu drivers get used and get fed this parameter).
No idea what it actually does but it seems to have helped someone in this issue with the same CPU/GPU as you. Kernel 6.12 15 worked well for them it seems and 6.13 series introduced regressions.
well good news. I have run all the commands on another clean f42 install and now it works .
I was pretty sure, that I have already tried out this kernel option in my initial troubleshooting attempt, but maybe I had a typo or the above commands had an impact also.
So thank you very much!
Also I may be traumatised now and always think that my laptop froze if the display does not update for a few seconds
EDIT:
Well it crashed again after a while of using it without problem…
now it works 