Patches/Updates 16th March 2018 - X-Server dies - need to use recovery mode

English Install/Boot/Login
1

Following today’s patches and updates, KDE SDDM doesn’t present the login screen any more: I have to use the SysRq reboot to recover and then choose the Recovery Mode at the Boot screen to be able to login to a KDE session.

The packages updated/patched today were: libsolv-tools; python-solv; zypper-log; libzypp; zypper; zypper-aptitude; kernel-firmware; libsystemd0; libsystemd0-32bit; libudev1; messagelib; systemd-32bit; systemd-bash-completion; ucode-amd; wireless-regdb; messagelib-lang; systemd; udev; systemd-sysvinit; systemd-logger.

Haven’t yet worked out which one is causing the issue – will update later assuming that, no one else discovers the culprit …

The journal entry for the “bad” boot is:

Mär 16 12:16:10 eck001 systemd[1]: Started Locale Service.
Mär 16 12:16:10 eck001 systemd[1]: Received SIGRTMIN+21 from PID 246 (plymouthd).
Mär 16 12:16:10 eck001 sddm[2622]: Initializing...
Mär 16 12:16:10 eck001 sddm[2622]: Starting...
Mär 16 12:16:10 eck001 sddm[2622]: Adding new display on vt 7 ...
Mär 16 12:16:10 eck001 sddm[2622]: Display server starting...
Mär 16 12:16:10 eck001 sddm[2622]: Running: /usr/bin/X -nolisten tcp -auth /run/sddm/{4526d8ea-5a20-479a-85ac-aadeb9d3544f} -background none -noreset -displayfd 18 vt7
Mär 16 12:16:10 eck001 SuSEfirewall2[1990]: Firewall rules successfully set
Mär 16 12:16:10 eck001 systemd[1]: Started SuSEfirewall2 phase 2.
Mär 16 12:16:11 eck001 sddm[2622]: Setting default cursor
Mär 16 12:16:11 eck001 sddm[2622]: Running display setup script  "/etc/X11/xdm/Xsetup"
Mär 16 12:16:11 eck001 sddm[2622]: Display server started.
Mär 16 12:16:11 eck001 sddm[2622]: Socket server starting...
Mär 16 12:16:11 eck001 sddm[2622]: Socket server started.
Mär 16 12:16:11 eck001 sddm[2622]: Greeter starting...
Mär 16 12:16:11 eck001 sddm[2622]: Adding cookie to "/run/sddm/{4526d8ea-5a20-479a-85ac-aadeb9d3544f}"
Mär 16 12:16:11 eck001 display-manager[2368]: Starting service sddm/usr/bin/xauth: (stdin):1:  bad "remove" command line
Mär 16 12:16:11 eck001 display-manager[2368]: /usr/bin/xauth: (stdin):2:  bad "add" command line
Mär 16 12:16:11 eck001 sddm[2622]: Display server stopped.
Mär 16 12:16:11 eck001 sddm[2622]: Running display stop script  "/usr/share/sddm/scripts/Xstop"
Mär 16 12:16:11 eck001 sddm[2622]: Socket server stopping...
Mär 16 12:16:11 eck001 sddm[2622]: Socket server stopped.
Mär 16 12:16:11 eck001 sddm[2622]: Removing display "" ...
Mär 16 12:16:11 eck001 sddm[2622]: Adding new display on vt 7 ...
Mär 16 12:16:11 eck001 sddm[2622]: Display server starting...
Mär 16 12:16:11 eck001 sddm[2622]: Running: /usr/bin/X -nolisten tcp -auth /run/sddm/{40097c77-f298-4b9d-99c6-6543011d9b45} -background none -noreset -displayfd 20 vt7
Mär 16 12:16:11 eck001 sddm-helper[2809]: [PAM] Starting...
Mär 16 12:16:11 eck001 sddm-helper[2809]: [PAM] Authenticating...
Mär 16 12:16:11 eck001 sddm-helper[2809]: [PAM] returning.
Mär 16 12:16:11 eck001 sddm[2622]: Setting default cursor
Mär 16 12:16:11 eck001 sddm[2622]: Running display setup script  "/etc/X11/xdm/Xsetup"
Mär 16 12:16:11 eck001 sddm[2622]: Display server started.
Mär 16 12:16:11 eck001 sddm[2622]: Socket server starting...
Mär 16 12:16:11 eck001 sddm[2622]: Socket server started.
Mär 16 12:16:11 eck001 sddm[2622]: Greeter starting...
Mär 16 12:16:11 eck001 sddm[2622]: Adding cookie to "/run/sddm/{40097c77-f298-4b9d-99c6-6543011d9b45}"
Mär 16 12:16:11 eck001 display-manager[2368]: /usr/bin/xauth: (stdin):1:  bad "remove" command line
Mär 16 12:16:11 eck001 display-manager[2368]: /usr/bin/xauth: (stdin):2:  bad "add" command line
Mär 16 12:16:11 eck001 sddm[2622]: QProcess: Destroyed while process ("/usr/lib/sddm/sddm-helper") is still running.
Mär 16 12:16:11 eck001 sddm[2622]: Display server stopped.
Mär 16 12:16:11 eck001 sddm[2622]: Running display stop script  "/usr/share/sddm/scripts/Xstop"
Mär 16 12:16:11 eck001 sddm[2622]: Socket server stopping...
Mär 16 12:16:11 eck001 sddm[2622]: Socket server stopped.
Mär 16 12:16:11 eck001 sddm[2622]: Removing display "" ...
Mär 16 12:16:11 eck001 sddm[2622]: Adding new display on vt 7 ...
Mär 16 12:16:11 eck001 sddm[2622]: Display server starting...
Mär 16 12:16:11 eck001 sddm[2622]: Running: /usr/bin/X -nolisten tcp -auth /run/sddm/{15486f61-a0e5-435c-bc36-05411930f878} -background none -noreset -displayfd 20 vt7
Mär 16 12:16:11 eck001 sddm-helper[2824]: [PAM] Starting...
Mär 16 12:16:11 eck001 sddm-helper[2824]: [PAM] Authenticating...
Mär 16 12:16:11 eck001 sddm-helper[2824]: [PAM] returning.
Mär 16 12:16:11 eck001 sddm[2622]: Setting default cursor
Mär 16 12:16:11 eck001 sddm[2622]: Running display setup script  "/etc/X11/xdm/Xsetup"
Mär 16 12:16:11 eck001 sddm[2622]: Display server started.
Mär 16 12:16:11 eck001 sddm[2622]: Socket server starting...
Mär 16 12:16:11 eck001 sddm[2622]: Socket server started.
Mär 16 12:16:11 eck001 sddm[2622]: Greeter starting...
Mär 16 12:16:11 eck001 sddm[2622]: Adding cookie to "/run/sddm/{15486f61-a0e5-435c-bc36-05411930f878}"
Mär 16 12:16:11 eck001 display-manager[2368]: /usr/bin/xauth: (stdin):1:  bad "remove" command line
Mär 16 12:16:11 eck001 display-manager[2368]: /usr/bin/xauth: (stdin):2:  bad "add" command line
Mär 16 12:16:11 eck001 sddm[2622]: QProcess: Destroyed while process ("/usr/lib/sddm/sddm-helper") is still running.
Mär 16 12:16:11 eck001 sddm[2622]: Display server stopped.
Mär 16 12:16:11 eck001 sddm[2622]: Running display stop script  "/usr/share/sddm/scripts/Xstop"
Mär 16 12:16:11 eck001 sddm[2622]: Socket server stopping...
Mär 16 12:16:11 eck001 sddm[2622]: Socket server stopped.
Mär 16 12:16:11 eck001 sddm[2622]: Removing display "" ...
Mär 16 12:16:11 eck001 sddm[2622]: Adding new display on vt 7 ...
Mär 16 12:16:11 eck001 sddm[2622]: Display server starting...
2

