Cant shutdown the system!(Fedora crashed)
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
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.
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?
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:20Old 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).
Not sure if this the display manager is the issue, but SDDM is the other "big player".
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.
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
Maybe post the entire DMESG just in case.