I downgraded to 6.7.11-200 through koji and also downgraded amd-gpu-firmware to 20230919-1 (the version for Fedora 39). Only issue I ran into was that the perf package needed a version of perl that nothing provided, so I installed the kernel packages with --skip-broken and skipped perf. I’m still seeing the same issues and same messages from dmesg and vainfo.
At this point I’m thinking the issue has to be independent of the kernel, since when I originally got an emergency shell on boot, switching to older, known good kernel versions didn’t fix the problem.
dnf has a rollback command. You could try using that to revert all the packages on your system to the versions that they were at before the problem first appeared.
I figured out what the problem was, but only after reinstalling my system. That installation script I mentioned in the OP has one part where it extracts a tarball containing lib, usr, and opt directories into the root directory. Since /lib is a symlink, it gets overwritten by the lib directory in the tarball.
Reinstalling all packages restored some of the contents of /lib, but apparently many packages write directly to /usr/lib, so that explains why things like reinstalling the firmware package and changing package versions had no effect. I’ve sent the site maintainer an explanation of the problem, as well as a version of the script that doesn’t overwrite /lib, so hopefully this will be a non-issue for others.
I had the same CPU problem. I don’t know what you mean by “reinstalling my system”.
The only way I could get enough CPU to type this was to install x11 (took a while to type “dnf install plasma-workspace-x11”) and switch to that. Solved the CPU problem and I won’t be goung back to wayland.
Writing the same files multiple times is certainly an issue.
However, your solution has its own problems. What if one package uses /lib and another uses /usr/lib for the same file? Or if one package uses only /lib and your script prevents writing those files?
Yes, /lib should be a link to /usr/lib (fedora has used the /usr/lib path for many years and added the /lib link since many packages that originate in the Debian or Ubuntu world used [or still use] only /lib for installation.) There very easily may be packages that depend upon the /lib path for installation and even to be able to run.
In another post in this forum the problem located was mesa driver update from 24.2.4-1.fc41 to 25.0.1-2.fc41. The fix was to downgrade: sudo dnf downgrade mesa