X server segfaulting since 4.14.13

Since the recent updates to 4.14.13, the X server is segfaulting on boot, leaving a flashing console login (possibly because it is repeatedly respawning and crashing).

This happens for two different PCs, right on the same update, with the same symptoms. I had to roll back to 4.14.12 on both.

One PC is using a Radeon RX 480 (amdgpu), the other one a Radeon RX 580 (amdgpu). No issues before.

17.248] (EE) Backtrace:
17.248] (EE) 0: /usr/bin/X (xorg_backtrace+0x65) [0x55a293a0c575]
17.248] (EE) 1: /usr/bin/X (0x55a293857000+0x1b9329) [0x55a293a10329]
17.248] (EE) 2: /lib64/libpthread.so.0 (0x7f20ffa6f000+0x12270) [0x7f20ffa81270]
17.248] (EE) 3: /usr/lib64/libEGL_mesa.so.0 (0x7f20ed3af000+0x19942) [0x7f20ed3c8942]
17.248] (EE) 4: /usr/lib64/libEGL_mesa.so.0 (0x7f20ed3af000+0x20b9a) [0x7f20ed3cfb9a]
17.248] (EE) 5: /usr/lib64/libEGL_mesa.so.0 (0x7f20ed3af000+0x186a5) [0x7f20ed3c76a5]
17.248] (EE) 6: /usr/lib64/libEGL_mesa.so.0 (0x7f20ed3af000+0x15289) [0x7f20ed3c4289]
17.248] (EE) 7: /usr/lib64/libEGL_mesa.so.0 (0x7f20ed3af000+0x153a9) [0x7f20ed3c43a9]
17.248] (EE) 8: /usr/lib64/libEGL_mesa.so.0 (eglInitialize+0x13a) [0x7f20ed3bf27a]
17.248] (EE) 9: /usr/lib64/xorg/modules/libglamoregl.so (glamor_egl_init+0x10b) [0x7f20f43c07fb]
17.248] (EE) 10: /usr/lib64/xorg/modules/drivers/amdgpu_drv.so (0x7f20fc3d9000+0x181ab) [0x7f20fc3f11ab]
17.248] (EE) 11: /usr/lib64/xorg/modules/drivers/amdgpu_drv.so (0x7f20fc3d9000+0xf5a1) [0x7f20fc3e85a1]
17.248] (EE) 12: /usr/bin/X (InitOutput+0xa3d) [0x55a2938f126d]
17.248] (EE) 13: /usr/bin/X (0x55a293857000+0x58083) [0x55a2938af083]
17.248] (EE) 14: /lib64/libc.so.6 (__libc_start_main+0xea) [0x7f20ff6d5f4a]
17.249] (EE) 15: /usr/bin/X (_start+0x2a) [0x55a293898f3a]
17.249] (EE)
17.249] (EE) Segmentation fault at address 0x20
17.249] (EE)

Fatal server error:
17.249] (EE) Caught signal 11 (Segmentation fault). Server aborting
17.249] (EE)
17.249] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org

Is mesa-dri installed?

Just looked … no, not installed. Is there some indication that it is not required until 4.14.12, and now mandatory since 4.14.13? As I said, it worked just until I confimed the update and rebooted.

Yes, it is mandatory (at least if you want/need working OpenGL support).
But no, it is completely unrelated to the kernel or its version.

The package is new in the latest snapshot, it contains the Mesa OpenGL drivers, which have been moved out of the main Mesa package.

Actually it should get installed by default, unless you disabled installation of recommended packages (because hardware drivers are treated as recommended only).

See also the discussion on the opensuse-factory mailinglist:

I had the same problem, but installing mesa-dri did fix the problem. Thanks a lot!!

I think there is a dependency missing for amdgpu hardware.

Btw. I am on kernel 4.15.rc3.

No.

Mesa-dri supplements Mesa, so if Mesa is installed, Mesa-dri should get installed too (unconditionally, regardless of the hardware).
But that only works if you don’t disable installation of recommended packages.

So it’s the upgrade to Mesa 17.3.

Unfortunately, it’s not working for me. I just activated the recommended packages install, and upgraded to Mesa 17.3. The Mesa-dri package and Mesa-gallium is autoselected. After the install and rebooting, the X server crashes again with a segfault.

I have to roll back to the previous state in order to start Tumbleweed again.

This is the package list (rpm -qa | grep Mesa)

