Bug 1013200

Created attachment 704543 [details]
plymouth coredump

Created attachment 704544 [details]
sddm-greeter coredump

Package version info:

sddm-0.13.0-8.1.x86_64
plymouth-0.9.2-2.2.x86_64
xorg-x11-server-7.6_1.18.3-4.1.x86_64

coredumpctl info on the two attached dumps:

           PID: 460 (plymouthd)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Fr 2016-12-02 08:49:50 CET (18min ago)
  Command Line: @usr/sbin/plymouthd --mode=boot --pid-file=/run/plymouth/pid --attach-to-session
    Executable: /usr/sbin/plymouthd
 Control Group: /system.slice/plymouth-start.service
          Unit: plymouth-start.service
         Slice: system.slice
       Boot ID: 0320a6fa27864214b4d62ed7b7d04dcd
    Machine ID: dbe28f0435b4a756350d2ade583c427a
      Hostname: linux
      Coredump: /var/lib/systemd/coredump/core.plymouthd.0.0320a6fa27864214b4d62ed7b7d04dcd.460.1480664990000000.xz
       Message: Process 460 (plymouthd) of user 0 dumped core.

           PID: 1974 (sddm-greeter)
           UID: 481 (sddm)
           GID: 479 (sddm)
        Signal: 6 (ABRT)
     Timestamp: Fr 2016-12-02 08:50:08 CET (17min ago)
  Command Line: /usr/bin/sddm-greeter --socket /tmp/sddm-:0-NUwyJj --theme /usr/share/sddm/themes/breeze-openSUSE
    Executable: /usr/bin/sddm-greeter
 Control Group: /user.slice/user-481.slice/session-1.scope
          Unit: session-1.scope
         Slice: user-481.slice
       Session: 1
     Owner UID: 481 (sddm)
       Boot ID: 0320a6fa27864214b4d62ed7b7d04dcd
    Machine ID: dbe28f0435b4a756350d2ade583c427a
      Hostname: rofl
      Coredump: /var/lib/systemd/coredump/core.sddm-greeter.481.0320a6fa27864214b4d62ed7b7d04dcd.1974.1480665008000000.xz
       Message: Process 1974 (sddm-greeter) of user 481 dumped core.

Possibly relevant hardware (lspci) info:

01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS780L [Radeon 3000]

Please provide backtraces of plymouth and sddm-greeter.

