System freezes at shutdown/reboot (Leap 42.2/KDE, UEFI-type install)

English Install/Boot/Login
#1

I’m new to this forum, sorry for asking things that might have been answered before; however, no success with forum search.

I have taken the step from Windows (power user) to Linux 1/2 year ago, testing several distros like Linux Mint Cinnamon, Ubuntu, Linux Mint KDE, Kubuntu and now openSUSE Leap 42.2 with KDE desktop. openSUSE Leap to me currently is the most polished KDE implementation, plus several more positives like more technical orientation, detailed system management etc. However, I need to resolve a couple of issues before deciding to stick with Leap for a long-term installation.

Issue - maybe the Install/Boot/Login subforum isn’t exactly the right place to post this: The Leap/KDE system freezes at shutdown or reboot!!! The graphical (KDE) desktop just dims, then freezes. The only way known to me is pressing the power button off for a couple of seconds … ugly. The system even does not turn the desktop off anymore, nor does it go to the text mode tty thereafter. I DO just hope there is no loss of data on the SSD…

The Leap 42.2/KDE system is freshly installed on a Hewlett Packard EliteBook 8560w in UEFI boot mode with GRUB2. Here’s the inxi info:

inxi -Fxzw
Resuming in non X mode: xdpyinfo not found. For package install advice run: inxi --recommends
System:    Host: susy422-et.suse Kernel: 4.4.57-18.3-default x86_64 (64 bit gcc: 4.8.5)
           Desktop: KDE Plasma 5.8.6 (Qt 5.6.1) Distro: openSUSE Leap 42.2
Machine:   Device: laptop System: Hewlett-Packard product: HP EliteBook 8560w v: A0001C02
           Mobo: Hewlett-Packard model: 1631 v: KBC Version 01.3F
           UEFI: Hewlett-Packard v: 68SVD Ver. F.61 date: 05/25/2016
Battery    BAT0: charge: 37.0 Wh 95.0% condition: 38.9/38.9 Wh (100%)
           model: Hewlett-Packard Primary status: Charging
CPU:       Dual core Intel Core i5-2540M (-HT-MCP-) cache: 3072 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 10376
           clock speeds: max: 3300 MHz 1: 806 MHz 2: 843 MHz 3: 1797 MHz 4: 859 MHz
Graphics:  Card: NVIDIA GF108GLM [Quadro 1000M] bus-ID: 01:00.0
           Display Server: X.org 1.18.3 drivers: nouveau (unloaded: modesetting,fbdev,nv,vesa)
           Resolution: 96x51
Audio:     Card-1 NVIDIA GF108 High Definition Audio Controller
           driver: snd_hda_intel bus-ID: 01:00.1
           Card-2 Intel 6 Series/C200 Series Family High Definition Audio Controller
           driver: snd_hda_intel bus-ID: 00:1b.0
           Sound: Advanced Linux Sound Architecture v: k4.4.57-18.3-default
Network:   Card-1: Intel 82579LM Gigabit Network Connection
           driver: e1000e v: 3.2.6-k port: 5020 bus-ID: 00:19.0
           IF: eth0 state: down mac: <filter>
           Card-2: Intel Centrino Ultimate-N 6300 driver: iwlwifi bus-ID: 25:00.0
           IF: wlan0 state: up mac: <filter>
Drives:    HDD Total Size: 500.1GB (29.0% used)
           ID-1: /dev/sda model: Samsung_SSD_850 size: 500.1GB
Partition: ID-1: / size: 126G used: 8.7G (7%) fs: ext4 dev: /dev/sda2
           ID-2: swap-1 size: 20.14GB used: 0.00GB (0%) fs: swap dev: /dev/sda6
Sensors:   None detected - is lm-sensors installed and configured?
Weather:   Conditions: 52 F (11 C) - Overcast Wind: From the WSW at 12 MPH
           Time: April 21, 2:09 PM CEST (Europe/Berlin)
Info:      Processes: 177 Uptime: 0:38 Memory: 885.9/15992.5MB
           Init: systemd runlevel: 5 Gcc sys: N/A Client: Shell (bash 4.3.421) inxi: 2.3.8

