Bug 850775 - display managers aren't enabled after installation
Summary: display managers aren't enabled after installation
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
: 850465 (view as bug list)
Depends On: kdm.preset lightdm.preset lxdm.preset
Blocks: F18Alpha, F18AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2012-08-22 12:04 UTC by Jan Sedlák
Modified: 2012-09-14 14:08 UTC (History)
22 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-12 00:56:48 UTC
Type: Bug


Attachments (Terms of Use)

Description Jan Sedlák 2012-08-22 12:04:32 UTC
Description of problem:
After installation of one of the GUIs (KDE, XFCE, LXDE), graphical.target is set as default target, but no display manager is set as default, so after boot it shows console login.

kdm.service in KDE installation, lxdm.service in LXDE installation and lighdm.service in XFCE installation are all disabled by default.

How reproducible:
always

Steps to Reproduce:
1. Install F18 TC3, choose some desktop (KDE, LXDE, XFCE, Gnome can't be installed)
2. Reboot
  
Actual results:
it boots into console

Expected results:
it should boot into display manager

Additional info:
I don't know who is responsible for setting default display manager, so I have reported it into DM itself, bug 850766.

Comment 1 Jan Sedlák 2012-08-22 12:13:47 UTC
Proposing as an Alpha blocker, violates criterion: "Following on from the previous criterion, after firstboot is completed and on subsequent boots, a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to a working graphical environment without unintended user intervention."

Comment 2 Chris Lumens 2012-08-22 15:08:25 UTC
I see that each display manager's spec file has a %post that sets it up to be the default DM.  Isn't this supposed to do everything for us?  I don't see how anaconda needs to be involved here.

Comment 3 Adam Williamson 2012-08-22 17:06:54 UTC
*** Bug 850465 has been marked as a duplicate of this bug. ***

Comment 4 Adam Williamson 2012-08-22 17:10:47 UTC
Discussed at 2012-08-22 blocker review meeting. Accepted as a blocker per criterion "After firstboot is completed and on subsequent boots, a system installed according to any of the above criteria must boot to a working graphical environment without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied".

It seems clear from discussion in the meeting, in this bug and in #850465 that no-one, with the possible exception of Lennart, is really sure how the hell this is supposed to work, and what's actually going to be possible and what isn't. We can't 'fix' this by doing stuff in the live spin kickstarts because that won't handle DVD installs. However this is handled needs to work for DVD installs of any desktop as well as for live installs.

Lennart, how are you expecting this to be handled? Is the claim in https://bugzilla.redhat.com/show_bug.cgi?id=850465#c3 - "Halfline pointed out too that the old default ordering still takes place, so if only kdm is installed, it will get used." - accurate? If so, is that mechanism broken? It appears to be, based on our Alpha TC3 testing experience. Just what the heck are desktops supposed to be doing to make this work?

Comment 5 Bill Nottingham 2012-08-22 19:17:29 UTC
1) Each spin should ship a preset file that determines which one it is supposed to use

- Since this is read as part of the transaction, I *think* this needs done in %pre of the kickstart.


2) The script in systemd's %post should run on upgrade (and initial install, for that matter) to change it based on /etc/sysconfig/desktop

- This won't work on live image creation, etc. b/c it runs in the transaction, and any /etc/sysconfig/desktop would be written later. But it shouldn't be needed because of #1 above.

Comment 6 Adam Williamson 2012-08-23 00:01:42 UTC
Bill: how are DVD installs to be handled? Your comment appears to cover only live spins.

Comment 7 David Lehman 2012-08-23 00:21:50 UTC
Anaconda used to write /etc/sysconfig/desktop (AFAICT) for non-live installs, but I apparently didn't implement that in the new packaging backend. I'll have an updates image someone can test tomorrow.

Comment 8 Lennart Poettering 2012-08-23 12:19:12 UTC
The various spins should ship a preset file like the following (a good name would be /usr/lib/systemd/system-preset/80-fedora-kde-spin.preset or so):

enable kdm.service
disable gdm.service

This will have the effect that kdm is enabled on package installation and gdm is left off. Normally /usr/lib/systemd/system-preset/99-default.preset will enable gdm, but since 80-fedora-kde-spin.preset is before 99-default.preset lexicographically and the first matching item wins the spin default will override the Fedora default if used this way.

We probably should duplicate this bug report with these directions against the various spins. However, I am not sure that there is even a bugzilla component for them?