Doesn’t show much (except that plymouth is crashing, but that shouldn’t cause the problem, you could try to disable it though with the “plymouth.enable=0” boot option).
What’s in /var/log/Xorg.0.log? (or /var/log/Xorg.0.log, which is the log from the previous boot)

From the updates you mention, the most likely ones would be systemd or kernel-firmware I think.
So try to revert them first.

I don’t have a problem here, but I haven’t installed these updates yet (and if it’s a problem with kernel-firmware, it may be highly hardware specific anyway).

3

Something is weird with the Xorg logs:


 > l -t /var/log/Xorg.*
-rw-r--r-- 1 root root  19737 16. Mär 15:04 /var/log/Xorg.0.log
-rw-r--r-- 1 root root      0 16. Mär 15:03 /var/log/Xorg.0.log.old
-rw-r--r-- 1 root root  44113 26. Jan 10:29 /var/log/Xorg.1.log
-rw-r--r-- 1 root root  43847 13. Dez 15:25 /var/log/Xorg.1.log.old
-rw-r--r-- 1 root root 100518 28. Aug 2017  /var/log/Xorg.2.log
-rw-r--r-- 1 root root  58724 28. Aug 2017  /var/log/Xorg.4.log
-rw-r--r-- 1 root root  63245 28. Aug 2017  /var/log/Xorg.3.log
-rw-r--r-- 1 root root  63083 23. Aug 2017  /var/log/Xorg.2.log.old
 >

