|Summary:||boot failure with encrypted /tmp|
|Product:||[Fedora] Fedora||Reporter:||Kai Engert (:kaie) (inactive account) <kengert>|
|Status:||CLOSED INSUFFICIENT_DATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||15||CC:||harald, iarlyy, johannbg, johannbg, johannbg, jonathan, lpoetter, metherid, mschmidt, notting, plautrba|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-01-29 13:06:46 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Kai Engert (:kaie) (inactive account) 2010-07-02 14:21:01 UTC
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.
Comment 1 Ray Strode [halfline] 2011-04-28 13:23:32 UTC
could be gconf isn't able to talk to dbus-daemon. when it's in this state is dbus-daemon runnng?
Comment 2 Kai Engert (:kaie) (inactive account) 2011-05-20 13:13:47 UTC
(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.
Comment 3 Kai Engert (:kaie) (inactive account) 2011-05-20 13:22:27 UTC
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.
Comment 4 Ray Strode [halfline] 2011-05-20 16:58:14 UTC
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.
Comment 5 Michal Schmidt 2011-05-23 09:15:11 UTC
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.)
Comment 7 Bug Zapper 2011-06-01 14:56:18 UTC
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
Comment 8 Bug Zapper 2011-06-27 19:19:37 UTC
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.
Comment 9 Kai Engert (:kaie) (inactive account) 2011-07-15 16:31:01 UTC
(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...
Comment 10 Lennart Poettering 2011-07-18 23:29:17 UTC
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)
Comment 11 Kai Engert (:kaie) (inactive account) 2011-07-19 12:41:01 UTC
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.)
Comment 12 Fedora Admin XMLRPC Client 2011-10-20 16:30:02 UTC
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 13 Jóhann B. Guðmundsson 2012-01-24 11:21:01 UTC
Is this still a problem or can this bug be closed?
Comment 14 Kai Engert (:kaie) (inactive account) 2012-01-24 17:34:07 UTC
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.
Comment 15 Jóhann B. Guðmundsson 2012-01-29 13:06:46 UTC
(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.