Thanks in advance for your help, which could be (1) a full solution to this, (2) some tips on how to gather information from log files on what went wrong, (3) some tips on whether one could get the system to shutdown after such a freeze without using the brutal power-off button.

Just this further remark: I want the UEFI multi-boot capabilities, since I have Linux Mint 18.1 CInnamon and WIndows 10 in parallel. The HP EliteBooks from the WIndows-7 era like my 8560w are still quite popular, but they are very stubborn regarding UEFI boot even with a BIOS/ROM update from May 2016. Yet, I managed to work around those boot problems.

#2

More by incidents than systematic trials, I did find at least one / the conditions when the system freeze happens:

Asking Leap 42.2 KDE to shut down (the standard graphical “off” button) and letting the ensuing 30-second timer run out causes the Plasma desktop to merely dim and then freeze. No chance for any keystrokes like Ctrl+LeftArrow (once or twice) to shut down the graphics system, Ctrl+Alt+Fn to switch fronm graphics to terminal n, Ctrl-Alt+F2 followed by Ctrl+Alt+Del to switch to terminal and then call for shutdown. No way except the very brutal pressing the laptop power button for a couple of seconds.

The same happens when asking Leap 42.2 to reboot and letting the ensuing 30-sec timer run out.

My take is that either the Plasma Desktop or any underlying graphics system freezes rendering the entire system inaccessible.

I refer again to the system configuration printed in the first post here. In particular, I should like to mention that the laptop was running in stand-alone when these freezes happened, i.e. no docking station, no external monitor and no other peripherals like printer, scanner etc. Power supply was external, not on battery.

Again, my questions: Anybody else seeing such things? Any remedy? What would be a good way to let KDE or openSUSE people become aware of this?

#3

To know possible reasons, try command “reboot” from terminal using root. Before rebooting (or going to freeze…), system should print some messages. Either successfull reboot or not, it should give some answers. For example, if success, then problem is really with graphical layers.

#4

Yes, did so. No failure, successful reboot. The system shuts down the graphical desktop with the terminal on it, then goes to a black screen very shortly, then displays the usual messages

   3.somethings] tpm_tis 00:01: A TPM error occurred (7) attempting to read a pcr
Welcome to openSUSE Leap 42.2 - Kernel 4.4.57-18.3-default (tty1)
susy442-et login: _

before either rebooting (going back to the machine’s startup screen) or shutting down successfully.

In those cases of failure it seems to me that the graphical system takes its last breath at the moment it gets dismissed (what I call dimmed), and then the entire system is utterly stuck.

No idea whether it would help to grab system logs, and I just haven’t taken the time to figure out where they are. If you think that might help I’ll go digging…

#5

Hello 111MilesToGo,

Pressing Ctrl+Alt+Backspace twice should kill the X-server.

You can try to disable composite completely (systemsettings5 -> Hardware -> Monitor/Display -> Compositor).

journalctl -b -1 -r -p 4

should show you all warnings and errors ("-p 3" only the errors) of your last boot ("-b 0" of your current boot) from the system log. For more information on this use

man journalctl

Errors related to the X system can be found in “var/log/Xorg.0.log”.

Your graphics card (NVIDIA GF108GLM [Quadro 1000M]) supports (as far as i know but i might be wrong) the optimus technology (if there is a suitable CPU present). So searching the forum for “optimus” or “bumblebee” might reveal some helpful information. If i recall correctly there are special drivers for those cards. You could show the result of

# hwinfo --gfxcard

here (you need to be root to do so). Maybe someone with a comparable setup can provide more information.

Regards

susejunky

#6

Thanks, susejunky and green8, for your detailed posts. I will go on from there and check deeper into the issue. However, it takes some decision to willingly cause the system to freeze in order to confirm how systematic my current observations are. Taking them as a working hypothesis for now, I do wonder why the freezes occur when I let the 30-sec timer run out before shutdown, and why there is nothing like that when I confirm to shut down sooner than the 30-sec.