Bug 19834 - prefdm breaks sddm in KVM
Summary: prefdm breaks sddm in KVM
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: release_blocker critical
Target Milestone: ---
Assignee: Base system maintainers
QA Contact: Samuel Verschelde
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 19782
  Show dependency treegraph
 
Reported: 2016-11-23 18:32 CET by Neal Gompa
Modified: 2016-12-02 01:30 CET (History)
4 users (show)

See Also:
Source RPM: systemd-230-5.mga6.src.rpm
CVE:
Status comment: Should be fixed since the 30th of November, via systemd-units update


Attachments

Description Neal Gompa 2016-11-23 18:32:15 CET
Description of problem:
When installing Mageia Cauldron through a netinstall for Plasma desktop, I got the "good luck" bug. 

This is on Fedora 25 KVM host, using virt-manager.

I was able to make the problem go away and get sddm to work reliably by doing the following:
systemctl disable --now prefdm.service
systemctl enable --now sddm.service

After that, sddm works properly all the time for successive reboots, cold start-ups after shutdown, etc..

I'm not sure what about prefdm causes sddm to break, but it does on every VM I've made.

Name-Version-Release number of selected component (if applicable):
systemd-units-230-5.mga6
sddm-0.14.0-10.mga6

How reproducible:
Always

Steps to Reproduce:
1. Install Cauldron via a netinstall for Plasma 5 Desktop in KVM
2. Reboot
Neal Gompa 2016-11-23 18:33:50 CET

Blocks: (none) => 19782

Neal Gompa 2016-11-23 18:34:14 CET

Blocks: 19782 => (none)

Neal Gompa 2016-11-23 18:34:40 CET

Blocks: (none) => 19782

Rémi Verschelde 2016-11-23 21:59:08 CET

Priority: Normal => release_blocker
CC: (none) => mageia, mageia
Assignee: bugsquad => basesystem

Comment 1 Neal Gompa 2016-11-23 22:49:36 CET
After some digging and testing, I was able to make prefdm->sddm work reliably by doing the following:

```
mkdir -p /etc/systemd/system/prefdm.service.d
cat > /etc/systemd/system/prefdm.service.d/00-restartsecfix.conf << EOF
[Service]
RestartSec=1s
EOF
systemctl daemon-reload
```

I originally tried with 5 seconds, then dropped it down to 2 seconds, and then finally 1 second.

sddm always starts up once a delay is in place. However, when it's less than 2 seconds, it may take a few spawns for it to work. It does always work in the end, but the "good luck" message is behind it and shows up when you power down or reboot.
Yann Ciret 2016-11-23 23:30:46 CET

CC: (none) => mageia

Comment 2 Mike Rambo 2016-11-28 20:46:24 CET
I can confirm comment #2. Tested in a virtualbox VM and on four hardware variations. One with integrated Intel video and then the same box with Radeon and nVidia add in cards (with the latter using both free and proprietary drivers). I did the change directly in the /usr/lib/systemd/system/prefdm service file but the net effect was the same. Still see good luck for a few seconds (except on nvidia proprietary which always works well for some reason) but then starts the gui eventually. Not sure normal users or reviewers will be very impressed though.

FWIW, I tested comment #1 too. I fully disabled prefdm to the point of moving the files (/etc/X11/prefdm and /usr/lib/systemd/system/prefdm.service) out of their normal locations, enabled sddm.service via systemctl, and changed the symlinks of dm.service and display-manager.service to sddm.service instead of prefdm.service. This works very smoothly for plasma.

I think Neal is correct that the fast successive restarts is a large part of the problem for prefdm (and thereby for sddm) but the restart delay alone, while it does eventually get to a gui, is not a very pretty solution. Good luck still shows in some cases for a couple of seconds before the gui starts on my tests for both VM and hardware except nvidia proprietary.

CC: (none) => mrambo

Comment 3 Samuel Verschelde 2016-12-01 22:26:07 CET
Fixed now, isn't it?

Status comment: (none) => Should be fixed since the 30th of November, via systemd-units update
QA Contact: (none) => stormi

Comment 4 Neal Gompa 2016-12-02 01:30:03 CET
Yep, my fix to prefdm.service fixed this.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

Comment 5 Neal Gompa 2016-12-02 01:30:46 CET
Ah, just to note, my fix wasn't the restartsec fix, but instead to remove "plymouth-quit.service" from the Conflicts in prefdm.service.

Note You need to log in before you can comment on or make changes to this bug.