Created attachment 429063 [details] Installed packages Description of problem: - use F-13 - boot - login to existing user account - manually connect ethernet by clicking on network manager icon (I have auto-connect disabled, because I use static IP addresses and switch between locations) - try to start Firefox or Thunderbird (any profile) and get error message: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details - 1: Server ping error: IDL:omg.org/CORBA/COMM_FAILURE:1.0) - in addition, tried to connect to VPN, config entries still shown in NetworkManager-Applet, but attempt to connect results in error messages. running the config UI even shows no entries in the VPN tab. - effectively gconf is disabled/broken - gconftool-2 -R /desktop/gnome reports the same failure as above Version-Release number of selected component (if applicable): Use a Fedora system that has updates until June 24 then update to all updates visible until July 02. I'll attach a list of all packages that got installed today. Additional info: I was able to work around the problem using the following approach: - boot - X gdm login screen comes up - shift-ctrl-2 to enter a console - login as root - telinit 3 to shutdown X - ps axfuwww|grep -i gconf => nothing - ifconfig eth0 192.168.x.x netmask 255.255.255 - telinit 5 - login - everything works fine. It seems gconf requires a configured tcp/ip device on boot? If true, that's new, it wasn't necessary prior to today's upgrade.
could be gconf isn't able to talk to dbus-daemon. when it's in this state is dbus-daemon runnng?
(In reply to comment #1) > could be gconf isn't able to talk to dbus-daemon. when it's in this state is > dbus-daemon runnng? It is running.
Luckily, today I was able to identify the cause. I'm using an encrypted /tmp directory. $ grep -w tmp /etc/crypttab tmpcrypt /dev/sda6 /dev/urandom tmp $ grep -w tmp /etc/fstab /dev/mapper/tmpcrypt /tmp ext2 defaults,noatime 0 0 The following is happening: - system starts up - encrypted tmp is not yet mounted - some processes start to execute and create files in /tmp/ - the tmp filesystem is mounted, thereby hiding all files inside /tmp/ that were created earlier - the processes that created those files get confused and malfunction This is probably caused by the fact, that two attempts are being made to unlock crypted filesystems. If I disable the separate tmp filesystem, thereby causing that all tmp files remain on the / filesystem, and remain visible all the time, the problem reported in this bug is gone. I think that startup of all server processes and all GUI/X processes should be delayed until after the second pass of encrypted filesystem unlocking, and until after the second attempt of mounting all filesystems.
Your configuration may be a bit out of the realm of supportability, not sure. At any rate, moving to systemd since it's not really a gconf problem.
It cannot be systemd, because it did not exist in Fedora 13. Moving to some other component, say... initscripts. (But if you can reproduce it in Fedora 15 with systemd, we'd like to know about it.)
This looks related to bug 667282.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
(In reply to comment #5) > It cannot be systemd, because it did not exist in Fedora 13. > > Moving to some other component, say... initscripts. > > (But if you can reproduce it in Fedora 15 with systemd, we'd like to know about > it.) With Fedora 15, it's worse. I had disabled the encrypted tmp filesystem, upgraded to F15, and ran that confi for a couple of weeks. Today I tried to reenable my former, preferred configuration. I enabled the /tmp entry in fstab. The system doesn't even start up. It deadlocks after I enter the disk encryption password for home volume. I can use ctrl-alt-delete to get out of the deadlock and reboot, disable the encrypted tmp, reboot, and it works again. Looks like an encrypted tmp filesystem would require careful tweaking of the order of events executed by systemd, to ensure tmp is mounted after encrypted unlocking is ready, and mount tmp prior to any other service that may require the tmp filesystem...
Please boot with "systemd.log_level=debug systemd.log_target=kmsg" on the kernel cmdline, and remove "quiet" form it. Then, please provide us with the last output when this freezes. (screenshot is fine)
Screenshot: http://kuix.de/misc/bug610827.jpg After I entered the password for /home, the system got stuck again, and luckily all information printed did fit on the screen. You can still see the password prompt in the topmost line. (I can always reproduce, by enabling the mountpoint for /tmp in fstab.)
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Is this still a problem or can this bug be closed?
It's still an issue until someone confirms that it's working now. Unfortunately I've repartitioned my primary machine and forgot to reserve space for an encrypted tmp partition, so I can't test at this time.
(In reply to comment #14) > It's still an issue until someone confirms that it's working now. I dont follow how you come to that conclusion and to point out that you first experienced this against F13 as you mention there in comment one which did not even have systemd which pretty much rules out systemd. ( perhaps should have been filed against util-linux or ecryptfs-utils? ) > Unfortunately I've repartitioned my primary machine and forgot to reserve space > for an encrypted tmp partition, so I can't test at this time. To proparly diagnose this we need you to boot with 'log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg' then save the output of the dmesg command and attach it here. We will also need you to attach /etc/crypttab along with /etc/fstab to this report and even /etc/mtab as well. Now given that you no longer can provide us with this info I am forced to close this as insufficient data. Feel free to reopen it if you still experience this and can provide us with that information or open a new bug against F16 or rawhide if this bug is present there. Thanks.