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
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.
sorry, didn't see the original message go by until now.
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.