Hmm. The only difference in xorg-x11-server between 42.2 release and update I can find is

 U_modesetting-set-driverPrivate-to-Null-after-closing-fd.patch
 Prevent crash when unplugging displaylink device. (bnc#1011570)

I don't think this is the culprit and it only affects modesetting driver users, which you probably are not with your AMD card (check /var/log/Xorg.0.log or wherever your displaymanager writes the X log into).

> (from the "official" http://download.opensuse.org/repositories/Kernel:/stable/standard/ repository) 
>

For sure this is not the "official" kernel. This is a bleeding edge "kernel-of-the-day". Therefore I suggest to go back to our latest Leap 42.2 kernel (version 4.4!) and test again.

For me this looks like a race between plymouth and X. Honestly if you can live
without a splash screen for boot I recommend to disable plymouth by adding "plymouth.enable=0" to the kernel boot options. ;-)

(In reply to Fabian Vogt from comment #5)
> Please provide backtraces of plymouth and sddm-greeter.

80 debuginfo installs later.....

Small side note, following all the gdb "zypper install this or that debuginfo", for sddm, two fail:

zypper install Mesa-libGL1-debuginfo-11.2.2-158.1.x86_64 Mesa-libglapi0-debuginfo-11.2.2-158.1.x86_64
Package 'Mesa-libGL1-debuginfo-11.2.2-158.1.x86_64' not found.
Package 'Mesa-libglapi0-debuginfo-11.2.2-158.1.x86_64' not found.

Here are the backtraces I could generate, relative to the coredumps attached previously:

==== plymouthd ================================================

Reading symbols from /usr/sbin/plymouthd...Reading symbols from /usr/lib/debug/usr/sbin/plymouthd.debug...done.
done.
[New LWP 460]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `@usr/sbin/plymouthd --mode=boot --pid-file=/run/plymouth/pid --attach-to-sessio'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  ply_event_loop_get_destination_from_fd_watch (loop=0x7974742f7665642f, 
    watch=0x21) at ply-event-loop.c:449
449	ply-event-loop.c: No such file or directory.
(gdb) bt
#0  ply_event_loop_get_destination_from_fd_watch (loop=0x7974742f7665642f, 
    watch=0x21) at ply-event-loop.c:449
#1  0x00007f2765b9e1db in ply_event_loop_stop_watching_fd (
    loop=0x7974742f7665642f, watch=0x21) at ply-event-loop.c:750
#2  0x00007f276598a84c in ply_terminal_close (terminal=0xab7cc0)
    at ply-terminal.c:686
#3  0x00007f2765ba1c33 in ply_hashtable_foreach (hashtable=0xab78e0, 
    func=0x7f276598a7c0 <ply_terminal_close>, user_data=0xab7f20)
    at ply-hashtable.c:268
#4  0x00007f2765987573 in ply_close_all_terminals (manager=<optimized out>)
    at ply-device-manager.c:933
#5  0x000000000040c1e8 in quit_splash (state=state@entry=0x7ffe07cf7170)
    at main.c:1064
#6  0x000000000040d8cf in on_boot_splash_idle (state=0x7ffe07cf7170)
    at main.c:1196
#7  0x00007f2765b9ed02 in ply_event_loop_handle_timeouts (loop=0xab2150)
    at ply-event-loop.c:1192
#8  ply_event_loop_process_pending_events (loop=loop@entry=0xab2150)
    at ply-event-loop.c:1251
#9  0x00007f2765b9f2f0 in ply_event_loop_run (loop=0xab2150)
    at ply-event-loop.c:1310
#10 0x00000000004055bf in main (argc=<optimized out>, argv=<optimized out>)
    at main.c:2236

==== sddm-greeter =============================================

Reading symbols from /usr/bin/sddm-greeter...Reading symbols from /usr/lib/debug/usr/bin/sddm-greeter.debug...done.
done.
[New LWP 1974]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/bin/sddm-greeter --socket /tmp/sddm-:0-NUwyJj --theme /usr/share/sddm/them'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f8f1374c8d7 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:55
55	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
Missing separate debuginfos, use: zypper install Mesa-libGL1-debuginfo-11.2.2-158.1.x86_64 Mesa-libglapi0-debuginfo-11.2.2-158.1.x86_64
(gdb) bt
#0  0x00007f8f1374c8d7 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007f8f1374dcaa in __GI_abort () at abort.c:78
#2  0x00007f8f140f537e in qt_message_fatal (context=..., 
    message=<synthetic pointer>) at global/qlogging.cpp:1648
#3  QMessageLogger::fatal (this=this@entry=0x7ffdddb66c90, 
    msg=msg@entry=0x7f8f0bb9b200 "QXcbConnection: Could not connect to display %s") at global/qlogging.cpp:790
#4  0x00007f8f0bb20d4e in QXcbConnection::QXcbConnection (this=0x1e42d10, 
    nativeInterface=0x1e42b80, canGrabServer=<optimized out>, 
    defaultVisualId=4294967295, displayName=0x0) at qxcbconnection.cpp:585
#5  0x00007f8f0bb2409d in QXcbIntegration::QXcbIntegration (
    this=<optimized out>, parameters=..., argc=<optimized out>, 
    argv=<optimized out>) at qxcbintegration.cpp:179
#6  0x00007f8f0bdf948b in QXcbIntegrationPlugin::create (this=<optimized out>, 
    system=..., parameters=..., argc=@0x7ffdddb6743c: 5, argv=0x7ffdddb675d8)
    at qxcbmain.cpp:50
#7  0x00007f8f1480d24b in loadIntegration (argv=0x7ffdddb675d8, 
    argc=@0x7ffdddb6743c: 5, parameters=..., key=..., loader=
    0x7f8f14e67e10 <_ZZN12_GLOBAL__N_112Q_QGS_loader13innerFunctionEvE6holder>)
    at kernel/qplatformintegrationfactory.cpp:56
#8  QPlatformIntegrationFactory::create (platform=..., paramList=..., 
    argc=@0x7ffdddb6743c: 5, argv=argv@entry=0x7ffdddb675d8, 
    platformPluginPath=...) at kernel/qplatformintegrationfactory.cpp:73
#9  0x00007f8f14819eca in init_platform (argv=0x7ffdddb675d8, 
    argc=@0x7ffdddb6743c: 5, platformThemeName=..., platformPluginPath=..., 
    pluginArgument=...) at kernel/qguiapplication.cpp:1058
#10 QGuiApplicationPrivate::createPlatformIntegration (this=0x1e320e0)
    at kernel/qguiapplication.cpp:1227
#11 0x00007f8f1481aa5d in QGuiApplicationPrivate::createEventDispatcher (
    this=<optimized out>) at kernel/qguiapplication.cpp:1244
#12 0x00007f8f142d1d18 in QCoreApplicationPrivate::init (
    this=this@entry=0x1e320e0) at kernel/qcoreapplication.cpp:814
#13 0x00007f8f1481b40c in QGuiApplicationPrivate::init (this=0x1e320e0)
    at kernel/qguiapplication.cpp:1267
#14 0x00007f8f1481c064 in QGuiApplication::QGuiApplication (
    this=0x7ffdddb67460, argc=@0x7ffdddb6743c: 5, argv=0x7ffdddb675d8, 
    flags=329217) at kernel/qguiapplication.cpp:573
#15 0x000000000042884e in SDDM::GreeterApp::GreeterApp (this=0x7ffdddb67460, 
    argc=<optimized out>, argv=<optimized out>)
    at /usr/src/debug/sddm-0.13.0/src/greeter/GreeterApp.cpp:61
#16 0x000000000041630d in main (argc=5, argv=0x7ffdddb675d8)
    at /usr/src/debug/sddm-0.13.0/src/greeter/GreeterApp.cpp:236

(In reply to Stefan Dirsch from comment #6)
> Hmm. The only difference in xorg-x11-server between 42.2 release and update
> I can find is
> 
>  U_modesetting-set-driverPrivate-to-Null-after-closing-fd.patch
>  Prevent crash when unplugging displaylink device. (bnc#1011570)
> 
> I don't think this is the culprit and it only affects modesetting driver
> users, which you probably are not with your AMD card (check
> /var/log/Xorg.0.log or wherever your displaymanager writes the X log into).

I'll attach my current Xorg.0.log, not sure exactly what to look for there. There is a modesetting_drv loaded and notes about using "kms".

> > (from the "official" http://download.opensuse.org/repositories/Kernel:/stable/standard/ repository) 
> 
> For sure this is not the "official" kernel. This is a bleeding edge
> "kernel-of-the-day".

Yeah! But it's a nice one actually - never failed me for the last 6 months. Anywway....

> Therefore I suggest to go back to our latest Leap 42.2
> kernel (version 4.4!) and test again.
> 
> For me this looks like a race between plymouth and X. Honestly if you can
> live
> without a splash screen for boot I recommend to disable plymouth by adding
> "plymouth.enable=0" to the kernel boot options. ;-)

Did both - back to the normal 42.2 kernel (kernel-default-4.4.27-2.1.x86_64), the 4.8.x kernels removed. Tried with and without plymouth. NO CHANGE regarding the issue, sddm-greeter even coredumps when plymouth is both disabled and uninstalled (packages, initrd rebuild, though that I tested only with the 4.8.11 kernels)

Created attachment 704617 [details]
Xorg log

It seems like sddm behaves correctly here and the bug is indeed in X.org.
The plymouth crash is well-known as bug 975879.

(In reply to Patrick Schaaf from comment #9)
> Created attachment 704617 [details]
> Xorg log

modesetting is loaded (among other drivers), but radeon driver is being used. So the xorg-x11-server update can't be the culprit here.

Ok. Apparently Xserver couldn't be started. Please try this with original update kernel 4.4 for Leap 42.2 in place and plymouth uninstalled/disabled.

  X -retro -verbose 7 -logverbose 7 : 99 & sleep 3; DISPLAY=:99 xterm &

and attach 

/var/log/Xorg.99.log
              ^^

If Xserver comes up you can kill it via holding <Ctl>-<Alt> and then pressing
<Backspace> twice.

It could be that the crashing plymouthd left the vt hogged.
Maybe booting without plymouth (plymouth.enable=0 on the command line) helps and the sddm greeter screen is shown.

AFAIR, Max knows all the ins and outs of plymouth hogging VTs.

I tried several more things:

Disabling plymouth (both kernel cmdline and uninstalling packages / rebuilding initrd) does not change the issue (black screen, first sddm-greeter dumps core)

I also downgraded everything to repo snapshots I made the last few days, back to the libreoffice changes of 27.11. None of that made the issue go away. So my initial suspicion that the recent xserver updates were the culprit, or the mesa updates the day before, are out of the equation. Weird that I did not see the issue three days ago on the previous boot, though... Upgraded back to current...

I tried to boot with "nomodeset". Issue persists.

I disabled the cryptsetup (extra partition) normally running. No change.

I tried booting with my second monitor removed. Issue stays the same.

Next thing I'll try is Stefan's request wrt. running X by hand (disabling display manager startup, before I try). I'll do that now.

The final thing I can then further do, is to reinstall the system. I _did_ have some issues with an SSD (MD RAID1 setup) during the original install, but thought that was under control, but who knows.... (SSD is replaced now)

(In reply to Stefan Dirsch from comment #12)
> Ok. Apparently Xserver couldn't be started. Please try this with original
> update kernel 4.4 for Leap 42.2 in place and plymouth uninstalled/disabled.
> 
>   X -retro -verbose 7 -logverbose 7 : 99 & sleep 3; DISPLAY=:99 xterm &
> and attach  
> /var/log/Xorg.99.log

I did that, after "systemctl set-default multi-user" and reboot, so no plymouth or display manager autostart.

It worked - X started, I got the xterm, and could terminate. Do you still want to see the Xorg.99.log ?

Yes, please attach Xorg.99.log.

(In reply to Egbert Eich from comment #13)
> It could be that the crashing plymouthd left the vt hogged.
> Maybe booting without plymouth (plymouth.enable=0 on the command line) helps
> and the sddm greeter screen is shown.
> 
> AFAIR, Max knows all the ins and outs of plymouth hogging VTs.


This is clearly not the issue here. Patrick did the right thing: He uninstalled Plymouth *and* rebuilt rhe initrd. After this step, Plymouth can no longer hog the VT.

(In reply to Patrick Schaaf from comment #15)
> I did that, after "systemctl set-default multi-user" and reboot, so no
> plymouth or display manager autostart.

Not sure if that keeps Plymouth from running. Also, plymouth.enable=0 is a parameter that is evaluated by Plymouth itself.

For what it's worth, can you please keep Plymouth uninstalled (and possibly locked with zypper addlock) until we have resolved this issue? That way we make sure we don't run into something Plymouth related as well.

Of course, don't forget to rebuild the initrd after removing Plymouth :)

(In reply to Max Staudt from comment #18)
> (In reply to Patrick Schaaf from comment #15)
> > I did that, after "systemctl set-default multi-user" and reboot, so no
> > plymouth or display manager autostart.
> 
> Not sure if that keeps Plymouth from running. Also, plymouth.enable=0 is a
> parameter that is evaluated by Plymouth itself.
> 
> For what it's worth, can you please keep Plymouth uninstalled (and possibly
> locked with zypper addlock) until we have resolved this issue? That way we
> make sure we don't run into something Plymouth related as well.
> 
> Of course, don't forget to rebuild the initrd after removing Plymouth :)

plymouth was both disabled and uninstalled from tbe beginning of my comment:14

I'm reinstalling the system from zero now, back in 45 minutes...

(In reply to Max Staudt from comment #17)
> 
> This is clearly not the issue here. Patrick did the right thing: He
> uninstalled Plymouth *and* rebuilt rhe initrd. After this step, Plymouth can
> no longer hog the VT.

Ok, but the sddm greeter is calling abort() because it cannot connect to the Xserver. This is either because the Xserver isn't ready for connections, yet or sddm is using the wrong credentials - or something is grabbing it (unlikely).
When the Xserver is running but just showing a black screen one could try to obtain the credentials from the Xserver command line and then try to log in:
From a root shell (remote or after a VT switch) do:
 1. # ps aux | grep Xorg
    get the argument after '-auth'
 2. # export XAUTHORITY=<the_argument>
 3. # export DISPLAY=:0.0
 4. # xterm

Switching the DM would be something to try out as well...

Created attachment 704642 [details]
Xorg.99.log when running server + xterm by hand, as requested by Stefan Dirsch

Situation after reinstall:

The initial boot after installing, without update repositories active yet, had a plymouth coredump, but sddm-greeter did NOT coredump, and the graphical login was shown.

I then activated the update repositories, zypper dupped, and rebooted. Voila, the issue occurs again. Disabled plymouth once more, issue persists.

I now built myself an OnBootSec=45 systemd timer unit initiating "systemctl restart --no-block display-manager" - that works. Ugh...

(In reply to Egbert Eich from comment #20)
>
> When the Xserver is running but just showing a black screen one could try to
> obtain the credentials from the Xserver command line and then try to log in:
> From a root shell (remote or after a VT switch) do:
>  1. # ps aux | grep Xorg
>     get the argument after '-auth'
>  2. # export XAUTHORITY=<the_argument>
>  3. # export DISPLAY=:0.0
>  4. # xterm

That doesn't work... See transscript below. I also tried it as user, with /run/addm/{...} chmodded 644, still no joy.

rofl:~ # systemctl status display-manager
display-manager.service - X Display Manager
   Loaded: loaded (/usr/lib/systemd/system/display-manager.service; enabled; vendor preset: enabled)
   Active: ^[[0;1;32mactive (running)^[[0m since Fri 2016-12-02 16:10:35 CET; 2min 1s ago
  Process: 1300 ExecStart=/usr/lib/X11/display-manager start (code=exited, status=0/SUCCESS)
 Main PID: 1390 (sddm)
    Tasks: 4 (limit: 512)
   CGroup: /system.slice/display-manager.service
           ├─1390 /usr/bin/sddm
           └─1402 /usr/bin/X -nolisten tcp -auth /run/sddm/{b8afb90f-46c8-4438-9a97-1bf82d128e7b} -background none -noreset -displayfd 18 vt7

Dec 02 16:10:36 linux sddm[1390]: Socket server started.
Dec 02 16:10:36 linux sddm[1390]: Greeter starting...
Dec 02 16:10:36 linux sddm[1390]: Adding cookie to "/run/sddm/{b8afb90f-46c8-4438-9a97-1bf82d128e7b}"
Dec 02 16:10:36 linux sddm-helper[1671]: [PAM] Starting...
Dec 02 16:10:36 linux sddm-helper[1671]: [PAM] Authenticating...
Dec 02 16:10:36 linux sddm-helper[1671]: [PAM] returning.
Dec 02 16:10:36 linux sddm-helper[1671]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)
Dec 02 16:10:53 rofl sddm[1390]: Greeter session started successfully
Dec 02 16:10:53 rofl sddm[1390]: ^[[0;1;39mAuth: sddm-helper exited with 6^[[0m
Dec 02 16:10:53 rofl sddm[1390]: Greeter stopped.
rofl:~ # coredumpctl list
TIME                            PID   UID   GID SIG PRESENT EXE
[... stuff from previous boots ...]
Fri 2016-12-02 16:10:54 CET    2045   481   479   6 * /usr/bin/sddm-greeter
rofl:~ # export XAUTHORITY=/run/sddm/{b8afb90f-46c8-4438-9a97-1bf82d128e7b\}
rofl:~ # export DISPLAY=:0.0
rofl:~ # xterm
No protocol specified
Warning: This program is an suid-root program or is being run by the root user.
The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm: Xt error: Can't open display: %s

(In reply to Egbert Eich from comment #20)
> 
> Switching the DM would be something to try out as well...

Switched to kdm - NO ISSUE.

(accidentally first installed gdm, that drew in over 200 packages, of which "zypper remove -u gdm" only could remove 97 again. just noting...)

I'll give up for today. But if there's other things to try, I can do that during the weekend.

The fact that kdm worked for you could definitely mean that this has nothing to do with X.Org.


rofl:~ # export XAUTHORITY=/run/sddm/{b8afb90f-46c8-4438-9a97-1bf82d128e7b\}
rofl:~ # export DISPLAY=:0.0
rofl:~ # xterm

Did you check the existence of this file: /run/sddm/{b8afb90f-46c8-4438-9a97-1bf82d128e7b}?
If it does exist, 
# export XAUTHORITY=/run/sddm/{b8afb90f-46c8-4438-9a97-1bf82d128e7b}
# xauth list
should give some output.

(In reply to Egbert Eich from comment #25)
>
> Did you check the existence of this file:
> /run/sddm/{b8afb90f-46c8-4438-9a97-1bf82d128e7b}?

Yes. It does exist.

> If it does exist, 
> # export XAUTHORITY=/run/sddm/{b8afb90f-46c8-4438-9a97-1bf82d128e7b}
> # xauth list
> should give some output.

It does. Something like:

rofl:~ # xauth info
Authority file:       /run/sddm/{e38ebf58-e9d4-453d-8562-d357d7ab5238}
File new:             no
File locked:          no
Number of entries:    1
Changes honored:      yes
Changes made:         no
Current input:        (argv):1

All fine, I think.

Rebooted some more this morning...

On the suspicion that there would be some timing problem between sddm, X, and sddm-greeter startup, I wrapped sddm-greeter with a shellscript, and then used that to log some environmental and process list stuff, as well as introduce some delay.

The logged argument and environment information was inconspicuous between the nonworking after-boot run and the subsequent working run when manually restarting the display-manager unit.

Sleeping for some seconds before really starting sddm-greeter, did NOT help. So, it's not simply a timing issue between sddm starting X, and starting the greeter.

But, comparing the logged process lists between the after-boot (does not work) scenario, and a subsequent working run (systemctl restart display-manager), I got a suspicion.... I noticed that sddm (and X) were started rather early, immediately after wickedd came up, but BEFORE systemd-logind.

On that suspicion, I added an After= dependency on systemd-logind to the display-manager.service unit - and that GOT IT TO WORK!

Not I don't really know what I'm doing here :) ..... but I hope that might help you understand the issue better.

Thanks! Good catch, Patrick! This finally makes sense. ;-)

Werner, could you adjust the display-manager.service unit according to comment #27?

This change may be required for gdm as well.

I reinstalled once more this morning, with the goal to find out why I did not see the blank screen issue immediately after install, but only after I dupped with update repos (and a private repo with some stuff unrelated to X, but nevertheless bringing in some systemd units on my own. And I used an autoyast install that I've been working on the last days, instead of a plain manual installer.

Anyway, really strange result is, that I can no longer reproduce the blank screen issue. It was fine after autoyast (including update repos), it stayed okay when I successively added my own stuff, and it even keeps working file after reenabling plymouth again.

Comparing package lists to the previous nonworking installs, confirms to me that I did not miss anything that might be related.

All that without a modified display-manager.service, and ps always confirmed that sddm+X started clearly BEFORE systemd-logind (4.5 seconds, in the current boot).

So... I once more don't know what was going on here... and an on-suspicion addition of After=systemd-logind in display-manager.service is probably not warranted at the moment.

Indeed good catch ... SR#443776 for Factory
                  and SR#125113 for SLES12-SP2/Leap-42.2

Remark: SR#125113 for SLES12-SP2/Leap-42.2

xdm on Leap is not inherited from Leap. (see openSUSE:Leap:42.2:Update 00Meta lookup.yml) Could you do a separate submission to openSUSE:Leap:42.2:Update please?

Thanks in advance.

(In reply to Benjamin Brunner from comment #32)
> xdm on Leap is not inherited from Leap. (see openSUSE:Leap:42.2:Update
> 00Meta lookup.yml) Could you do a separate submission to
> openSUSE:Leap:42.2:Update please?

They differ only in a changelog date, so we could actually change that:
osc rdiff SUSE:SLE-12-SP2:Update/xdm openSUSE:Leap:42.2:Update/xdm

(In reply to Andreas Stieger from comment #33)

OK ... see SR#443862

This is an autogenerated message for OBS integration:
This bug (1013200) was mentioned in
https://build.opensuse.org/request/show/443862 42.2 / xdm

Ok. Let's close this one as fixed after the SR#443862 by Werner, that I've just accepted.

Apparently the sddm issue is no longer reproducable and the plymouth crash already tracked in bnc#975879 since April 2016.

openSUSE-RU-2016:3122-1: An update that has one recommended fix can now be installed.

Category: recommended (low)
Bug References: 1013200
CVE References: 
Sources used:
openSUSE Leap 42.2 (src):    xdm-1.1.11-13.1

SUSE-RU-2017:0117-1: An update that has one recommended fix can now be installed.

Category: recommended (low)
Bug References: 1013200
CVE References: 
Sources used:
SUSE Linux Enterprise Server for Raspberry Pi 12-SP2 (src):    xdm-1.1.11-41.16.1
SUSE Linux Enterprise Server 12-SP2 (src):    xdm-1.1.11-41.16.1
SUSE Linux Enterprise Desktop 12-SP2 (src):    xdm-1.1.11-41.16.1