Bug 19871 - Eliminate prefdm and use display manager service units directly
Summary: Eliminate prefdm and use display manager service units directly
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: High normal
Target Milestone: Mageia 7
Assignee: Base system maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-30 15:24 CET by Neal Gompa
Modified: 2020-09-23 00:43 CEST (History)
5 users (show)

See Also:
Source RPM: systemd, initscripts, drakxtools
CVE:
Status comment:


Attachments

Description Neal Gompa 2016-11-30 15:24:29 CET
Description of problem:
prefdm is old, creaky, and causing us problems. No other distribution relies on it anymore, and systemd itself has a clean process for handling display managers, so let's move to that.

For maximum compatibility, we would shift dm.service symlink to point to /etc/systemd/system/display-manager.service, which itself would point to the proper display manager. /usr/lib/systemd/system/display-manager.service should not exist anymore. prefdm.service would not exist anymore. We could ship an override to display-manager.service that always adds the on failure message that we see now with the current prefdm.service if we want.

We would ship in wherever we ship systemd presets something like what Fedora has[1], which triggers the automatic enablement of a display manager once installed, but won't allow for display managers to be overwritten. Since you only want one to be enabled at a time, this works fine.

The initscripts patches that remove prefdm would be applied instead of not used, and drakdm needs to be tweaked to handle the display-manager.service symlink instead of changing the prefdm configuration.


[1]: https://pagure.io/fedora-release/blob/master/f/85-display-manager.preset
Neal Gompa 2016-11-30 15:24:38 CET

Target Milestone: --- => Mageia 7

Neal Gompa 2016-11-30 15:25:03 CET

CC: (none) => mageiatools

Samuel Verschelde 2016-11-30 15:27:41 CET

Priority: Normal => High

isadora 2016-11-30 18:22:09 CET

CC: (none) => isis2000

Florian Hubold 2017-08-08 22:10:41 CEST

CC: (none) => doktor5000

Comment 6 Ben McMonagle 2018-03-26 01:30:56 CEST
I have successfully installed via net-install cauldron both i586 and x86_64 (so not an MGA6 upgrade).

unfortunately display manager does not auto-start.

I can "get" to LXDE desktop using "startx startlxde" from a tty2, for example.

This is not a complaint, just a report.
 

I have also performed Mga6 upgrades to cauldron, and am able to login to desktops via dm greeter without issue (presumably as prefdm.service is still in use)

CC: (none) => westel

Comment 7 Bit Twister 2018-03-26 03:44:21 CEST
(In reply to ben mcmonagle from comment #6)
> I have successfully installed via net-install cauldron both i586 and x86_64
> (so not an MGA6 upgrade).
> 
> unfortunately display manager does not auto-start.

See bug 22620

The problem is getty@tty1.service and gui runlevel not enabled during install.
Boot runlevel 3,
Hit Ctrl+F2
login as root.
systemctl enable getty@tty1.service
systemctl set-default graphical.target
Next boot should work.

CC: (none) => bittwister2

Comment 8 Bit Twister 2018-03-26 04:09:50 CEST
bug 22593 has the workaround for runlevel 5/gui login.
Comment 9 Ben McMonagle 2018-03-26 20:48:30 CEST
(In reply to Bit Twister from comment #8)
> bug 22593 has the workaround for runlevel 5/gui login.

that works,

Thanks
Comment 10 Aurelien Oudelet 2020-09-19 18:09:18 CEST
Hi,
This is High priority bug for a good reason.

Making Mageia even better than ever is best direction.
In order to do right thing, this bug should be examined and fixed as soon as possible.

Packagers, please make the status to Assigned when you are working on this.
Feel free to reassign the bug if bad-triaged. Also, if bug is old, please close it.

On October 1st 2020, we will drop priority to normal.
Comment 11 David Walser 2020-09-23 00:43:44 CEST
Mageia 7 is using dm units instead of prefdm.

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


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