openSUSE 15.3 occasionally freezes unexpectedly. The network becomes unreachable, and neither the graphical interface nor the command line responds. The only way to recover is to force the system to shut down and reboot. No error messages or relevant logs can be found after the reboot.
Could you please help analyze what might be causing this issue?
Welcome to openSUSE Forums. Unfortunately, the first question has to be why are you still using such an old version of openSUSE?
It went end of life on December 31, 2022
This may be a difficult one. openSUSE 15.3 is end of life since 2022-12-31. Which means that, while people may be willing to help you, they will not have that system running and thus may have to use their memory on how things were four years ago.
And of course many will advice you to upgrade to 16.0 first. Which will come down to a re-installation because upgrade of more then one step at a time is not really supported.
And of course you might try to provide more information. Was this always the case since you installed openSUSE 15,3, or is this since some event (update) you may remember, etc. It might be hardware that is falling apart.
Ability to start right back up and work normally after a freeze suggests a RAM stick may have gone bad.
When was this computer manufactured? Parts in old computers that arenât kept clean inside can overheat and cause such trouble. Even when kept clean, parts can fail in old age, e.g. fans, and especially electrolytic capacitors, particularly those inside power supplies, known to fail on occasion before âold ageâ.
Adjust the times to when the issue happens and provide the basic sysinfo.
journalctl --since â2020-11-15 10:27:00â --until â2020-11-15 10:28:11â
Operating System: openSUSE Tumbleweed 20260814
KDE Plasma Version: 6.7.4
KDE Frameworks Version: 6.28.0
Qt Version: 6.11.1
Kernel Version: 7.1.8-1-default (64-bit)
Graphics Platform: X11
Processors: 16 Ă AMD Ryzen 7 5825U with Radeon Graphics
Memory: 64 GiB of RAM (62.1 GiB usable)
Graphics Processor: AMD Radeon Graphics
Manufacturer: HP
Product Name: HP ProBook 455 15.6 inch G9 Notebook PC
If youâre still using 15.3, I suspect you have old hardware. Try cleaning it out. The requirements for 16.0 are on the download page. If you your system doesnât meet these requirements, there are alternatives to openSUSE.
Meh, that is just clickbait. No, you cannot install Leap on < .v2 CPU. But, one can still install Tumbleweed ( even 32-bits ) and keep the install very minimal. Done that on ancient hardware with only 2 GB of RAM. These âlightweightâ distros donât have different software. Actually they pull in packages from elsewhere ( f.e. Debian ). Also they come and go pretty fast
I assume the OP doesnât want the chaotic pace of Tumbleweed, hence, staying with Leap. Your other points are legitimate.
IF the OP has a CPU that has a < .v2 architecture, then TW or Slowroll are the only openSUSE options.
The main issue is that I havenât been able to obtain any useful log information, so Iâm not sure where the problem is or how to identify the root cause. Is there a better way to collect and locate the relevant logs for troubleshooting?
That is not going to be easy, since none of us here is using 15.3 anymore. And trying a dup to 16.0 is most likely not going to work, at least lead to issues that are hard to track.
Do not assume you do not have a hardware problem? Run a RAM tester for at least 4 passes, preferably all night long at least.
Dmesg is not persistent. Journal can and should be. It is if /var/log/journal/ exists, so journalctl using -b -1 option may have something that helps.
Even if that passes OK, it will not solve the issue of the OS being way past its EOL, but yeah
ssh from another machine into 15.3. Become root, issue, in a screen session, âjournalctl --followâ. 15.3 might die on you, or just become unresponsive, but you would have the output of journalctl. Besides that, if youâre running a screen session, you might be able to open up another tab (^A, from the top of my head?) and maybe investigate?
To keep the ssh-session alive, you might have to put this in /etc/ssh/ssh_config.d/99-local.conf:
Host *
ServerAliveInterval 60
Or perhaps another value? See man ssh etc. for more info about ServerAliveInterval.
Another option might be to send the logs to another machine.
Kind regards,
Leen