after starting my laptop I realised, that during the booting process the screen where I have to enter my passphrase to decipher the hard drive has changed. Before it was a black screen with a field in the center where I enter the password. Each character was shown as a dot. Now this screen has changed to grey and I have to enter the passphrase in the upper left corner. By starting to enter the passphrase, the request to enter the passphrase vanishes. Characters of the passphrase aren’t shown neither as symbol nor as dots. In addition, the process of booting is extended. Moreover, my system runs slow with irregular lags. When the system switches to power saving mode, the screen doesn’t turn off. It’s black but with low lighting.
Technical data:
Fedora Linux 44 (Workstation Edition)
Lenovo ThinkPad L14 Gen 5
AMD Ryzen™ 5 Pro 7535U with Radeon™ Graphics × 12
How can I fix those issues? Is this caused by a virus or spyware? I’m new to fedora and appreciate if you try to explain it in an easy way.
It sounds to me like your video driver is not working. It is falling back to an older and simpler system.
Can you boot with the previous kernel?[1] Usually, if there is a problem with a video driver update, holding back and using the previous one until the next update is a viable workaround.
I would strongly advise against it. You will buy into a myriad of new bugs, which is not gonna help you fix the first bug. Moreover, kernel and video drivers will be the same, so really no added benefit. Do not upgrade before release (or 2 months after release).
Yes, the video driver also handles power-save modes for the video card. That problem might be related. Were you not able to boot with the previous kernel that worked?
Okay! I haven’t tried it yet. Don’t no how it works and don’t want to destroy anything. I wait until the next update and hope it will work. If the problem can’t be solved with the next update, I’ll try it.
Beyond what Flo already said, this is a bad idea for more dangerous reasons: on one hand, this is beta, not release. The user did not indicate they are fine with that nor aware of the implications of beta, which they should be before starting to use beta on what seems a production system.
Second, most importantly in this case, the upgrade process is highly complex: when the system has noteworthy bugs that are not understood, it already shows that the user has a situation that likely is not considered+identified in our testing, and thus in our testing of this complex process. Upgrading a failing system, without understanding the bug, is generally not a good idea, at least not before the bug is better understood, and in any case, troubleshooting should not start with upgrading to beta.
There is a new kernel and a new firmware about to come, both fix AMD bugs: there are some noteworthy bugs around AMD. But the critical one that users “experience” is for the AMD 680M, while your 7535U seems to have a 660M. But I would still not exclude that some of the bugs might cause issues on other systems, especially if the gpu is a related one. Several things of AMD will be reverted.
In order to keep this simple, you might just want to go to the last working kernel (I strongly suggest to test if the more recent kernel is affected → if your issue was introduced with 7.2.5, it would support the theory, though the actual issue is not in the kernel but the initramfs that is created from firmware during kernel installation). If that (older kernel: likely 7.2.4?) mitigates the issue, just wait for the next update: however, the next kernel update itself might not auto-solve the issue if it’s firmware related…
I will update it in the next days, once the new firmware (that reverts several AMD changes that cause issues) is out, and I will add some commands that will ensure the recent kernel is installed and that it will be using the new firmware (which does not automatically happen if both are “just” updated unless the new firmware was already there before the next kernel is installed).
I hope these AMD cases can be closed on the weekend or at least early next week…
If you want to invest the time, you can try the mitigation of the other issue, if you feel safe about that: Fedora 44 kernel 7.2.5 causes AMDGPU display problems and HDMI failure on ThinkPad T14 Gen 3 - #6 by py0xc3 (you can also use downgrade without koji rpms IF you enable the update-archives, if that makes you feel safer) → that would also help to identify if the origin of your issues are the same, but only if you test in advance which of your currently installed kernels (so those who can choose when booting) work or not work before testing this. My expectation is that 7.2.4 work, 7.2.5 does not, but if you do the mitigation I elaborated, 7.2.5 will work as well. So, that’s my guess
Final solution for those with the 680M problem (issues about the solution, please in the topic I posted it and add the data I requested for that case!):
Maybe it also solves the issue here with the 660M, would be worth a try, and feedback (here in this topic) would be appreciated if it also solves the 660M issue as it would add useful information for us
