Bug 842844 - gdm refuses to start after F15->F17 upgrade
gdm refuses to start after F15->F17 upgrade
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
17
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-24 13:46 EDT by Michal Jaegermann
Modified: 2012-08-02 13:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-07-30 20:45:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2012-07-24 13:46:10 EDT
Description of problem:

After upgrade of a working installation of Fedora 15 to Fedora 17 gdm attempts to start six times blinking a screen and gives up.  Log files in /var/log/gdm all look in principle the same. In :N-greeter.log one finds something like this:

gnome-session[1384]: ERROR: Unable to open '/etc/dconf/db/gdm', specified in dconf profile

aborting...

In :N-slave.log

gdm-welcome][1380]: pam_unix(gdm-welcome:session): session opened for user gdm by (uid=0)
gdm-welcome][1380]: pam_unix(gdm-welcome:session): session closed for user gdm
gdm-simple-slave[1359]: WARNING: Child process 1384 was already dead.

and :N.log shows that X server starts and is immediately shut down by gdm
with a log file terminated by:

Server terminated successfully (0). Closing log file.

Mysterious "/etc/dconf/db/gdm" indeed does not exist although gdm supplies
/etc/dconf/db/gdm.d directory. Probably /etc/dconf/profile/gdm is that "dconf profile" which is causing ERROR above and it contains:

user
gdm

lines - whatever that may mean.

Forcing selinux relabelling does not change anything.  It is possible to start X server by itself with 'startx' and after a looong struggle this brings up some kind of a very slow desktop for root.  Now what???

Version-Release number of selected component (if applicable):
gdm-3.4.1-3.fc17.x86_64
Comment 1 Michal Jaegermann 2012-07-30 20:45:15 EDT
Here what was the problem.  Anaconda bailed out on me in the middle of an upgrade because of an error in a "preun" scriptlet in an emacs package just about to be replaced.  That left me with a massive cleanup job on a system which was already too far gone from the original but not enough to work somehow as an upgrade (in particular 'package-cleanup --cleandupes' was failing due to broken/breaking dependencies and required a gueswork and a "manual help").  As a result after a recovery "posttrans" were NOT run and in particular 'dconf update' from gdm package scripts was skipped.  That one happens to create that missing
/etc/dconf/db/gdm binary file.

Still it would be nice in a response to my original bug report to get a hint that possibly 'dconf update' was not executed instead of leaving me to my own devices.

Regardless - in my opinion this is buggy and getting buggier as this whole heap becomes more and more complicated and fragile.  A misguided push to binary configuration files with mysterious functionality just repeats very old errors.
Comment 2 Ray Strode [halfline] 2012-08-02 13:34:09 EDT
sorry, didn't see the original message go by until now.
Comment 3 Ray Strode [halfline] 2012-08-02 13:40:17 EDT
FWIW, the author of dconf doesn't like that we're using dconf for lockdown either.  He'd rather each component in a GDM session notice it's running in a locked down session and do the appropriate lock down on its own.

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