Can’t Configure GDM After Update To CentOS 7.6

Home » CentOS » Can’t Configure GDM After Update To CentOS 7.6
CentOS 8 Comments

Hi,

It looks like the upgrade to CentOS 7.6 has been unusually disruptive with the GNOME desktop version bump and a series of moving targets under the hood. The result is some wreckage at my client’s desktop installations, which I’ve been busy to repair since yesterday. First things first.

I have a custom configuration of GDM, which consists mainly of two things.

1. Display my company’s logo instead of the CentOS logo.

2. Disable the user list (since I have about 100 users here).

Until CentOS 7.5, here’s what I did.

1. Create a file /etc/dconf/profile/gdm :

user-db:user
system-db:gdm
file-db:/usr/share/gdm/greeter-dconf-defaults

2. Create a file /etc/dconf/db/gdm.d/01-logo :

[org/gnome/login-screen]
logo=’/usr/share/pixmaps/microlinux-logo.png’

3. Create a file /etc/dconf/db/gdm.d/00-login-screen :

[org/gnome/login-screen]
disable-user-list=true

4. Update dconf :

# dconf update

Now with CentOS 7.6 this doesn’t work anymore. The /etc/dconf/db/gdm.d directory is nowhere to be found, and I’m currently mildly cursing the GNOME developers’ (and Red Hat’s) policy of releasing moving targets. Until now, the whole purpose of Enterprise Linux seemed to be low-risk updates.

I’ve documented the whole GDM customization process until CentOS 7.5 in a short article on my french blog :

* https://blog.microlinux.fr/gdm-CentOS/

Any idea how I can configure GDM with the new version ?

Cheers,

Niki

—
Microlinux – Solutions informatiques durables
7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32

8 thoughts on - Can’t Configure GDM After Update To CentOS 7.6

  • While the /etc/dconf/db/gdm.d/ directory doesn’t exist, I’ve got many RHEL7.6 and CentOS 7.6 systems where GDM behaves the same way as before, as long as you create /etc/dconf/db/gdm.d/ and put the files in there, and as soon as you run ‘dconf update’, you see it change.

    I’m not sure why the /etc/dconf/db/gdm.d/ and
    /etc/dconf/db/gdm.d/locks/ directory aren’t owned by a package anymore, that seems like a bug, but as far as I can tell, GDM
    continues to get its information from there.

  • Jonathan Billings wrote:

    I suspect it might be something that has been left out in the rebase to GDM 3.28.1 – an earlier change log for GDM has:

    * Thu Jun 25 2015 Ray Strode 3.14.2-4
    – Make sure user customizations to gdm via /etc/dconf/db/gdm.d
    continue to work following rebase.
    Related: #1174564

    So, I’m guessing that something similar was left out with this change from 3.26 to 3.28 ?

    Maybe a bug report to https://bugzilla.redhat.com is needed ?

    James Pearson

  • Le 06/12/2018 à 15:24, James Pearson a écrit :

    On a side note, I’ve now spent a day and a half trying to recover my wrecked desktop profiles, with only a partial success. As it looks now, I’ll probably move all my desktop installations to openSUSE Leap 15 and KDE 5 in the near future.

    As far as I can tell, rebasing GNOME in the middle of a minor update was not a good idea.

    Cheers,

    Niki

    —
    Microlinux – Solutions informatiques durables
    7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32

  • They did a similar thing with NetworkManager few releases ago that caused all my servers to start grabbing randomized IPv6 addresses instead of static they previously grabbed.

    I don’t understand why Red Hat makes these kind of changes in point releases – yet they won’t update OpenSSL or PHP or Postfix in a point release.

    It’s like they use /dev/random to determibe where they require API
    stability between point releases.

    —
    For signature trust anchor (paranoid only need worry ’bout this):
    https://ca.pipfrosch.com/pipfrosch-cacert-pem.crt

    Webmail clients, sorry, out of luck, you can’t import it. Get an actual e-mail app.

  • Rebasing Gnome3 regularly I think has been one of Red Hat’s best decisions, and one I can easily imagine a committee deciding against for reasons of wanting to minimise risk.

    Do you remember just how bad Gnome3 was in RHEL 7.0? It was unstable and insecure, certainly when used with nvidia drivers. I can’t see how you could justify the effort it would have required to effectively support an unsupported version of Gnome3, and backporting I think would have been more than deeply unpleasant.

    They made a mistake in omitting a patch that wasn’t caught in qa, and that’s a shame. But then let’s be honest, how many Red Hat customers actually use this feature? I do use it, and I didn’t pick it up in my own testing, as our deployment must have created the directories as we had no issues.

    jh

  • Le 06/12/2018 à 18:54, John Hodrien a écrit :

    Or they could simply have gone with KDE 4, a stable and mature desktop at the time RHEL 7.0 was out. And not an abomination that had to be potty-trained from scratch again while steadily losing features every other minor upgrade.

    Niki

    —
    Microlinux – Solutions informatiques durables
    7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32

  • Well that is one person’s opinion on the KDE/GNOME debate .. mine would be slightly different (OK , completely opposite :)

    To each his own :)

  • Johnny Hughes wrote:

    I’m in the gnome is crap camp. Bloatware (which is what kde used to be…), and it looks like it’s trying, real hard, to make users think of Windows 10 (which, having had to deal with, I LOATHE!!!!!)

    Kde looks like *Nix. I like things wo work the way I want, and no, the way they want to do it isn’t how I want it… which, of course, is the *Nix Way.

    mark