7mo ago

Cant shutdown the system!(Fedora crashed)

I have been facing this issue since yesterday, but basically at some point the system becomes insanely slow, and the restart and shutdown options disappear from the menu, tty3-7 dont work, it freezes at the shutdown -now command(at which point I just manually cut the power(bad Idea I know)),

but today I stuck around as my system got insanely borked, eventually freezing up and giving me the screen above. the problem shows up after I wake it up from suspend but not always: My system specs:

    
OS: Fedora Linux 41 (Workstation Edition) x86_64 
Host: TECRA R940 PT439V-03U02WAR 
Kernel: 6.11.10-300.fc41.x86_64 
Uptime: 23 mins 
Packages: 2282 (rpm), 43 (flatpak) 
Shell: bash 5.2.32 
Resolution: 1600x900 
DE: GNOME 47.1 
WM: Mutter 
WM Theme: Adwaita 
Theme: Adwaita [GTK2/3] 
Icons: Adwaita [GTK2/3] 
Terminal: gnome-terminal 
CPU: Intel i7-3540M (4) @ 3.700GHz 
GPU: AMD ATI Radeon HD 7550M/7570M/7650M 
Memory: 1845MiB / 7879MiB

here are the journalctl entries that I think are relevant

entries for events 40 min before that.

and this is from when it happened earlier in the day

20 comments

So, this is a ~15 year old laptop?
The first two things that immediately come to mind when you're kernel panicing is bad ram, and bad cpu temperatures.
Thermal paste doesn't last forever, and it's worth checking if your CPU or GPU are overheating, and repasting if so.
And, as always, a memtest is a quick and easy step to rule that out - I'd say half the "weird crashes" I've ever seen ends up being bad ram and well, at least it's cheap and easy to replace?
- This is not a malfunctioning hardware thing. I faced the same issue for a few days on silverblue, where my 2 year old zen3 laptop would slow down to a crawl and eventually the gnome-shell would freeze. Somehow it resolved itself somewhere between kernel and gnome-shell + mutter updates
Can you enable SSH, and then try SSH into the box once it hangs?
Any OOMKiller messages in dmesg/journalctl? Do you have swap space?
Nothing in the logs jumped out at me, hopefully someone else can help you.
- No i dont have another system that I can ssh with right now, There are some OOM messages before the timestamps in my first paste, I have edited the post to include more journalctl entries, yes I have a swapfile.
  
  If you're on Android then you can use Termux (via F-droid) to get ssh capabilities. I think there is also a different iOS app, but I'm no expert on that OS, so I can't tell you its name. If you have a smart phone then you might have a ssh capable system after all
  
  There are android clients, probably one for iOS as well. If you are getting OOM killed, you need to work out what is using all your memory. The OOM killer is pretty indiscriminate, and will murder processes randomly.
  Maybe keep system monitor up and keep an eye on memory usage?
The KMS timeouts almost make me wonder if the graphics chip is snorting some sort of crack.
Just to be safe, maybe try booting a live USB and see what happens. To be very sure, you could even try multiple distro/DE combos on the live disk.
If it's RAM, it should be easily replaceable on a laptop of that age. If it's the graphics chip, then it's probably time to find some other laptop. You can probably still press this to service in a homelab, though.
Try changing the Display Manager from GDM to something like LightDM. There are some issues with GDM on some systems.
- LightDM last stable release was 2 years ago, are there any other options available?? going through journalctl entries these seem to popout to me Vulkan: ../src/amd/vulkan/radv_physical_device.c:1984: Device '/dev/dri/renderD128' is not using the AMDGPU kernel driver: Invalid argument (VK_ERROR_INCOMPATIBLE_DRIVER)
  
  JS ERROR: TypeError: this.actor is null _syncEnabled@resource:///org/gnome/shell/ui/windowManager.js:144:25 onStopped@resource:///org/gnome/shell/ui/windowManager.js:161:35 _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:65:22 _easeActorProperty/<@resource:///org/gnome/shell/ui/environment.js:247:60 _destroyWindowDone@resource:///org/gnome/shell/ui/windowManager.js:1611:21 onStopped@resource:///org/gnome/shell/ui/windowManager.js:1579:39 _makeEaseCallback/<@resource:///org/gnome/shell/ui/environment.js:65:22 _easeActor/<@resource:///org/gnome/shell/ui/environment.js:160:64 @resource:///org/gnome/shell/ui/init.js:21:20
  
  Not sure if this the display manager is the issue, but SDDM is the other "big player".
  
  Old isn't necessarily bad. Also, as far as I can tell, distros are still patching 1.32. Based on my personal usage of LightDM and the fact that the project is still developed (based on commits to main), I'd say it's more of an "if it ain't broke, don't fix it" dynamic. As for security, the active development suggests the developers would respond if there was a vulnerability - a big if, considering its last CVE was in 2017.
  Personally, I love LightDM - it has just enough features while mostly sticking to its name (I mean, you're probably using GTK anyway).
Hey are you still facing this issue. I also faced this twice on fedora 41 silverblue but it seems to have resolved itself after some updates
- I am I just dont suspend anymore
  
  That is one solution lmao
What about dmesg? if it's a hardware problem (and it looks like, but I may wrong) dmesg will print some usefull data

sudo dmesg -Tw
-T form human redeable timestamp and -w to follow (like tail -f)
Also, about that hard reset that you did, Linux magic keys are your friends if your are not facing a kernel panic, I have this key combo engraved in my head like a rune:
Press and hold Alt + PrtSc (not Alt+Gr) and then press only one time each (and while holding Alt + PrtSc) E + I + S + U + B
PrtSc maybe be SysRq in your keyboard depends on the manufacturer, architecture or how old it is. Also wait one or two seconds between keys when pressing EISUB.
Edit: the rune in my head was wrong, fixed it
- What about dmesg? if it’s a hardware problem (and it looks like, but I may wrong) dmesg will print some usefull data
  I tried sysrq then, now i know why it didn't work sysrq: This sysrq operation is disabled.
  nothing useful in dmesg, at least to me
  
  Looks like SysRq keys are not enable in your distro by default, don't know the reason but Fedora kernel devs would known better than me.
  Just for curious, did you installed some gnome extension recently? try this
  
  grep -i gnome-shell /var/log/syslog* | grep -i exten
  
  Maybe post the entire DMESG just in case.

20 comments