The one timestamped “16. Mär 15:04” is the one from this boot and, it doesn’t have anything extraordinary marked with the ‘WW’ and ‘EE’ flags:


 > grep -E 'WW|EE' /var/log/Xorg.0.log
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
    13.770] (WW) The directory "/usr/share/fonts/misc/sgi" does not exist.
    13.791] (WW) Warning, couldn't open module vboxvideo
    13.791] (EE) Failed to load module "vboxvideo" (module does not exist, 0)
    13.791] (WW) Warning, couldn't open module vmware
    13.791] (EE) Failed to load module "vmware" (module does not exist, 0)
    13.817] (EE) open /dev/dri/card0: No such file or directory
    13.817] (WW) Falling back to old probe method for modesetting
    13.817] (EE) open /dev/dri/card0: No such file or directory
    13.818] (WW) Falling back to old probe method for vesa
    13.818] (EE) Screen 0 deleted because of no matching config section.
    13.831] (EE) AIGLX: reverting to software rendering
 >

I’ve also removed the outdated Xorg logs.

I’ve rolled the updates and patches back in 2 stages:


kernel-firmware wird heruntergeladen (Downloadgröße 42,49 MiB)
libudev1 wird heruntergeladen (Downloadgröße 330,3 KiB)
systemd wird heruntergeladen (Downloadgröße 3,70 MiB)
ucode-amd wird heruntergeladen (Downloadgröße 42,9 KiB)
udev wird heruntergeladen (Downloadgröße 1,26 MiB)
systemd-sysvinit wird heruntergeladen (Downloadgröße 286,6 KiB)
kernel-firmware-20170530-14.1.noarch.rpm wird installiert (Größe nach Installation 191,04 MiB)
libudev1-228-44.1.x86_64.rpm wird installiert (Größe nach Installation 130,3 KiB)
systemd-228-44.1.x86_64.rpm wird installiert (Größe nach Installation 20,61 MiB)
ucode-amd-20170530-14.1.noarch.rpm wird installiert (Größe nach Installation 31,8 KiB)
udev-228-44.1.x86_64.rpm wird installiert (Größe nach Installation 6,56 MiB)
systemd-sysvinit-228-44.1.x86_64.rpm wird installiert (Größe nach Installation 5,3 KiB)

