Bug 610827 - boot failure with encrypted /tmp
boot failure with encrypted /tmp
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
15
All Linux
low Severity high
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-02 10:21 EDT by Kai Engert (:kaie)
Modified: 2012-01-29 08:06 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-29 08:06:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Installed packages (10.46 KB, text/plain)
2010-07-02 10:21 EDT, Kai Engert (:kaie)
no flags Details

  None (edit)
Description Kai Engert (:kaie) 2010-07-02 10:21:01 EDT
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 09:23:32 EDT
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) 2011-05-20 09:13:47 EDT
(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) 2011-05-20 09:22:27 EDT
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 12:58:14 EDT
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 05:15:11 EDT
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 6 Bill Nottingham 2011-05-23 12:40:59 EDT
This looks related to bug 667282.
Comment 7 Bug Zapper 2011-06-01 10:56:18 EDT
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 15:19:37 EDT
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) 2011-07-15 12:31:01 EDT
(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 19:29:17 EDT
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) 2011-07-19 08:41:01 EDT
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 12:30:02 EDT
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 06:21:01 EST
Is this still a problem or can this bug be closed?
Comment 14 Kai Engert (:kaie) 2012-01-24 12:34:07 EST
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 08:06:46 EST
(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.

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