libOSMesa8-17.2.6-180.3.x86_64
Mesa-libGLESv1_CM1-17.2.6-180.3.x86_64
Mesa-gallium-17.3.2-181.1.x86_64
Mesa-libGLESv2-devel-17.2.6-180.3.x86_64
Mesa-libglapi0-32bit-17.2.6-180.3.x86_64
Mesa-dri-17.3.2-181.1.x86_64
Mesa-libglapi0-17.2.6-180.3.x86_64
Mesa-libGLESv1_CM-devel-17.2.6-180.3.x86_64
Mesa-libEGL1-32bit-17.2.6-180.3.x86_64
Mesa-libEGL1-17.3.2-181.1.x86_64
Mesa-libGL1-17.3.2-181.1.x86_64
Mesa-32bit-17.2.6-180.3.x86_64
Mesa-libGL-devel-17.3.2-181.1.x86_64
Mesa-libva-17.2.6-180.3.x86_64
Mesa-demo-x-8.3.0-3.3.x86_64
Mesa-libGLESv2-2-17.2.6-180.3.x86_64
Mesa-libGL1-32bit-17.2.6-180.3.x86_64
Mesa-libEGL-devel-17.3.2-181.1.x86_64
libOSMesa8-32bit-17.2.6-180.3.x86_64
Mesa-17.3.2-181.1.x86_64

Edit: My bad … I just saw that lots of packages were not upgraded, including the libwayland. I retried with everything checked, now it is working]

By the way, concerning the “recommended install”. You know why I had unchecked that box? - Because when you install LaTeX and have activated recommended install, you get the whole package collection including every single locale support on Earth, which results in about 2500+ packages to be updated every time there is a kernel bugfix update.

Thanks for your help. :slight_smile:

Had the exact same problem also on an AMD machine and as far as I know, I haven’t unchecked any package options. I ran ‘zypper dup’ from the flashing console (it was actually a challenge to type in the password because the keyboard input was also getting interrupted) and at one point during the upgrade the flashing stopped. Once the upgrade finished, I restarted the machine and everything was fine. The only thing I don’t get is why there were more than 500 packages to be upgraded. Isn’t the whole point of Tumbleweed to do such upgrades automatically.

One thing that caught my attention was a vendor change notification I had to confirm for one of the Qt libraries from the default repo to Packman. Maybe that was what was preventing a proper automatic update. But still, the regular update applet should be informing about such things because otherwise the whole system is quite fragile if additional repos are being used.

Having the same symptoms here, on Intel video hardware. Can’t log in from tty as the blinking login makes it impossible to enter the password. Not sure how to fix this short of reinstalling TW…
I’m typing this from LEAP 42.2 which dualboots with TW on this machine.

Press Ctrl+Alt+F1 to switch to text mode, login and run “zypper in Mesa-dri”.
Or boot to text mode in the first place, by pressing ‘e’ at the boot menu and appending ‘3’ to the line starting with “linux” or “linuxefi”.

I am in text mode when the boot finishes but the login screen blinks incessantly and will only accept keyboard input intermittently. I manage to enter the username but can’t enter the password as there is no means of telling which keypress has been accepted and which hasn’t…

So you mean the text mode “login screen”, I thought you were talking about the graphical login.
Well, that’s likely because the graphical login screen tries to start again and again (and fails everytime).

As I wrote, boot to text mode (“runlevel 3”) then.

Yes, that’s what I did and then simply ran a “zypper dup”. All good again, thanks Wolfi!

Why this package is not dependency? If lack of package causing segfault is not enough to consider package dependency then what is? kernel panic? I ran zypper up because zypper dup goes crazy if you’re using packman repo and had to install this package manually after update. Also “3d acceleration” is questionable here. I’m running KVM guest without hardware acceleration and still got segfault.

This question has been answered several times recently. On Tumbleweed “zypper up” is almost guaranteed to eventually break the system Only “zypper dup” is safe.
Several codecs have come out of patent and are included in the OpenSUSE repositories. As a result they have been dropped from Packman. “zypper dup” does not “go crazy”. It simply makes a one-time request for permission to change repositories from Packman to OpenSUSE for the affected packages.

I do not understand why you have reopened this thread to make an unrelated comments.

It is required meanwhile, since shortly after this thread started.

“zypper up” should have some sort of stern warning or plain refuse, for Tumbleweed.

There is a warning:

 # zypper up

...

    Consider to cancel:
    Product 'openSUSE Tumbleweed' requires to be updated by calling 'zypper dup'!
Continue? [y/n/...? shows all options] (y): 

Perhaps the last chance option should default to no:

 Continue? [Y/n/...? shows all options] (n): 

And removing PackageKit from the default installation patterns.