The systemd %post scriptlets should already convert /etc/sysconfig/default as needed on upgrades, so I guess in systemd itself there's nothing we need to convert really.

Comment 9 David Lehman 2012-08-23 13:22:32 UTC
I was mistaken about anaconda previously writing /etc/sysconfig/desktop. This was only done by request via kickstart.

Comment 10 Rex Dieter 2012-08-24 15:53:47 UTC
Seems Adam's comment #6 remains unanswered.  

I'm guessing one solution would be to ship the preset along with the DM packaging, but then we have possible scenario of having  multiple DM's with something  like
/usr/lib/systemd/system-preset/80-fedora-kdm.preset
enable kdm.service
disable gdm.service

/usr/lib/systemd/system-preset/85-fedora-lightdm.preset
enable lightdm.service
disable gdm.service

how would systemd handle this case?  enable both kdm.service and lightdm.service?

Comment 11 Bill Nottingham 2012-08-24 15:59:48 UTC
Lower number wins, so if we did that, I'd suspect gdm at 80, kdm at 81, lightdm at 82, xdm as 1 billion, etc.

Comment 12 Rex Dieter 2012-08-24 16:11:23 UTC
thanks, I think I understand now, only the lowest # (single) preset wins.  ok, will definitely want to name these
##-fedora-<spin_or_DE>.preset
then.

So, I'm ok with your idea of assigning:
80(gnome), 81(kde), 82(xfce), 83(lxde), 84(...), ... 
unless someone has a better suggestion.

Comment 13 Jóhann B. Guðmundsson 2012-08-24 18:02:24 UTC
Is it not just possible to create package conflicts between each DM's and each *DM installs just it's own preset file with simple "enable *dm.service" entry
Leaving Anaconda totally out of this since the relevant DM would just be setup based which DE the user choose to install? 

Seriously we should official not endures users to install multiple *DE. If users want more then one *DE they can install and set it up after the initial install and at the same time do the necessary tweak to get whatever DM they want to use at that time...

Comment 14 Paolo Bonzini 2012-08-28 08:58:24 UTC
Does it need to be:

/usr/lib/systemd/system-preset/80-fedora-gdm.preset
enable gdm.service
disable kdm.service
disable lightdm.service

/usr/lib/systemd/system-preset/81-fedora-kdm.preset
enable kdm.service
disable lightdm.service

/usr/lib/systemd/system-preset/82-fedora-lightdm.preset
enable lightdm.service


etc?  This does not really scale.

Comment 15 Adam Williamson 2012-08-29 17:55:40 UTC
johann: if we put in package conflicts between *dm packages, you'd *never* be able to install multiple dm's, even post-install with yum.

Discussed at 2012-08-29 blocker review meeting. We're still not confident we really grok this, but as things stand, we *think* each *dm package needs to ship a preset file that enables itself. That should at least handle initial installation, where you usually will only get a single *dm installed. We honestly have no clue what will happen with this system if you install multiple dms manually after system installation. We do think the preset file needs to be in the *dm packages, not just on live spins, because otherwise DVD install isn't going to work.

Comment 16 Rex Dieter 2012-08-29 18:16:08 UTC
side note now that I'm looking at implementing this, is it worth creating some rpm macro for
/usr/lib/systemd/system-preset

similar to how we currently have in /etc/rpm/macros.systemd
%_unitdir /usr/lib/systemd/system

??

or be evil and use
%{_unitdir}-preset/
? :)

