Bug 809806

Can you attach the kdmrc file, so that we can have a look at it. As that it works after the system has completed the boot process, it could also be the timing that the xdm.service is started and that maybe at that moment, the other VT's are not enabled/available. 

The jump from 11.4 to 12.3 is quite big, so the question is here if it is indeed a KDE bug or another component.

Just found a workaround by adding the two lines


 case "$1" in
     start)

+        command -p setconsole /dev/tty1 < /dev/console > /dev/null 2>&1
+        command -p chvt --userwait 1 > /dev/null 2>&1


.... this helps a lot as now kdm does its work.

the lines had been added in /etc/init.d/xdm, teh LSB boot script :)

Created attachment 530057 [details]
/usr/share/kde4/config/kdm/kdmrc

Here we are

IMHO the bug does not depend on the kdmrc but the place where kdm is executed.
It kdm is started on VT7 it tries to execute all three X server on VT7. If kdm is started on VT1 the it seems that the configuration given in kdmrc wins.

The control messages of kdm_config are useless as it can not distinguish between different :*-Core nor :*-Greeter entries.

As that you have the terminals hardcoded in the config (ServerVT=7,8,9,...), did you ever tried to see what happens if you let KDM do the assignments ? (removing that entry from the corresponding 1, 2, 3rd display core settings ?

(In reply to comment #6)

Do you have noticed that with the workaround above the kmdrc does its work?

Without the two lines it does not work regardless if I remove the ServerVT=7,9,9
lines ... with the two lines it takes only a few seconds longer as it seems that the kdm now starts the X servers with a delay  ...

I just added

 plymouth_quit

before the the two lines to avoid dead locks which may happen.  Not in the kernel but the boot process stops as plymouth locks doesn the all consoles.

Werner, I don't understand your last comment ?  What do you mean with "but the boot process stops as plymouth locks doesn't the all consoles"  ?

Just tried it using the shell function

   plymouth_quit

is enough to allow the kdm and X servers to use more than VT7.

The `doesn' should be read as `down' ... it was `some' minutes after midnight.
Plymouth combines some features of my old blogd(8) together with a splash screen layer in user space by using kernel-based mode setting. With the side effect that VT are locked/controlled by plymouth as it is providing a /dev/console on a pty/tty pair.

Search for Plymouth at
 http://www.freedesktop.org/wiki/Software/systemd/multiseat

I have started working on a kdm with proper multiseat support, which is available in my home project:

https://build.opensuse.org/package/show?package=kdebase4-workspace&project=home%3AStefanBruens%3Abranches%3AKDE%3ARelease%3A410

Multiseat and Systemd support is only enaybled for 12.3, though.

Problems with plymouth / vt switching are most probably due to kdm_plymouth.patch in the kdebase4-workspace package.

These problems are still somewhat existent in the current package, will work on it ...

(In reply to comment #13)

Are you pretty sure? This because the errors are reported from the X servers as all X servers tries to open the same console vt7 which in fact will not work.

kdm_plymouth.patch has the following diff for allocateVT:

+            if (plymouth_has_active_vt ()) {
+                /* plymouth was displaying a splash screen and has
+                 * terminated leaving it on screen
+                 */
+                int vt;
+                vt = get_active_vt ();
+                if (vt > 0) {
+                    /* start the X server on the active vt */
+                    d->serverVT = vt;
+                    return;

Normally, it would use reqSrvVT (==ServerVT in kdmrc) or search a unused one itself.

(In reply to comment #15)

Ouch ... from change log

 Sun Jan  6 17:04:04 UTC 2013 - tittiatcoke@gmail.com
 - Updated plymouth patch with the correct path (/usr/bin/plymouth)

please remove this part of the patch or make it smart that is start only  the
*first* X server on the splash screen!

I've send an SR#180233 which hopefully repairs this ... now the pathc looks like

+            if (plymouth_has_active_vt ()) {
+                /* plymouth was displaying a splash screen and has
+                 * terminated leaving it on screen
+                 */
+                int vt;
+                vt = get_active_vt ();
+                if (vt > 0) {
+                    if (d->reqSrvVT <= 0 || d->reqSrvVT == vt) {
+                        /* start this X server on the active vt */
+                        d->serverVT = vt;
+                        return;
+                    }
+                }
+           }

the same on

+        /* fallback to old/deprecated method */
+        } else if ( triggered_to_force_display_on_active_vt() >= 0 ) {
+            int vt;
+            vt = get_active_vt();
+            if (vt > 0) {
+                if (d->reqSrvVT <= 0 || d->reqSrvVT == vt) {
+                    d->serverVT = vt;
+                    return;
+                }
+            }
+        }

Looks good to me, will test tomorrow

OT: Why does the bugzilla show US East Coast (?) time and labels it with UTC?

Q: Had the patch worked and if so how about adding this for an update for the package of 12.3

Hm, I am not sure if this works correctly when reqSrvVT is not set. I think the plymouth code should be moved below the iteration through the list of serverVTs, although this than needs alteration to accept plymouth' VT although it is active.

I have completely reworked the plymouth patch, it should work in any case, see  https://bugzilla.redhat.com/show_bug.cgi?id=975079#c11 for details.

I has been tested by at least one multiseat user, and I will test it myself later.

@Werner: can you test it as well, both with and without explicit ServerVT for the different displays?

Testcatalog:
1. Singleseat - X server starts, replaces either plymouth splash screen (quiet case) or the text console (nosplash, ESCape from splash).

2. Static multiseat: all X servers start, each on a different VT, one replaces plymouth/text console

3. Dynamic multiseat: First X server starts as in 1., second server starts and presents greeter on hotplug

(In reply to comment #21)

OK ... but where can I find repository/package[1]?  Does this work on an openSUSE 12.3 or does it cause an full update of KDE libraries as well?


[1] Maybe home:StefanBruens:branches:KDE:Distro:Factory/kdebase4-workspace

Hmmm ... seems to be

home:StefanBruens:branches:KDE:Release:410/kdebase4-workspace/kdm_plymouth.patch

Both repositories are fine.

The K:D:F branch was just updated with the latest patch and is currently building, the K:R:410 branch just got a more complete changelog but is otherwise unchanged (4.10.4-26.1 should be recent enough, 4.10.4-28.1 is currently building)

(In reply to comment #21)

My configuration [1]:

> 2. Static multiseat: all X servers start, each on a different VT, one replaces
> plymouth/text console

does *not* work.  After removing the

     plymouth_quit

at start in /etc/init.d/xdm which I've added below `start)' the Xserver's do not crash anymore but now plymouth blocks VT7 and the only key stroke which had worked was Ctrl-Alt-Del to cause a reboot ... if I press then ESC to switch plymouth into background to see the boot messages I was able to access one of the Xserver's

Now I've readded the plymouth_quit.

[1]:

 /home/werner> grep -E '[012]-Core|ServerVT' /usr/share/kde4/config/kdm/kdmrc
 ServerVTs=-7
 [X-:0-Core]
 # Better leave it zero and use ServerVTs.
 ServerVT=7
 [X-:1-Core]
 ServerVT=8
 [X-:2-Core]
 ServerVT=9

Hi Werner,

just pushed a new patch with debug statements, functionality unchanged.

What I am interested in:

- output of "cat /var/log/messages | grep kdm", i.e. any debug output from kdm
- output of "ps aux | grep X", i.e. the arguments the X servers are started with

What does "the Xserver's do not crash anymore" mean?

(In reply to comment #26)

> What does "the Xserver's do not crash anymore" mean?

Before this change the three Xserver's where started on VT7 which had caused that the Xserver's died and kdm had exit with an error.  After this plymouth had stopped normally with the boot process and I was able to do stop the xdm services and the restart it.  This was the reason for me to add the plymouth_quit shell function in the start section /etc/init.d/xdm


> What I am interested in:
> 
> - output of "cat /var/log/messages | grep kdm", i.e. any debug output from kdm
> - output of "ps aux | grep X", i.e. the arguments the X servers are started
> with

This will become complicated as plymouth screen is locked and the only command I'm able to do is Ctrl-Alt-Del to trigger a reboot.  I do not have network access at home.  Maybe I have to add a watch background process in /etc/init.d/xdm to get this information.

Yes, that is what i would expect for old version of the patch -

allocateVT and server start are done in distinct passes, so all displays get VT7, as this is the VT plymouth is active on, and later on during server startup plymouth is actually quit.

The new version avoids this problem, but there seems to be something wrong with the plymouth shutdown.

I think I have to dig into plymouth what the different commands are actually doing ...

Anyway, the new version leaves some debug output in /var/log/messages, which survives the reboot.

To get the output, you can specify systemd.unit=multi-user.target on the kernel commandline (=^ runlevel 3).

Another possibility is to add "-debug 0x81", which redirects the kdm output to /var/log/kdm.log and increases the verbosity level of the kdm core, including the exec commands for the X server. Warning - this might include sensible information like passwords.

Hmmm ... in /etc/init.d/xdm the shell function plymouth_quit looks like

  plymouth_quit()
  {
      if [ -x /usr/bin/plymouth ]; then
           plymouth quit
           plymouth --wait
      fi
  }

maybe the wait is what is missed in kdm?

Created attachment 546244 [details]
output.log

I've selected the output of the current running X server as well as the
kdm/xdm messages short after installation time of the kdm with new plymouth.
The file output.log shows 

  ps aux | grep Xorg > output.log

as well as

  xzgrep -E '2013-06-26T21:[345]' /var/log/messages-20130627.xz | grep -5 -E '[xk]dm' >> output.log

Hm, are you sure you were running the last version from my repository - there should be some more debug output, i.e. output of the exit codes from all the queries towards plymouth.

Unfortunately, you wont be able to update at the moment, as the repository is already updated to KDE 4.10.5, which will be published next tuesday (most probably).

(In reply to comment #31)

I've installed the version which I had found at home:StefanBruens:branches:KDE:Release:410/kdebase4-workspace/

... and I had read the kdm_plymouth.patch ... AFICR there was no extra debugging code. Maybe I've used an older version.

Neverthless IMHO using

  /usr/bin/plymouth quit

without

  /usr/bin/plymouth --wait

may lead to the problem that two different programs try to open the same VT at the same time and both plymouth and the X server want to open a VT exclusively

Ok, I think I know why this was no issue for me - I use the /usr/lib/systemd/systemd-multi-seat-x wrapper which adds "-sharevts".

I have changed the plymouth quit calls to "/usr/bin/plymouth quit [--retain-splash] --wait", which should solve the issue.

Currently building, please check the changelog of the KDM package to make sure you have the correct version. Should be ready at 20:30 CEST.

(In reply to comment #33)

OK .. I'll do this tomorrow, thanks for fiddling this out

Just another question:

which mechanism do you use to assign the graphics cards and input devices to the different seats?

I assign distinct "seat-<xxx>" tags to the devices using udev rules, and use different layout sections for each seat. The latter is only necessary because one seat has 2 monitors, the other one only 1, otherwise the udev rules would be sufficient.

(In reply to comment #35)

This is one seat but three X servers on VT7, VT8, and VT9.  With this it is possible that my wife, my daughter, and me are able to hold our sessions open or open an other session.  Yes I'm aware that kde has the option to start a new session on demand on a new VT but out method is now several years in use and works with all display managers as well as with all window managers.

(In reply to comment #33)

To which package do you refere ... the https://build.opensuse.org/package/show/home:StefanBruens:branches:KDE:Release:410/kdebase4-workspace is broken

(In reply to comment #33)

How do you do this?

The repository is located at:
http://download.opensuse.org/repositories/home:/StefanBruens:/branches:/KDE:/Release:/410/openSUSE_12.3/

You can check the changelog with rpm:
rpm -q --changelog kdm | head -n 30

* Tue Jul 02 2013 stefan.bruens@rwth-aachen.de
- make the plymouth quit call synchronous to avoid a race condition
  between X server claiming the VT before plymouth releases it

... makes no difference, if I do not use the shell function plymouth_quit
in /etc/init.d/xdm beforestarting the kdm the boot splash remains for ever
upto the point where I press Ctrl-Alt-Del

I've played with a script /usr/bin/Xorg.multi

 #!/bin/bash
 if plymouth --ping ; then
     plymouth quit
     plymouth --wait
 fi
 chvt --userwait 7
 exec -a /usr/bin/Xorg /usr/bin/Xorg -sharevts ${1+"$@"}

this works sometimes but if the other Xservers crash away even if

 ServerCmd=/usr/bin/Xorg.multi

in /usr/share/kde4/config/kdm/kdmrc was set in [X-:0-Core] only.

Created attachment 546720 [details]
output.log

Here the log for the first case from /var/log/warn (not /var/log/messages)

Created attachment 546739 [details]
plymouth-wrapper

Unfortately, the --wait statement was ineffective because it must be placed before the quit command -> fixed

See also the appended plymouth wrapper, which might give some more insight.

sudo mv /usr/bin/plymouth{,.bin}
sudo cp plymouth_wrapper /usr/bin/plymouth
sudo chmod +x /usr/bin/plymouth

(In reply to comment #43)

Hmmm ...  --wait waits forever as quit is noit reached anymore. Even the
script

 #!/bin/bash
 if plymouth --ping ; then
     typeset -i vt=7
     for x
     do
         case "$x" in
         vt*) vt=${x#vt}
              break
         esac
     done
     set -- -sharevts ${1+"$@"}
     chvt --userwait $vt
     plymouth quit &
     plymouth --wait
     usleep 10000
 fi
 exec -a /usr/bin/Xorg /usr/bin/Xorg ${1+"$@"}

does not work.  If not pressed ESC the boot screen stays for ever and if
ESC pressed then only the first X server starts and the other shows:

  [    13.021] (EE) intel(0): [drm] failed to set drm interface version.
  [    13.021] (EE) intel(0): Failed to become DRM master.
  [    13.021] (II) UnloadModule: "intel"
  [    13.021] (EE) Screen(s) found, but none have a usable configuration.

and /var/log/warns has this

 2013-07-04T17:53:12.161852+02:00 speedy kdm[1476]: plymouth --ping -> 0
 2013-07-04T17:53:12.162074+02:00 speedy kdm[1476]: plymouth is running ...
 2013-07-04T17:53:12.184325+02:00 speedy kdm[1476]: plymouth deactivate -> 0
 2013-07-04T17:53:12.187735+02:00 speedy kdm[1476]: plymouth --has-active-vt -> 0
 2013-07-04T17:53:12.188118+02:00 speedy kdm[1476]: plymouth is active on VT 7
 2013-07-04T17:53:12.188266+02:00 speedy kdm[1476]: plymouth should quit when server starts
 2013-07-04T17:53:12.190868+02:00 speedy kdm[1476]: plymouth --ping -> 0
 2013-07-04T17:53:12.191098+02:00 speedy kdm[1476]: plymouth is running ...
 2013-07-04T17:53:12.203080+02:00 speedy kdm[1476]: plymouth deactivate -> 0
 2013-07-04T17:53:12.205700+02:00 speedy kdm[1476]: plymouth --has-active-vt -> 0
 2013-07-04T17:53:12.206034+02:00 speedy kdm[1476]: plymouth is active on VT 7
 2013-07-04T17:53:12.206193+02:00 speedy kdm[1476]: Active VT: 7, busy mask: 0x4c1
 2013-07-04T17:53:12.207660+02:00 speedy kdm[1476]: plymouth --ping -> 0
 2013-07-04T17:53:12.208007+02:00 speedy kdm[1476]: plymouth is running ...
 2013-07-04T17:53:12.219665+02:00 speedy kdm[1476]: plymouth deactivate -> 0
 2013-07-04T17:53:12.222100+02:00 speedy kdm[1476]: plymouth --has-active-vt -> 0
 2013-07-04T17:53:12.222447+02:00 speedy kdm[1476]: plymouth is active on VT 7
 2013-07-04T17:53:12.222672+02:00 speedy kdm[1476]: Active VT: 7, busy mask: 0x4c1
 2013-07-04T17:53:14.231428+02:00 speedy kdm[1476]: Quitting Plymouth with transition
 2013-07-04T17:53:14.243746+02:00 speedy kdm[1476]: plymouth quit --retain-splash -> 1
 2013-07-04T17:53:14.244149+02:00 speedy kdm[1476]: Is Plymouth still running? yes
 2013-07-04T17:53:16.405106+02:00 speedy kdm[1476]: X server for display :2 terminated unexpectedly
 2013-07-04T17:53:17.829401+02:00 speedy kdm[1476]: X server for display :1 terminated unexpectedly
 2013-07-04T17:53:17.849336+02:00 speedy kdm[1476]: X server died during startup
 2013-07-04T17:53:17.849641+02:00 speedy kdm[1476]: X server for display :1 cannot be started, session disabled


IMHO the plymouth concept has a nice look but it *is* broken by design,
that is it should *never* block any VT nor tty

Actually it is the VT handling in the Kernel which broken by lack of design. (Linus Torvalds opion on VT_ACTIVATE/VT_WAITACTIVE: https://bugzilla.redhat.com/show_bug.cgi?id=323501#c3 )

The problem is the kernels behaviour when the foreground (=^active) console is in mode KD_GRAPHICS and the terminal is in control mode VT_AUTO (opposed to VT_PROCESS). In this case the VT_ACTIVATE is silently dropped and VT_WAITACTIVE will hang until:
a) another process grabs the active VT and puts it into VT_PROCESS mode, then manual (CTRL-[ALT]-Fx) switching becomes possible again
b) VT_ACTIVATE was a noop in the first place

The second case is what happens in the typical setup, plymouth is on VT7 and X "switches" to VT7.

The behaviour was introduced by this patch from 2007: http://linux.kernel.narkive.com/NadYBuBi/patch-software-suspend-fix-suspend-when-console-is-in-vt-auto-kd-graphics-mode

This is almost impossible to do correctly. plymouth can no longer listen to any signals for the VT, as it has to close it before the X server can open it, so it must go out of VT_PROCESS mode. Setting KD_TEXT on the other hand the screen will flicker ...

I have an idea how to solve this (needs some more work on the KDM plymouth patch, and a small change in plymouth ...)

Hi Werner,

I think the latest patch covers all use cases now. Some more comments:

Re: https://bugzilla.novell.com/show_bug.cgi?id=809806#c44
[    13.021] (EE) intel(0): Failed to become DRM master.
This is what must happen when you start multiple X servers using the same hardware and use "-sharevts". "-sharevts" skips the initial VT change during server startup, thus the first server never releases the hw and the second one fails.

The kdm patch now makes sure it first starts the server which replaces plymouth (same VT), thus there is no VT switch needed during server startup (actually it still switches from (e.g.) VT7 to VT7). If the server startup succeeds, plymouth will get a quit request with "retain", so it leaves the VT alone (it is already controlled by X now). In case of failure, plymouth gets a quit without retain, it then reopens the VT, switches away to the initial VT(1) - getty - and releases VT7.

There is a small bug in plymouth not resetting the console mode back to KD_TEXT if is the last user and is about to quit, will SR a package fixing this.

(In reply to comment #46)
This does work without the plymouthquit shell command in /etc/init.d/xdm and without the Xorg.multi wrapper script.  With the Xorg.multi wrapper script the
plymouth is stoppped but the console is not accessible anymore due -sharevts option I guess.

The normal case *does* work. Only the screen visible is now vt8 not vt7. I guess that this is caused duethe waiting loop on plymouth:

2013-07-12T23:21:09.006026+02:00 speedy kdm[1404]: plymouth is running
2013-07-12T23:21:09.007870+02:00 speedy kdm[1404]: plymouth is active on VT 7, reusing for :0
2013-07-12T23:21:09.009627+02:00 speedy kdm[1404]: plymouth is running
2013-07-12T23:21:09.041226+02:00 speedy kdm[1404]: last message repeated 2 times
2013-07-12T23:21:09.041155+02:00 speedy kdm[1404]: plymouth should quit when server starts
2013-07-12T23:21:09.180634+02:00 speedy kdm[1404]: plymouth is running
2013-07-12T23:21:09.195668+02:00 speedy kdm[1404]: plymouth should quit when server starts
2013-07-12T23:21:09.199040+02:00 speedy kdm[1404]: plymouth is running
2013-07-12T23:21:09.224085+02:00 speedy kdm[1404]: plymouth should quit when server starts
2013-07-12T23:21:09.225958+02:00 speedy kdm[1404]: plymouth is running
2013-07-12T23:21:09.239815+02:00 speedy kdm[1404]: plymouth should quit when server starts
2013-07-12T23:21:09.241516+02:00 speedy kdm[1404]: plymouth is running
2013-07-12T23:21:09.260398+02:00 speedy kdm[1404]: plymouth should quit when server starts
2013-07-12T23:21:09.262150+02:00 speedy kdm[1404]: plymouth is running
[...]
2013-07-12T23:21:11.180887+02:00 speedy kdm[1404]: plymouth is running
2013-07-12T23:21:11.197801+02:00 speedy kdm[1404]: plymouth should quit when server starts
2013-07-12T23:21:11.201460+02:00 speedy kdm[1404]: plymouth is running
2013-07-12T23:21:11.227630+02:00 speedy kdm[1404]: plymouth should quit when server starts
2013-07-12T23:21:11.228112+02:00 speedy kdm[1404]: Quitting Plymouth with transition
2013-07-12T23:21:11.271651+02:00 speedy kdm[1404]: Is Plymouth still running? no
2013-07-12T23:21:11.274762+02:00 speedy kdm[1404]: plymouth is NOT running

...

Nice to know it works.

The large number of running/should quit messages is due to the design of the kdm event loop, will fix this ...

"Only the screen visible is now vt8 not vt7" - that is, the other displays are there, but you are used to have VT7 active by default? Thats due to the fact the server on VT7 is started first, then all other servers are started in reverse order, in your case VT9 and VT8.

(In reply to comment #48)

Indeed I see now three times (or three times a flicker to be more correct) a black screen with a clock cursor and then the VT8 is visible.

The process table shows:

root      2086  0.0  0.1 145344 17904 tty7     Ss+  09:26   0:01 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -seat seat0 -auth /var/lib/kdm/AuthFiles/A:0-6J8Jfa
root      2950  0.0  0.2 180016 44412 tty9     Ss+  09:26   0:06 /usr/bin/Xorg -br :2 vt9 -nolisten tcp -novtswitch -layout Seat0.2 -seat seat0 -auth /var/lib/kdm/AuthFiles/A:2-aNtcec
root      3228  0.0  0.1 150724 21180 tty8     Ss+  09:26   0:00 /usr/bin/Xorg -br :1 vt8 -nolisten tcp -novtswitch -layout Seat0.1 -seat seat0 -auth /var/lib/kdm/AuthFiles/A:1-7Dqysb

This is an autogenerated message for OBS integration:
This bug (809806) was mentioned in
https://build.opensuse.org/request/show/183857 Factory / kdebase4-workspace

Sorry to say, but something seems to be wrong with this new patch.
Since I installed the new kdebase4-workspace package, kdm fails to start on boot on my system (12.3 64bit with KDE 4.10.95 from KDE:Distro:Factory, standard KDM configuration).

Last message on screen is "Reached graphical target", I have to press Ctrl+Alt+F1, login in text mode and start kdm manually (init 3, init 5) then it starts up, but on VT8 instead of VT7.
And plymouthd keeps running (I still see the bootsplash when I switch to VT7) and it constantly uses 5-6% CPU time, even when I am already logged in to KDE.

This also happens if I press ESC during boot to get the boot text messages.

Sometimes instead of getting a login screen, the screen even just turns black and not even Ctrl+Alt+Fn works (but I can press Ctrl+Alt+Del to reboot).

Comment#51 was not entirely correct, sorry:
I seem to get the black screen EVERYTIME, unless I press ESC during boot.

If I do press ESC, kdm fails to start. "systemctl status xdm" gives me this in that case:
xdm.service - LSB: X Display Manager
          Loaded: loaded (/etc/init.d/xdm)
          Active: active (running) since Mon, 2013-07-22 10:53:23 CEST; 2min 12s ago
         Process: 1252 ExecStart=/etc/init.d/xdm start (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/xdm.service
                  └ 1280 /usr/bin/kdm

Jul 22 10:53:24 amiga kdm_config[1281]: Multiple occurrences of section [X-*-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
Jul 22 10:53:24 amiga kdm_config[1281]: Multiple occurrences of section [X-*-Greeter] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
Jul 22 10:53:24 amiga kdm_config[1281]: Multiple occurrences of key 'UseTheme' in section [X-*-Greeter] of /usr/share/kde4/config/kdm/kdmrc
Jul 22 10:53:24 amiga kdm_config[1281]: Multiple occurrences of section [X-:*-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
Jul 22 10:53:24 amiga kdm_config[1281]: Multiple occurrences of section [X-:0-Core] in /usr/share/kde4/config/kdm/kdmrc. Consider merging them.
Jul 22 10:53:24 amiga kdm[1280]: plymouth is running
Jul 22 10:53:24 amiga kdm[1280]: plymouth is active on VT 7, reusing for :0
Jul 22 10:53:27 amiga kdm[1280]: X server died during startup
Jul 22 10:53:27 amiga kdm[1280]: X server for display :0 cannot be started, session disabled
Jul 22 10:53:27 amiga kdm[1280]: Quitting Plymouth without transition

As said, I can then manually start kdm with "init 3" followed by "init 5", but it starts on VT8 instead of VT7 and plymouthd keeps using 5-6% CPU time constantly until I kill it.

If I disable plymouth with the "plymouth.enable=0" boot parameter, everything works fine.

Wolfgang, thanks for bringing this up.

Stefan could you have a look at it, please? I'll block the release for the 12.3 update for the moment.

(In reply to comment #53)
> I'll block the release for the 12.3
> update for the moment.
Which update? I can only find this: https://build.opensuse.org/project/show/openSUSE:Maintenance:1871 which doesn't include this change.

In the meantime I also found this pending plymouth update and installed it:
https://build.opensuse.org/project/show/openSUSE:Maintenance:1860

But even with this update my problems persist.

The package with the fixed plymouth should be in openSUSE:Maintenance:1860.

(In reply to comment #55)
> The package with the fixed plymouth should be in openSUSE:Maintenance:1860.

Yes, that's what I installed. But that didn't change anything for me.

(In reply to comment #56)
> (In reply to comment #55)
> > The package with the fixed plymouth should be in openSUSE:Maintenance:1860.
> 
> Yes, that's what I installed. But that didn't change anything for me.

the plymouth fix in openSUSE:Maintenance:1860 only affects "plymouth --quit" without --retain-splash .

For unknown reasons the wrong code path if triggered in the replacePlymouth() function in dm.c. I will further investigate, expect more answers tomorrow morning ...

The code stumbles over the reserved servers ...

Possible fix is in 
https://build.opensuse.org/package/rdiff/home:StefanBruens:branches:KDE:Distro:Factory/kdebase4-workspace?opackage=kdebase4-workspace&oproject=KDE%3ADistro%3AFactory&rev=2

Will test and SR eventually

(In reply to comment #58)
> Possible fix is in 
> https://build.opensuse.org/package/rdiff/home:StefanBruens:branches:KDE:Distro:Factory/kdebase4-workspace?opackage=kdebase4-workspace&oproject=KDE%3ADistro%3AFactory&rev=2

I installed that package and it works fine for me now.
KDM/X succeeds to start and runs on VT7 as it should.

Thank you!

After the plymouth update isn't related to the kdebase4-workspace fix, I released it and we can start an separate update afterwards.

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

Category: recommended (important)
Bug References: 809806
CVE References: 
Sources used:
openSUSE 12.3 (src):    plymouth-0.8.8_git201211022126-4.10.1

fixed?

Stephan,

The only thing I know is that we accepted the patch that Stefan Bruens created and that patch is part of workspace in 13.1.

my question was more towards Stefan

kdebase4-workspace / kdm is fine for 12.3 and 13.1

the plymouth patch was left out for 13.1, see
https://build.opensuse.org/request/show/220631

Plymouth update for 13.1 is now released too. I think we can close this bug now.

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

Category: recommended (moderate)
Bug References: 809806
CVE References: 
Sources used:
openSUSE 13.1 (src):    plymouth-0.8.8_git201309032142-2.5.1

Any chance to get a fixed package for 12.3 or a patch?
I tried to adopt the patch from above to kdm-4.10.0-1.8.1 and start 2 KDMs at boot, but the Xserver on vt7 crashes with 
[     4.037] (WW) Falling back to old probe method for vesa
[     4.037] (EE) Screen 0 deleted because of no matching config section.
[     4.037] (II) UnloadModule: "modesetting"
[     4.037] 
Fatal server error:
[     4.037] Cannot run in framebuffer mode. Please specify busIDs        for all framebuffer devices
[     4.037] 
[     4.037] (EE) 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
[     4.037] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[     4.037] (EE) 

When restarting the kdm it works as expected.
Updated plymouth-package (plymouth-0.8.8_git201211022126-4.10.1) is also installed