wireless-regdb wird heruntergeladen (Downloadgröße 9,3 KiB)
libsystemd0 wird heruntergeladen (Downloadgröße 519,6 KiB)
libsystemd0-32bit wird heruntergeladen (Downloadgröße 522,7 KiB)
messagelib wird heruntergeladen (Downloadgröße 5,00 MiB)
systemd-bash-completion wird heruntergeladen (Downloadgröße 291,4 KiB)
systemd-logger wird heruntergeladen (Downloadgröße 281 KiB)
messagelib-lang wird heruntergeladen (Downloadgröße 705,6 KiB)
wireless-regdb-2017.03.07-4.1.noarch.rpm wird installiert (Größe nach Installation 6 KiB)
libsystemd0-228-44.1.x86_64.rpm wird installiert (Größe nach Installation 788,4 KiB)
libsystemd0-32bit-228-44.1.x86_64.rpm wird installiert (Größe nach Installation 848,1 KiB)
messagelib-17.04.2-6.1.x86_64.rpm wird installiert (Größe nach Installation 8,74 MiB)
systemd-bash-completion-228-44.1.noarch.rpm wird installiert (Größe nach Installation 74,4 KiB)
systemd-logger-228-44.1.x86_64.rpm wird installiert (Größe nach Installation 1 KiB)
messagelib-lang-17.04.2-6.1.noarch.rpm wird installiert (Größe nach Installation 5,33 MiB)

No change – will reinstall them.

Hope that I don’t have a coincidental hardware breakage …

4

That’s obviously the one from recovery mode, otherwise it wouldn’t try to load “vmware” and “vboxvideo”…

Xorg.0.log.old would likely be the one from the previous normal boot, but unfortunately that’s empty (which means that X is apparently crashing quite early before it even writes anything to the file)

Is there a coredump listed by coredumptctl?
Can you get to a graphical system by running startx in text mode? (as root)

Another thing that might be interesting is switching to a different display manager and see if that works. If it does, the Xorg log may be interesting as well.

I’ve rolled the updates and patches back in 2 stages:
No change – will reinstall them.

ucode-intel may be the culprit too (especially if it’s an intel system), so try to revert it as well.

5

That’s exactly what’s happening …

No.

I’m in KDE Plasma 5 now, from the recovery mode – no compositing …

BTW: it’s impossible to login into a TTY – SDDM and X are consuming too much CPU … The flashing display they’re producing is making the keyboard unresponsive …

I’ll take a look …

I re-installed all the updates/patches, including the ‘ucode-intel’ patch which arrived after I hit the issue being worked here:


