I have a laptop which sometimes freezes like that. In my case, it seems to be a graphics driver issue. When freezes happen, it is usually at the time the screen is returned from dim to full brightness. So I configure power settings to never do that. Now it mostly happens during boot, before those power settings take effect.
You issue might be completely different. I would guess that graphics driver issues are a possibility.
If your system just freezes,
You can open a console and run “journalctl -f” continuously (and visible on the Desktop).
That way, should your screen freeze, you’ll see the last entries display before freezing
journalctl -f
You can also inspect your syslog of previous boots to see what was happening leading to your forced shutdown, for instance the following will display the previous boot with the last entries displayed first
I only knew the “journalctl -b -p err” and had learned it here. And I thought journalctl can only track the current boot. So today I learned “-r -b -l” can display the last boot.
The difficulty to find out the source of my freeze problem is it is hard to reproduce since it’s random and not often. Especially, after I had switched the rendering background in KDE settings to opengl 2.0 from 3.0, it seems the freeze has stopped appearing but I need to wait a bit more to decide it is really gone.
Is it a complete freeze, or can you ssh in from elsewhere?
For me, the main cause of repeated crashes have been hardware/bios related.
For freezes where I can ssh in, it seems to be graphics-driver, graphics-driver/kernel interaction, or X11 bugs (using nvidia’s drivers).
The last time chrome caused crashes I eventually figured out my BIOS settings had been set to “optimise” performance. I think some power optimisations were the cause of the instability. For me this always happened when I visited and ran the old flash version of speedtest.net.
On one other system blowing the dust and out and re-seating components brought stability for another year (the PC was getting up toward a decade old).
Recently chrome was giving me a few CPU hogging issues (beta version) where disabling chrome’s settings -> advanced -> system -> use hardware acceleration helped. But it appears OK now, but I also disabled many chrome extensions, updated chrome, and recently switched to tumbleweed (just for fun), so I’m not sure what fixed it.
Same thing in my HP probook 450 g2 laptop but i think it’s related to UEFI mode as my friend use same laptop, same leap 15 but in bios mode and never faced this issue .
I do have exactly the same issue with constant complete freezes (fresh Leap 15 install using KDE Plasma). Sometimes the freezes happen already during boot and before the login screen (I doubt that the WM is to blame?). None of the log files I have been checking since the early days of Suse (I am literally a 20+ yrs Suse user) to identify issues seem to show anything of bigger concern; yes I do have the usual Bluetooth warnings and many QXcbConnection errors which supposedly are of no concern.
The system completely freezes up; no X Server restart possible; mouse can be used, tty1 etc. is available, but system freezes on tty1 as well, after entering root UID and before the password query. I am wondering if the system is actually frozen or just slow to the infinity? After a few such crashes / restart cycles the system can run for hours without an issue, i.e. my suspicion is that it is related to some routine cron job, but I cannot see a pattern in the occurrence of the crashes.
Older stock hardware (my overclocking times are long over etc.):
i7-920 (LGA1366)
Asus Rampage II
Leap 15 on brtfs SSD (Crucial)
48GB RAM
no overclocking
Radeon HD 5770 (at this point still default Suse Driver to minimize causes of crashes)
The same computer runs solid/stable for ~5 years on OpenSuse 13.2 which I have on a completely separate SSD while trying each Leap independently. Quite frankly I have had issues on all my SUSE computers/servers since the introduction of the Leaps @ 42.1 and that’s why I keep 13.2 where it really matters as long as I can somewhat get newer sources compiled.
P.S.
Leap 15 as update from 42.3 (updates since 42.1) runs rock solid on my modern compute machine (LGA 2011-v3) as well.
There are probably many different causes of freezing.
I have two systems that freeze, though not often enough to be a big problem.
For both of them, the graphics system seems to be involved.
I’ll describe what happens, mostly to illustrate the differences.
System A: This is a laptop with Intel SandyBridge graphics.
When this system freezes, it freezes hard. Everything stops. I cannot ping the system from another computer. Or, more accurately, there is no response to ping.
As best I can tell, the freeze has to do with dimming the display. Dimming the display is okay, but when it reverts to full brightness, it freezes.
System B: This is a virtual machine under KVM. According to Bug 1103426, this is due to using QXL video emulation on the virtual machine.
When system B freezes, I can still ping it. I can use “ssh” to login from another machine. The command line still seems to work for the “ssh” session. But I am unable to restart the graphics. And if I try to restart the graphics or to shutdown the system, it usually hangs.
I have a hurricane moving into my area and needed to prepare the house / plan a potential evacuation (East Coast SC).
My money is always first on the graphics card & driver as well, however, this time there are no error messages in the X logs (KDE+Wayland freezes as well) and tty freezes as well. In the past when I had issues with both NVIDIA and AMD drivers, there were hints in the logs or I could just restart X without a hard power off.
Strangely, these crashes go hand in hand with snapper issues (btrfs snapshots) during most of the reboots. So far, I blamed the issues on new snapshots being corrupted during the freezes, but I am wondering if snapper may not trigger the freezes in the first place? I am tempted to look into snapper? I just thought someone had some advise where to look for some out-of-the-ordinary logs.
P.S. If the test would not come up negative, I would almost think there is some hardware issue with the SSD? I can “rule out” the RAM because 13.2/memtest runs fine.
O.k., now I cannot even get into Leap 15 anymore. It freezes within the first minute or two after a successful login. Only power off works. This is true for both the graphical environment (KDE and my favorite lean IceWM tested) and the text mode. Something is seriously corrupt. I may have to stick with 13.2. even longer and try a full reinstall of Leap 15 (used the DVD, will try the NetInstall next) before moving on.
if all desktops fail
it could be a hardware issue they do tend to break
I’d say check the hard drives smart status using smartmontools https://software.opensuse.org/package/smartmontools
you can check the RAM using memtest86+ https://software.opensuse.org/package/memtest86+
depending on your gpu I’d say check your gpu temperature also your cpu’s temperature (there are widgets and apps that can do this)