Bug 850775

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."

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.

*** Bug 850465 has been marked as a duplicate of this bug. ***

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?

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.

Bill: how are DVD installs to be handled? Your comment appears to cover only live spins.

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.

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.

I was mistaken about anaconda previously writing /etc/sysconfig/desktop. This was only done by request via kickstart.

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?

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.

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.

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...

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.

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.

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/
? :)

(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

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

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.)

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.

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.

I installed Fedora 18 Alpha TC4 netinst (all defaults) with KDE, KDM was enabled and started.

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.

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)?

Tim, seems the answer to your last question is "yes", for now.

Rex: OK, just making sure before we start pulling in and verifying all the presets fixes for alpha.

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.

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.

https://fedoraproject.org/wiki/Features/DisplayManagerRework

outlines how to change DM's manually.

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?

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.

(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?

> 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.

>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.

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.

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)?

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

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.

Filed https://bugzilla.redhat.com/show_bug.cgi?id=855470 for LXDM.

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.

(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.

(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.

(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.

> 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.

(… 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.)

(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.

(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.