Comment 17 Jóhann B. Guðmundsson 2012-08-29 18:23:23 UTC
(In reply to comment #15)
> johann: if we put in package conflicts between *dm packages, you'd *never*
> be able to install multiple dm's, even post-install with yum.

Forcing the user to jump through hoops and hack things back and fourth if he wants to install multiple DM's yes I was aware of that I honestly dont see why a) we should ( continue to ) support doing this or b) make it easy if we do since probably 99% of our user base will never do this and those that are developing for one or more DE probably do so in today's age in isolated vm instances.

> Discussed at 2012-08-29 blocker review meeting. We're still not confident we
> really grok this, but as things stand, we *think* each *dm package needs to
> ship a preset file that enables itself. That should at least handle initial
> installation, where you usually will only get a single *dm installed. We
> honestly have no clue what will happen with this system if you install
> multiple dms manually after system installation. We do think the preset file
> needs to be in the *dm packages, not just on live spins, because otherwise
> DVD install isn't going to work.

Unless Anaconda generates the preset file based on the DE selected

Comment 18 Fedora Update System 2012-08-29 18:28:38 UTC
kde-settings-4.9-8.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/kde-settings-4.9-8.fc18

Comment 19 Kevin Kofler 2012-08-29 18:38:58 UTC
IMHO, the bug there is that a preset is needed in the first place when there's only one DM, and that's a systemd issue. (It should be using the one installed DM.)

Comment 20 Adam Williamson 2012-08-31 05:58:29 UTC
kevin: it seems the 'default' preset will only work to enable *gdm* in that case, not any DM. I don't know if that can be fixed.

Comment 21 Kevin Kofler 2012-08-31 10:13:20 UTC
Can't the distrowide default preset just require the virtual displaymanager.service rather than a specific DM? Or will that cause chaos when there's more than one installed?

If that is not possible, I guess we need to go with the solution from comment #14, but I'm also worried that this is bound to get out of sync, because every display manager would need to know about all others.

And in addition to all that, spins may want to drop their own preset to /etc so that installing the highest-priority DM after the fact won't make that the default, though that's less critical. (We used to do that with /etc/sysconfig/desktop on the KDE spin.)

I'm starting to think that we should really go back to prefdm! That solution just worked.

Comment 22 Martin Krizek 2012-08-31 11:07:11 UTC
I installed Fedora 18 Alpha TC4 netinst (all defaults) with KDE, KDM was enabled and started.

Comment 23 Tim Flink 2012-08-31 16:13:50 UTC
I installed F18 alpha TC4 netinstall (defaults) with Gnome. GDM was enabled after install and other than the background looking a little funny, it does work.

Comment 24 Tim Flink 2012-08-31 16:30:09 UTC
Was there any conclusion on the best way to solve this, at least for now? Are we going the preset route and accepting the fact that some DMs will be taking priority over others (ie if kdm, gdm and lightdm are installed, kdm will take priority)?

Comment 25 Rex Dieter 2012-08-31 16:42:02 UTC
Tim, seems the answer to your last question is "yes", for now.

Comment 26 Tim Flink 2012-08-31 17:06:10 UTC
Rex: OK, just making sure before we start pulling in and verifying all the presets fixes for alpha.

Comment 27 Kevin Kofler 2012-08-31 17:21:00 UTC
If more than one DM is installed, one of them will necessarily have to take priority over the others, that's not the issue. The issue is the way the highest-priority DM is determined. If each DM ships its own preset:
* Who determines which DM has higher priority? (E.g., KDM now has higher priority than GDM, which wasn't the case in the past. GDM could ship a preset with higher priority than KDM to "fix" this, but who decides whether it should? And what about, say, KDM vs. LightDM? Which should have higher priority?)
* From comment #14, it sounds like the higher-priority DMs explicitly need to disable the lower-priority ones to prevent conflicts. So how do we ensure this happens? If a new DM springs up (like LightDM recently did), do we have to update all the DMs to disable it in their presets?

If there isn't a way to handle this in the distrowide default preset, the systemd preset language needs to be extended. We need something like:
if GDM installed
  enable GDM
  haveDM = yes
fi
if KDM installed
  if haveDM
    disable KDM
  else
    enable KDM
    haveDM = yes
  fi
fi
if LightDM installed
  if haveDM
    disable LightDM
  else
    enable LightDM
    haveDM = yes
  fi
fi
(basically replicating the prefdm logic), where of course the priority order is a distro policy decision (the one above is just an example). If presets cannot do this, they cannot replace prefdm.

Comment 28 Daniel Belton 2012-08-31 19:51:01 UTC
Just to add a fly in the ointment, so to speak...

I currently have 3 DM's installed, and switch between them by modifying the /etc/sysconfig/desktop file (in F17).

I do this because I am trying to give Gnome 3 and GDM a fighting chance to become a usable DE/DM for me here, but it's not to the point yet where I can use it all of the time.

Currently, with the state of GDM and Gnome 3, I need a way to easily switch. If I can't switch, then as things are currently, I will have to drop Gnome 3/GDM completely and use what works the best for me.

I would really hate to have to completey drop Gnome since I have been using it since the end of 1998, but I have to have a usable system.

Comment 29 Rex Dieter 2012-08-31 20:32:39 UTC
https://fedoraproject.org/wiki/Features/DisplayManagerRework

outlines how to change DM's manually.

Comment 30 Adam Williamson 2012-08-31 22:21:10 UTC
I'm feeling somewhat Kevin-y, to be honest - what exactly is it that presets gets us that's better than prefdm was, to be worth all this pain and confusion?

Comment 31 Daniel Belton 2012-09-01 04:18:40 UTC
So, if I have KDM install and prefer to use it, but then install LightDM, will it make itself the default automatically? 

What if I don't want it to make itself the default? What if I am installing it just to test it, but don't want to replace my default DM with it? 

I see how things are going to progress here. People are going to delete all of the preset files except for the /usr/lib/systemd/system-preset/99-default.preset and just edit that file to start the DM they wish.

Comment 32 Jóhann B. Guðmundsson 2012-09-01 05:53:25 UTC
(In reply to comment #30)
> I'm feeling somewhat Kevin-y, to be honest - what exactly is it that presets
> gets us that's better than prefdm was, to be worth all this pain and
> confusion?

There is no confusion if you want to have multiple dm install you will need to modified and or create the necessary preset file your self. 

If the developers of DM's wanted their users base being able to launch different DE's they would implement that feature into their DM. 

Again why are we supporting having several DM's installed?

What is the actual use case for it now when almost every computer on the planet has cpu with vm capability?

Comment 33 Kevin Kofler 2012-09-01 18:41:42 UTC
> So, if I have KDM install and prefer to use it, but then install LightDM, will
> it make itself the default automatically? 
>
> What if I don't want it to make itself the default? What if I am installing it
> just to test it, but don't want to replace my default DM with it?

Well, either KDM or LightDM will have the higher priority. I don't see how else we would resolve the conflict. It has always been like that.

> I see how things are going to progress here. People are going to delete all of
> the preset files except for the
> /usr/lib/systemd/system-preset/99-default.preset and just edit that file to
> start the DM they wish.

… and that would be the wrong thing to do. NEVER hand-edit or delete a non-config file (and files in /usr are not config files) owned by a package, your changes will be overwritten by the next package update!

You can drop a file into /etc instead, read the documentation of the "systemd presets" feature.

> Again why are we supporting having several DM's installed?

Because DMs can be dragged in as dependencies by basically everything. E.g. gnome-shell requires gdm-libs which requires gdm.

Comment 34 Jóhann B. Guðmundsson 2012-09-01 19:12:15 UTC
>Because DMs can be dragged in as dependencies by basically everything. E.g. >gnome-shell requires gdm-libs which requires gdm.

Ugh what a mess then the only option is to have a single preset file locate in /etc/systemd directory to stay a way from packaging updates for all DM which users use to configure which one of the DM's is the default or some other hackish workaround like that...

Basically all packages install the same dm preset file ( and overwrite it if it exist ) which sets them as the default dm and if users want to overwrite it they create that file in /etc/systemd preset directory which specifies which DM should be used.

Comment 35 Daniel Belton 2012-09-01 19:32:29 UTC
I don't know all of the specifics, but that suggestion (in comment #34)sounds to me to be one of the best ones yet.

It allows the DM to specify itself as the default DM upon install, yet still gives the users an easy way to over-ride and change the default. 

I just wonder if all of this mess is any simpler than the existing prefdm, though. a simple 2 line edit and it can support any DM you wish for it to. I have changed mine several times to add in a DM that Fedora didn't have in there.

Comment 36 Rex Dieter 2012-09-04 15:24:51 UTC
OK, so ran into a  problem with kdm not starting in kde spin, bug #853985 , and seems we need to add
After=livesys-late.service
to make this work.  then I went and compared to f17's prefdm.service which  contains:
After=livesys-late.service rc-local.service systemd-user-sessions.service

ought we add all of those too? (seems so,  any reason not to)?

Comment 37 Rex Dieter 2012-09-04 16:08:33 UTC
looks like the template on
https://fedoraproject.org/wiki/Features/DisplayManagerRework
already includes systemd-user-sessions.service, so I'm pretty sure we also need livesys-late.service, but wondering about rc-local.service too.


Now, as to those folks wondering how to manually set DM, and didn't notice
https://fedoraproject.org/wiki/Features/DisplayManagerRework#How_To_Test
the one-line trick is:
systemctl enable --force xyzdm.service

Comment 38 Adam Williamson 2012-09-04 20:31:05 UTC
rc-local.service just runs /etc/rc.local, which could contain anything - it's for the system admin to add little one-liners that should happen on boot, without going to the trouble of creating a discrete service for each.

it probably makes sense to have After: rc-local.service so that anything the sysadmin wants to do on boot which might need to happen before login gets done. but not doing it shouldn't break anything out of the box.

Comment 39 Adam Williamson 2012-09-07 22:27:54 UTC
Filed https://bugzilla.redhat.com/show_bug.cgi?id=855470 for LXDM.

Comment 40 Adam Williamson 2012-09-12 00:56:48 UTC
So in RC2, we've confirmed that KDM and GDM work. They are the release-blocking desktops' DMs. The updates are stable - https://admin.fedoraproject.org/updates/FEDORA-2012-13304/kde-settings-4.9-9.fc18 (gdm was covered a long time ago). This bug can be closed, since it's a release blocker.

I think we actually have all the DMs covered now, but for any that aren't, please open separate, non-blocker bugs. Thanks.

Comment 41 Lennart Poettering 2012-09-13 19:44:51 UTC
(In reply to comment #37)
> looks like the template on
> https://fedoraproject.org/wiki/Features/DisplayManagerRework
> already includes systemd-user-sessions.service, so I'm pretty sure we also
> need livesys-late.service, but wondering about rc-local.service too.

Please do not order your DM in relation to livesys-late.service. Instead livesys-late.service should order itself relative to display-manager.service. Your DM doesn't need to know anything about live CDs. I actually file a bug about this against livesys.

THere's actually a bug about this:

https://bugzilla.redhat.com/show_bug.cgi?id=846384

And this is also documented in the feature page.

Comment 42 Lennart Poettering 2012-09-13 19:46:05 UTC
(In reply to comment #14)
> Does it need to be:
> 
> /usr/lib/systemd/system-preset/80-fedora-gdm.preset
> enable gdm.service
> disable kdm.service
> disable lightdm.service
> 
> /usr/lib/systemd/system-preset/81-fedora-kdm.preset
> enable kdm.service
> disable lightdm.service
> 
> /usr/lib/systemd/system-preset/82-fedora-lightdm.preset
> enable lightdm.service
> 
> 
> etc?  This does not really scale.

Nope. The spins should just disable the fedora default (which is gdm.service) and that's it. They shouldn't bother with the other dms.

Comment 43 Lennart Poettering 2012-09-13 20:19:57 UTC
(In reply to comment #16)
> side note now that I'm looking at implementing this, is it worth creating
> some rpm macro for
> /usr/lib/systemd/system-preset
> 
> similar to how we currently have in /etc/rpm/macros.systemd
> %_unitdir /usr/lib/systemd/system


I added %_presetdir for you now, should be in my next F18 upload.

Comment 44 Kevin Kofler 2012-09-13 21:57:00 UTC
> Nope. The spins should just disable the fedora default (which is gdm.service)
> and that's it. They shouldn't bother with the other dms.

No. Doing this in the spins doesn't solve the problem at all.

The priority and fallbacks need to be handled in the display manager packages. If a user installs KDM and not GDM from the DVD or netinstall, or even just by:
yum install kdm
yum remove gdm
this needs to work. Setting up KDM only from the KDE spin kickstart does not fulfill this requirement at all.

Comment 45 Kevin Kofler 2012-09-13 21:58:39 UTC
(… and prefdm actually solved this exact problem, it's exactly what it was designed for. It doesn't make sense to replace prefdm by a mechanism which cannot solve the same problem.)

Comment 46 Jens Petersen 2012-09-14 01:54:57 UTC
(In reply to comment #40)
> I think we actually have all the DMs covered now, but for any that aren't,
> please open separate, non-blocker bugs. Thanks.

Thanks

Lightdm seems still not coming up - guess it needs another tweak:
I filed bug 857277 for that.

Comment 47 Jens Petersen 2012-09-14 04:00:36 UTC
(In reply to comment #41)
> Please do not order your DM in relation to livesys-late.service. Instead
> livesys-late.service should order itself relative to
> display-manager.service. Your DM doesn't need to know anything about live
> CDs. I actually file a bug about this against livesys.

I think this bug is solved for Live, but seems not "yum install *dm"...?

At least for me installing any DM and rebooting is not giving me a DM.
Should it not be so?

I tried lightdm(-gtk), lxdm, gdm, and kdm and after yum installing them
no DM starts up at boot time.


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