Bug 19834

Summary:	prefdm breaks sddm in KVM
Product:	Mageia	Reporter:	Neal Gompa <ngompa13>
Component:	RPM Packages	Assignee:	Base system maintainers <basesystem>
Status:	RESOLVED FIXED	QA Contact:	Samuel Verschelde <stormi-mageia>
Severity:	critical
Priority:	release_blocker	CC:	mageia, mageia, mageia, mhrambo3501
Version:	Cauldron
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:	systemd-230-5.mga6.src.rpm	CVE:
Status comment:	Should be fixed since the 30th of November, via systemd-units update
Bug Depends on:
Bug Blocks:	19782

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.