kernel-firmware wird heruntergeladen (Downloadgröße 42,49 MiB)
Delta-RPM ./noarch/kernel-firmware-20170530-14.1_17.1.noarch.drpm wird heruntergeladen (Downloadgröße 308,2 KiB)
Delta-RPM wird angewendet: /var/cache/zypp/packages/download.opensuse.org-oss_4/noarch/kernel-firmware-20170530-14.1_17.1.noarch.drpm
libsystemd0 wird heruntergeladen (Downloadgröße 520 KiB)
libsystemd0-32bit wird heruntergeladen (Downloadgröße 523,2 KiB)
libudev1 wird heruntergeladen (Downloadgröße 330,8 KiB)
messagelib wird heruntergeladen (Downloadgröße 5,00 MiB)
Delta-RPM ./x86_64/messagelib-17.04.2-6.1_9.1.x86_64.drpm wird heruntergeladen (Downloadgröße 57,8 KiB)
Delta-RPM wird angewendet: /var/cache/zypp/packages/download.opensuse.org-oss_4/x86_64/messagelib-17.04.2-6.1_9.1.x86_64.drpm
systemd-bash-completion wird heruntergeladen (Downloadgröße 291,8 KiB)
ucode-amd wird heruntergeladen (Downloadgröße 43 KiB)
wireless-regdb wird heruntergeladen (Downloadgröße 14,1 KiB)
ucode-intel wird heruntergeladen (Downloadgröße 1,20 MiB)
messagelib-lang wird heruntergeladen (Downloadgröße 705,5 KiB)
Delta-RPM ./noarch/messagelib-lang-17.04.2-6.1_9.1.noarch.drpm wird heruntergeladen (Downloadgröße 47,7 KiB)
Delta-RPM wird angewendet: /var/cache/zypp/packages/download.opensuse.org-oss_4/noarch/messagelib-lang-17.04.2-6.1_9.1.noarch.drpm
systemd wird heruntergeladen (Downloadgröße 3,70 MiB)
Delta-RPM ./x86_64/systemd-228-44.1_47.1.x86_64.drpm wird heruntergeladen (Downloadgröße 394,8 KiB)
Delta-RPM wird angewendet: /var/cache/zypp/packages/download.opensuse.org-oss_4/x86_64/systemd-228-44.1_47.1.x86_64.drpm
udev wird heruntergeladen (Downloadgröße 1,26 MiB)
Delta-RPM ./x86_64/udev-228-44.1_47.1.x86_64.drpm wird heruntergeladen (Downloadgröße 299 KiB)
Delta-RPM wird angewendet: /var/cache/zypp/packages/download.opensuse.org-oss_4/x86_64/udev-228-44.1_47.1.x86_64.drpm
systemd-sysvinit wird heruntergeladen (Downloadgröße 287,1 KiB)
systemd-logger wird heruntergeladen (Downloadgröße 281,4 KiB)
kernel-firmware-20170530-17.1.noarch.rpm wird installiert (Größe nach Installation 191,04 MiB)
libsystemd0-228-47.1.x86_64.rpm wird installiert (Größe nach Installation 788,4 KiB)
libsystemd0-32bit-228-47.1.x86_64.rpm wird installiert (Größe nach Installation 848,1 KiB)
libudev1-228-47.1.x86_64.rpm wird installiert (Größe nach Installation 130,3 KiB)
messagelib-17.04.2-9.1.x86_64.rpm wird installiert (Größe nach Installation 8,74 MiB)
systemd-bash-completion-228-47.1.noarch.rpm wird installiert (Größe nach Installation 74,4 KiB)
ucode-amd-20170530-17.1.noarch.rpm wird installiert (Größe nach Installation 31,8 KiB)
wireless-regdb-2017.12.23-5.3.2.noarch.rpm wird installiert (Größe nach Installation 13 KiB)
ucode-intel-20180312-22.1.x86_64.rpm wird installiert (Größe nach Installation 3,20 MiB)
messagelib-lang-17.04.2-9.1.noarch.rpm wird installiert (Größe nach Installation 5,33 MiB)
systemd-228-47.1.x86_64.rpm wird installiert (Größe nach Installation 20,61 MiB)
udev-228-47.1.x86_64.rpm wird installiert (Größe nach Installation 6,56 MiB)
systemd-sysvinit-228-47.1.x86_64.rpm wird installiert (Größe nach Installation 5,3 KiB)
systemd-logger-228-47.1.x86_64.rpm wird installiert (Größe nach Installation 1 KiB)

No change …

6

Forgot to mention that, “/var/lib/sddm/.local/share/sddm/xorg-session.log” contains (only 1 line):

QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: Datei oder Verzeichnis nicht gefunden
7

Then stop the display-manager.service (or boot to runlevel 3/multiuser.target in the first place).
SDDM will restart again and again if X fails to start.

Irrelevant.

That’s from the user session (sddm runs as user sddm and /var/lib/sddm/ is its home directory), not X itself. Also, it’s from the current boot, not the previous one.

8

The misery is due to something which has changed in X11 with respect to an AMD OLAND card and the ‘radeon’ driver: the ‘radeon’ quirks no longer apply:
In /etc/X11/xorg.conf.d/: “50-device.conf”; the previous setting no longer works:


 # xrandr -q
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1920 x 1080, current 1920 x 1080, maximum 1920 x 1080
default connected primary 1920x1080+0+0 0mm x 0mm
   1920x1080     77.00* 
 #

Previously, “DVI-0” was hinted – commenting out the “Device” section in ‘/etc/X11/xorg.conf.d/50-device.conf’ cured the issue for the moment but, compositing no longer works as it should do – the OpenGL renderer is currently with a ‘llvmpipe’ in place of the AMD OLAND hardware.
The AMD vdpau libraries are installed: libvdpau_r300; libvdpau_r600; libvdpau_radeonsi; but:


 > vdpauinfo
