Red Hat Bugzilla – Bug 66750
Always use gdm
Last modified: 2014-03-16 22:28:11 EDT
Should always use gdm instead of kdm, unless only kdm is installed.
I don't think this is the correct way to go. This should be configurable
by the sysadmin with an entry in /etc/sysconfig.
It's fine if it's configurable, but gdm should always be the default.
Fix you dm launcher to run gdm by default unless an alternate is defined in
whatever you look at in /etc/sysconfig.
And back to initscripts where it was in the first place. ;-) gdm doesn't launch
why don't people like the anaconda patch I produced? It will have the desired
result, and works fine with the infrastructure already in place in prefdm for
I think the comment was just that the policy should just stay in prefdm.
Created attachment 70404 [details]
use GDM by default, unless specified by DISPLAYMANAGER (ignore $DESKTOP)
will be in 6.89-1
See #72468 -- this currently breaks badly when upgrading systems which:
1. are running 7.3 or less
2. have both KDE and GNOME installed
3. have configured DESKTOP="KDE" in /etc/sysconfig/desktop
On upgrades, /etc/sysconfig/desktop needs to be parsed and the DESKTOP line
duplicated as DISPLAYMANAGER
Sorry, wrong number -- the bug I meant was Bug 72486
I'm not sure I'd call it 'breaking badly' - you get gdm and have to change
DISPLAYMANAGER. It's mildly annoying, but nothing is broken.
*shrug* If I've bothered to configure a 7.3 system to use specific software,
and the upgrade silently changes that w/ no documentation, that's "breaking
Imagine if null silently switched all 7.3 machines where the admin had used
alternatives to select postfix back to sendmail, w/ no mention anywhere in any
documentation of this behavior. That's exactly what you're doing here, only
with the display manager instead of the MTA....
In this case (of the login display manager), we respectfully disagree.
I humbly request that the minor modifications to /etc/sysconfig/desktop be made
in order to reduce possible future confusion on this issue.
I definitely second Warren's request. While I disagree with Preston about this
not being a bug (to me, as a customer, any configuration which I deliberately
make and then RH upgrades remove is a bug), at least if it's documented people
will know how to fix the damage done by the upgrade.
Closing this out, as things appear to be working correctly now.