display: :0   screen: 0
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
Error creating VDPAU device: 1
 >

For what ever reason the AMD support seems to have disappeared …

Or, the the AMD OLAND card has suddenly died – for whatever reason …

9

If you boot to recovery mode, 50-device.conf is ignored.
Also, you will use a generic fallback driver, and not radeon.

Previously, “DVI-0” was hinted – commenting out the “Device” section in ‘/etc/X11/xorg.conf.d/50-device.conf’ cured the issue for the moment but, compositing no longer works as it should do – the OpenGL renderer is currently with a ‘llvmpipe’ in place of the AMD OLAND hardware.

llvmpipe is Mesa’s software OpenGL renderer, that’s normal in recovery mode.

The AMD vdpau libraries are installed: libvdpau_r300; libvdpau_r600; libvdpau_radeonsi; but:

VDPAU has nothing to do with OpenGL or compositing though. That’s just hardware accelerated decoding of video streams, i.e. hardware accerated movie playback.

For what ever reason the AMD support seems to have disappeared …

As indicated, that’s normal in recovery mode.
The question is what happens on a normal boot.

Again, try with e.g. xdm, and/or run startx directly from text mode to test whether it works then.
And look (or provide) the Xorg log, that should at least show which driver is used then.

Or, the the AMD OLAND card has suddenly died – for whatever reason …

Might indeed be a possibility.

FWIW, I have absolutely no problem after installing the recent updates on two different 42.3 systems (radeon and intel).

10

PS: if I understand your last post correctly, removing 50-device.conf “fixed” your problem with normal boot?
Then likely radeon cannot be loaded, and you had a line ‘Driver “radeon”’ in there, which would cause X to error out in that case.

Without the file, X will fall back to a different/generic driver.

Still strange that the X log was empty though, this should actually show up in there.
Maybe you rebooted your system at a time when X currently tried to start, i.e. when it just had created the log but not written anything yet…

Anyway, can you provide a log now?

11

Ooops!! The ‘radeon’ driver is missing!!!


 # lsmod | grep radeon
 # modprobe radeon
modprobe: ERROR: ctx=0x1600010 path=/lib/modules/4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/drm_kms_helper.ko error=No such file or directory
modprobe: ERROR: ctx=0x1600010 path=/lib/modules/4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/drm_kms_helper.ko error=No such file or directory
modprobe: ERROR: could not insert 'radeon': Unknown symbol in module, or unknown parameter (see dmesg)
 #

And:


 # pwd
/lib/modules
 # find . -iname '*radeon*'
./4.4.104-39-default/kernel/drivers/gpu/drm/radeon
./4.4.104-39-default/kernel/drivers/gpu/drm/radeon/radeon.ko
./4.4.104-39-default/weak-updates/updates/drivers/gpu/drm/radeon
./4.4.104-39-default/weak-updates/updates/drivers/gpu/drm/radeon/radeon.ko
./4.4.114-42-default/kernel/drivers/gpu/drm/radeon
./4.4.114-42-default/kernel/drivers/gpu/drm/radeon/radeon.ko
./4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/radeon
./4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/radeon/radeon.ko
./4.4.103-36-default/kernel/drivers/gpu/drm/radeon
./4.4.103-36-default/kernel/drivers/gpu/drm/radeon/radeon.ko
./4.4.103-36-default/weak-updates/updates/drivers/gpu/drm/radeon
./4.4.103-36-default/weak-updates/updates/drivers/gpu/drm/radeon/radeon.ko
 # 
 # find . -iname '*drm*'
./4.4.104-39-default/kernel/drivers/gpu/drm
./4.4.104-39-default/kernel/drivers/gpu/drm/bochs/bochs-drm.ko
./4.4.104-39-default/kernel/drivers/gpu/drm/drm.ko
./4.4.104-39-default/kernel/drivers/gpu/drm/drm_kms_helper.ko
./4.4.104-39-default/weak-updates/updates/drivers/gpu/drm
./4.4.104-39-default/weak-updates/updates/drivers/gpu/drm/bochs/bochs-drm.ko
./4.4.104-39-default/weak-updates/updates/drivers/gpu/drm/drm.ko
./4.4.104-39-default/weak-updates/updates/drivers/gpu/drm/drm_kms_helper.ko
./4.4.114-42-default/kernel/drivers/gpu/drm
./4.4.114-42-default/kernel/drivers/gpu/drm/bochs/bochs-drm.ko
./4.4.114-42-default/kernel/drivers/gpu/drm/drm.ko
./4.4.114-42-default/kernel/drivers/gpu/drm/drm_kms_helper.ko
./4.4.114-42-default/weak-updates/updates/drivers/gpu/drm
./4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/bochs/bochs-drm.ko
./4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/drm.ko
./4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/drm_kms_helper.ko
./4.4.103-36-default/kernel/drivers/gpu/drm
./4.4.103-36-default/kernel/drivers/gpu/drm/bochs/bochs-drm.ko
./4.4.103-36-default/kernel/drivers/gpu/drm/drm.ko
./4.4.103-36-default/kernel/drivers/gpu/drm/drm_kms_helper.ko
./4.4.103-36-default/weak-updates/updates/drivers/gpu/drm
./4.4.103-36-default/weak-updates/updates/drivers/gpu/drm/bochs/bochs-drm.ko
./4.4.103-36-default/weak-updates/updates/drivers/gpu/drm/drm.ko
./4.4.103-36-default/weak-updates/updates/drivers/gpu/drm/drm_kms_helper.ko
 #

And, the ‘drm_kms_helper.ko’ and ‘drm.ko’ files are badly linked (red background in “ls -l”):


 # l /lib/modules/4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/drm_kms_helper.ko
lrwxrwxrwx 1 root root 71  9. Feb 18:12 **/lib/modules/4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/drm_kms_helper.ko -> /lib/modules/4.4.79-4-default/updates/drivers/gpu/drm/drm_kms_helper.ko**
 # l /lib/modules/4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/drm.ko
lrwxrwxrwx 1 root root 60  9. Feb 18:12 **/lib/modules/4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/drm.ko -> /lib/modules/4.4.79-4-default/updates/drivers/gpu/drm/drm.ko**
 # 
 # l /lib/modules/
insgesamt 20
drwxr-xr-x  5 root root 4096 12. Mär 17:05 ./
drwxr-xr-x 12 root root 4096 13. Mär 09:13 ../
drwxr-xr-x  5 root root 4096  5. Mär 11:19 4.4.103-36-default/
drwxr-xr-x  5 root root 4096  5. Mär 11:19 4.4.104-39-default/
drwxr-xr-x  6 root root 4096  5. Mär 11:19 4.4.114-42-default/
 #

It’s looking bad: the “weak updates” drivers are all linked to the nonexistant “4.4.79-4” version and, I’m not clear as to what is setting up the “weak updates” directories …

Need to investigate further – will report later.

12

It’s getting worse: for the kernel versions 4.4.103-36-default, 4.4.104-39-default, and 4.4.114-42-default, there’s only one path under “weak-updates” and that is “weak-updates/updates/drivers/gpu/drm/” and, everything below there, for all the versions mentioned is linked to the non-existent ‘4.4.79-4’ version …

I’ll unlink everything under “weak updates” and then (forcibly) re-install the “kernel-default” package and see what happens …

Grrrr!!! >:)

13

Well, this will of course prevent X from loading the radeon X driver as well, and make it abort if you force radeon via 50-device.conf.

And, the ‘drm_kms_helper.ko’ and ‘drm.ko’ files are badly linked (red background in “ls -l”):
It’s looking bad: the “weak updates” drivers are all linked to the nonexistant “4.4.79-4” version and, I’m not clear as to what is setting up the “weak updates” directories …

That’s done via the (kernel and kmp) package’s %postinstall scripts, that get run whenever the package is installed/updated.

What drm-kmp-default package(s) do you have installed?

rpm -q drm-kmp-default

The current drm-kmp-default package is in fact version 4.4.79-4, and should contain /lib/modules/4.4.79-4-default/updates/drivers/gpu/drm/drm_kms_helper.ko

Reinstalling it should help in any case then (unless there is some other problem).

Btw, it all looks fine here (and as already mentioned, I didn’t experience any problem either):

wolfi@linux-lf90:~>  l /lib/modules/4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/drm_kms_helper.ko
lrwxrwxrwx 1 root root 71 23. Feb 20:53 /lib/modules/4.4.114-42-default/weak-updates/updates/drivers/gpu/drm/drm_kms_helper.ko -> /lib/modules/4.4.79-4-default/updates/drivers/gpu/drm/drm_kms_helper.ko
wolfi@linux-lf90:~> l /lib/modules/4.4.79-4-default/updates/drivers/gpu/drm/drm_kms_helper.ko
-rw-r--r-- 1 root root 263258  9. Aug 2017  /lib/modules/4.4.79-4-default/updates/drivers/gpu/drm/drm_kms_helper.ko

That’s the intel system, but I expect the same on the radeon system, which didn’t show any problems either (and continued to use the radeon driver)…

14

Zypper says:


 > zypper info drm-kmp-default
Loading repository data...
Reading installed packages...


Information for package drm-kmp-default:
----------------------------------------
Repository     : Hauptaktualisierungs-Repository
Name           : drm-kmp-default
Version        : 4.9.33_k4.4.79_4-5.2
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 11.7 MiB
Installed      : Yes (automatically)
Status         : up-to-date
Source package : drm-4.9.33-5.2.src
Summary        : Backported drm kernel modules
Description    :
    Backported drm kernel modules for upgrading to the 4.9.x kernel implemntations.
    This is mainly for supporting Intel Kabylake graphics, but also for bringing
    up / fixing the other graphics devices. 

 >

But:


 > l /lib/modules/4.4.79-4-default/updates/drivers/gpu/drm/
ls: cannot access '/lib/modules/4.4.79-4-default/updates/drivers/gpu/drm/': No such file or directory
 >

A forced re-install of ‘drm-kmp-default’ replaced the missing directories and files.

Thanks Wolfi!!! :slight_smile: [HR][/HR]BTW: removing everything under “weak updates” and re-installing the Kernel only restored the “weak updates” directory trees and the missing links …

Also BTW: an immediate “modprobe radeon” killed this KDE session but, when the SDDM recovered I logged back in to KDE, restarted Firefox, restarted this Forums session (was fast enough to not have to login again) and, was able to recover all the text above.


 # lsmod | grep radeon
radeon               1597440  26 
drm_kms_helper        167936  1 radeon
ttm                   110592  1 radeon
drm                   397312  14 ttm,drm_kms_helper,radeon
i2c_algo_bit           16384  1 radeon
 # 
 # xrandr -q
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
HDMI-0 disconnected (normal left inverted right x axis y axis)
DVI-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm
   1920x1080     60.00*+  50.00    59.94  
   1680x1050     59.88  
   1600x900      60.00  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x800      59.91  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08  
VGA-0 disconnected (normal left inverted right x axis y axis)
 #
15

:shame: And, now I suspect that I know what the root cause was:
I was investigating a CIFS issue ("/lib/modules/4.4.114-42-default/kernel/fs/cifs/") and, noticed that in “/lib/modules” there was a “3.16.7-24-desktop” tree presumably left-over from a previous system (possibly 13.2?). I removed that directory tree and, assumed that the “4.4.79-4-default” directory tree was a mistakenly left-over version 4.4 Linux kernel (Leap) directory tree; therefore I removed the “4.4.79-4-default” directory tree as well.

All went well until the Kernel Firmware update last week … :shame:

16

Yes, that would definitely explain why the files were missing. :wink:

All went well until the Kernel Firmware update last week … :shame:

Probably the files were still in the initrd, and loaded before / was mounted.

A kernel-firmware update triggers a recreation of the initrd as well though, which “broke” it.