Bug 678927 - Password prompt for unlocking encrypted /home partition sometimes does not appear
Summary: Password prompt for unlocking encrypted /home partition sometimes does not ap...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 683835 (view as bug list)
Depends On:
Blocks: 679842
TreeView+ depends on / blocked
 
Reported: 2011-02-20 21:58 UTC by Matěj Cepl
Modified: 2018-04-11 19:03 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 679842 (view as bug list)
Environment:
Last Closed: 2011-04-01 18:21:37 UTC


Attachments (Terms of Use)
output of dmesg command (85.65 KB, text/plain)
2011-02-20 21:58 UTC, Matěj Cepl
no flags Details
dmesg output (123.83 KB, text/plain)
2011-04-01 05:13 UTC, Bruno Wolff III
no flags Details
Another dmesg sample (123.69 KB, text/plain)
2011-04-01 14:21 UTC, Bruno Wolff III
no flags Details

Description Matěj Cepl 2011-02-20 21:58:08 UTC
Created attachment 479795 [details]
output of dmesg command

Description of problem:
When booting my system I get SELinux denial on systemd-tty-ask and then system freezes for half a minute or so and then it continues in startup, but it is not unlocking encrypted partitions (/home and swap), so the system start without /home and swap. The latter is not important for me (I have 4GB physical RAM on my computer), but the former completely breaks my login to Gnome. I have to switch back to console, unlock partitions, switch between runlevel 3 and back to runlevel 5 to get real gdm login.

Just to be sure, system is just after
touch /.autorelabel ; reboot
operation, so bad labels shouldn't be the issue.

And yes, this happens even though I have SELinux in a permissive mode.

Version-Release number of selected component (if applicable):
selinux-policy-3.9.15-1.fc16.noarch
systemd-18-1.fc16.x86_64


How reproducible:
100%

Additional info:
jakoubek:~# dmesg |grep avc
[   13.736246] type=1400 audit(1298238053.417:3): avc:  denied  { mmap_zero } for  pid=532 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect
[   17.917743] type=1400 audit(1298238057.598:4): avc:  denied  { write } for  pid=839 comm="systemd-tty-ask" name="sck.14102234336533528066" dev=devtmpfs ino=11937 scontext=system_u:system_r:systemd_passwd_agent_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=sock_file
[   74.781576] dbus[900]: avc:  netlink poll: error 4
[   75.016982] type=1400 audit(1298238114.697:5): avc:  denied  { sys_tty_config } for  pid=950 comm="cgconfigparser" capability=26  scontext=system_u:system_r:cgconfig_t:s0 tcontext=system_u:system_r:cgconfig_t:s0 tclass=capability

Comment 1 Lennart Poettering 2011-02-21 14:51:51 UTC
Dan?

Comment 2 Daniel Walsh 2011-02-21 16:18:42 UTC
First remove the vbetool which you probably do not need, this will remove the mmap_zero avc.

Second we can add the sys_tty_config for cgconfig_t.

THe systemd-tty-ask writing to a sock_file labled device_t looks like a bug in the app that created the socket.  Lennart, do you know which executable would have created this sock_file? sck.14102234336533528066?  Under /dev

If this happens in permissive mode, it is most likely not related to SELinux.

Comment 3 Lennart Poettering 2011-02-21 21:43:57 UTC
(In reply to comment #2)

> THe systemd-tty-ask writing to a sock_file labled device_t looks like a bug in
> the app that created the socket.  Lennart, do you know which executable would
> have created this sock_file? sck.14102234336533528066?  Under /dev

That's systemd-cryptsetup tool which places a text file containing a question and a socket to receive the response on in /dev/.systemd/ask-password. Some kind of agent (during boot that is plymouth) then sees that (via inotify) and brings it on the screen, passing the entered password back to systemd-cryptsetup via the socket.

Comment 4 James Laska 2011-02-22 19:00:29 UTC
I believe this use case is captured by the following F-15-Alpha release criteria [1].

    "The installer must be able to complete an installation using the 
     entire disk, existing free space, or existing Linux partitions 
     methods, with or without encryption enabled "

Given a large enough disk, anaconda recommends a separate /home partition.  Considering that with a big enough disk, this is the default scenario and doesn't require custom partitioning, I believe this issue is captured by the above criteria.  I support this as an Alpha release blocker.

[1] https://fedoraproject.org/wiki/Fedora_15_Alpha_Release_Criteria

Comment 5 Miroslav Grepl 2011-02-23 16:32:28 UTC
But still, this happens in permissive mode as Matej wrote above.

Comment 6 Miroslav Grepl 2011-02-23 17:04:44 UTC
Matej,
btw. how is labeled your systemd-cryptsetup

# ls -Z /lib/systemd/systemd-cryptsetup

Do you have disabled unconfined module also? If yes, I think you should see different AVC msgs which I am seeing.

Comment 7 Miroslav Grepl 2011-02-23 18:15:37 UTC
So I think this could be fixed from SELinux side for now using

dev_filetrans(lvm_t, lvm_var_run_t, sock_file)

and allow an access for systemd-tty-ask.

Comment 8 James Laska 2011-02-23 21:14:42 UTC
(In reply to comment #4)
> I believe this use case is captured by the following F-15-Alpha release
> criteria [1].
> 
>     "The installer must be able to complete an installation using the 
>      entire disk, existing free space, or existing Linux partitions 
>      methods, with or without encryption enabled "
> 
> Given a large enough disk, anaconda recommends a separate /home partition. 
> Considering that with a big enough disk, this is the default scenario and
> doesn't require custom partitioning, I believe this issue is captured by the
> above criteria.  I support this as an Alpha release blocker.
> 
> [1] https://fedoraproject.org/wiki/Fedora_15_Alpha_Release_Criteria

I'm recalling my previous assertion that this issue blocks the Alpha release criteria.  In my testing, it seems that a 50G disk size is required for anaconda to recommend a /home partition.  The Alpha criteria are intended to capture partitioning scenarios that a user can encounter on the *first* partitioning installer screen (Use all disk, replace, shrink, encrypt, etc...).  In simulating a test with a 50G disk, and checking 'Encrypt', anaconda encrypts the LVM physical volumes, *not* the LVM logical volumes. All LVM logical volumes are based on the VG that uses the encrypted PV's.

I believe this means that dracut prompts to unlock the encrypted PV's where swap and '/' reside, and won't later prompt for encrypted /home that resides on the same PVs.  NOTE, in my test this wasn't the case.  I was prompted for a passphrase 2 times on boot-up.  I was only expecting one prompt for the encrypted PVs.

However, I had no trouble logging into GDM with my newly created user and the user had access to the encrypted /home/$USER

I think this also means that a user cannot hit this issue without manually partitioning and selecting encrypted LVM logical /home partition, or a regular encrypted disk partition for /home.  Neither of these are choices in the first installer partitioning screen.

Comment 9 Miroslav Grepl 2011-02-24 10:49:27 UTC
It works fine in enforcing mode from SELinux perspective. 

Since systemd_passwd_agent_t domain runs as permissive domain and lvm_t domain is unconfined domain by default.

Comment 10 Matěj Cepl 2011-02-24 11:09:24 UTC
jakoubek:~ $ ls -Z /lib/systemd/systemd-cryptsetup
-rwxr-xr-x. root root system_u:object_r:lvm_exec_t:s0  /lib/systemd/systemd-cryptsetup
jakoubek:~# semodule -l |grep unconfined
unconfined	3.3.0
unconfineduser	1.0.0
jakoubek:~ $

Comment 11 Miroslav Grepl 2011-02-24 11:37:24 UTC
Ok, could you try to add this local policy and see if you get different avc msgs for systemd_passwd_agent_t domain


# cat  mysystemd.te

policy_module(mysystemd,1.0)

require{
 type lvm_t;
 type lvm_var_run_t;
 type systemd_passwd_agent_t;
}

dev_filetrans(lvm_t, lvm_var_run_t, { file sock_file })
#allow systemd_passwd_agent_t lvm_t:unix_dgram_socket sendto;
#allow systemd_passwd_agent_t self:unix_dgram_socket { write create };
#allow systemd_passwd_agent_t lvm_t:file read;


# make -f /usr/share/selinux/devel/Makefile
# semodule -i mysystemd.pp

Comment 12 Miroslav Grepl 2011-02-24 12:01:13 UTC
Dan,
what do you think about rules in the commnet #11. 

I would rather use the following solution


# for temporary sockets and files in /dev/.systemd/ask-password
interface(`systemd_passwd_agent_dev_template',`
        gen_require(`
                type systemd_passwd_agent_t;
        ')

        # Declaration
        type $1_systemd_device_t;
        files_type($1_systemd_device_t)
        dev_associate($1_systemd_device_t)

        # Rules
        dev_filetrans($1_t, $1_systemd_device_t, { file sock_file })
        allow $1_t $1_systemd_device_t:file manage_file_perms;
        allow $1_t $1_systemd_device_t:sock_file manage_sock_file_perms;

        allow systemd_passwd_agent_t $1_t:unix_dgram_socket sendto;
        allow systemd_passwd_agent_t $1_t:file read ;
')

and

systemd_passwd_agent_dev_template(lvm)

Comment 13 Miroslav Grepl 2011-02-24 12:03:17 UTC
Oops,

< allow systemd_passwd_agent_t $1_t:file read ;
> allow systemd_passwd_agent_t $1_systemd_device_t_t:file read ;

Comment 14 Daniel Walsh 2011-02-24 18:14:56 UTC
Looks ok.

Comment 15 Miroslav Grepl 2011-02-25 14:01:59 UTC
Fixed in selinux-policy-3.9.15-3.fc15

Comment 16 Adam Williamson 2011-02-25 16:54:37 UTC
given jlaska's earlier assertion, moving to F15Beta. needs testing to determine the exact impact here; we should test with the fixed SELinux and encrypted /home LV.

Comment 17 Lukas Bezdicka 2011-03-01 15:17:01 UTC
Last what I get from systemd is Starting to initialize storage subsystems before that there's Starting Forward Password Requests to Plymouth. rc6git6.1 kernel hangs there, rc6.git4.1 asks for password.
I'm not getting any avcs.

Comment 18 Matěj Cepl 2011-03-11 18:49:06 UTC
Not sure, whether the behavior of this bug has changed or not, but now I can reproduce it 100% (5 out of 5 at least) with cold restart (power off and power on with the switch). If I then reboot, everything works correctly.

Comment 19 Adam Williamson 2011-03-11 18:52:08 UTC
Discussed at 2011-03-11 blocker review meeting. We agreed we're still unsure on the impact of this bug; mcepl will test further and we will review next week. We agreed in principle that if you hit this bug with a default install with encrypted /home (i.e. no changes other than hit the 'encrypt home partition' box), it's a Beta blocker; if you don't hit it unless you use a custom partition layout, it's a Final blocker.

Comment 20 Matěj Cepl 2011-03-11 18:53:09 UTC
and yes I still see SELinux AVC denials around calling systemd-tty-ask.

This is the one:

SELinux is preventing systemd-tty-ask from 'write' accesses on the sock_file
sck.3847531483500995573.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that systemd-tty-ask should be allowed write access on the
sck.3847531483500995573 sock_file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep systemd-tty-ask /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:systemd_passwd_agent_t:s0
Target Context                system_u:object_r:device_t:s0
Target Objects                sck.3847531483500995573 [ sock_file ]
Source                        systemd-tty-ask
Source Path                   systemd-tty-ask
Port                          <Neznámé>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.15-2.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 2.6.38-0.rc6.git6.1.fc15.x86_64
#1
                              SMP Sat Feb 26 01:14:56 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Út 8. březen 2011, 22:38:20 CET
Last Seen                     Út 8. březen 2011, 22:38:20 CET
Local ID                      f2cdc926-e672-48da-8e8a-46190a60a536

Raw Audit Messages
type=AVC msg=audit(1299620300.384:34): avc:  denied  { write } for  pid=855
comm="systemd-tty-ask" name="sck.3847531483500995573" dev=devtmpfs ino=16877
scontext=system_u:system_r:systemd_passwd_agent_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=sock_file


Hash: systemd-tty-ask,systemd_passwd_agent_t,device_t,sock_file,write

audit2allow

#============= systemd_passwd_agent_t ==============
allow systemd_passwd_agent_t device_t:sock_file write;

audit2allow -R

#============= systemd_passwd_agent_t ==============
allow systemd_passwd_agent_t device_t:sock_file write;

------------------------------------------------------------------------------
this is the other
SELinux is preventing systemd-tty-ask from 'connectto' accesses on the
unix_stream_socket @/org/freedesktop/plymouthd.

*****  Plugin catchall (100. confidence) suggests  ***************************

If you believe that systemd-tty-ask should be allowed connectto access on the
plymouthd unix_stream_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep systemd-tty-ask /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:systemd_passwd_agent_t:s0
Target Context                system_u:system_r:kernel_t:s0
Target Objects                @/org/freedesktop/plymouthd [ unix_stream_socket
]
Source                        systemd-tty-ask
Source Path                   systemd-tty-ask
Port                          <Neznámé>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
Policy RPM                    selinux-policy-3.9.15-2.fc15
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 2.6.38-0.rc6.git6.1.fc15.x86_64
#1
                              SMP Sat Feb 26 01:14:56 UTC 2011 x86_64 x86_64
Alert Count                   1
First Seen                    Út 8. březen 2011, 22:38:20 CET
Last Seen                     Út 8. březen 2011, 22:38:20 CET
Local ID                      74e561cc-0be5-4e8b-a40f-1d2d8b7c490c

Raw Audit Messages
type=AVC msg=audit(1299620300.386:35): avc:  denied  { connectto } for  pid=855
comm="systemd-tty-ask"
path=002F6F72672F667265656465736B746F702F706C796D6F75746864
scontext=system_u:system_r:systemd_passwd_agent_t:s0
tcontext=system_u:system_r:kernel_t:s0 tclass=unix_stream_socket


Hash:
systemd-tty-ask,systemd_passwd_agent_t,kernel_t,unix_stream_socket,connectto

audit2allow

#============= systemd_passwd_agent_t ==============
allow systemd_passwd_agent_t kernel_t:unix_stream_socket connectto;

audit2allow -R

#============= systemd_passwd_agent_t ==============
allow systemd_passwd_agent_t kernel_t:unix_stream_socket connectto;

Comment 22 Daniel Walsh 2011-03-11 20:41:53 UTC
Neither of these is actually blocked system systemd_passwd_agent_t is a permissive domain.

Comment 23 Matěj Cepl 2011-03-12 12:27:25 UTC
(In reply to comment #22)
> Neither of these is actually blocked system systemd_passwd_agent_t is a
> permissive domain.

OK, just want to be sure it is not overlooked.

Comment 25 Daniel Walsh 2011-03-14 19:19:24 UTC
I added all of these rules to policy.

Fixed in selinux-policy-3.9.16-4.fc15.noarch

Comment 26 Adam Williamson 2011-03-18 17:51:17 UTC
Discussed at 2011-03-18 blocker review meeting. We agreed this definitely does not seem to be a selinux issue, our next  best guess is systemd, so we're re-assigning there; Lennart, can you please take a look at this, with the help of the logs provided by Matej?

We still do not have enough info on the circumstances of this bug to make a clear call on blocker status. We will discuss again next week, we hope with feedback from lennart and possibly more info from matej and bruno.

Comment 27 Bruno Wolff III 2011-03-18 19:43:16 UTC
683835 may be a duplicate of this. I filed that bug separately as it was clear that selinux wasn't blocking the boot as I still got the warning messages (before the new policy was installed) and the system would still sometimes boot.
I am doing a full relabel on a system I am seeing this on now and will test to make sure I still see the problem afterwards.

Comment 28 Adam Williamson 2011-03-19 02:47:19 UTC
Editing the summary to make it clear this is not an SELinux issue.

Comment 29 Bruno Wolff III 2011-03-19 15:41:14 UTC
I tested rebooting after doing a full relabel and I am still seeing a hang when it gets to the point where encrypted devices are unlocked after root has been pivoted.

Comment 30 Daniel Walsh 2011-03-21 22:02:39 UTC
Bruno if you do this in permissive mode to you see the hang?

Comment 31 Bruno Wolff III 2011-03-21 23:44:25 UTC
I set permissive more in /etc/selinux config (as a work around for the rsyslog issue) and I still am getting random failures to mount encrypted devices. Unless you think doing this using the enforcing=0 kernel parameter would give a different result, I think the issue is not selinux related.

Comment 32 Daniel Walsh 2011-03-22 11:55:59 UTC
No that should be the same.

Comment 33 Bobby Powers 2011-03-25 06:30:46 UTC
I also am hitting this on every boot, and have selinux set to permissive mode.  interesting dmesg output:


[    2.733516] dracut: dracut-008-7.fc16
[    2.755027] dracut: rd.luks=0: removing cryptoluks activation
[    2.760792] dracut: rd.lvm=0: removing LVM activation
...
[   68.378148] systemd-cryptsetup[767]: Timed out
[   68.378190] systemd-cryptsetup[767]: Failed to query password: Timer expired
[   68.382774] systemd[1]: cryptsetup@sda5_crypt.service: main process exited, code=exited, status=1
[   68.411016] systemd[1]: Unit cryptsetup@sda5_crypt.service entered failed state.

For what its worth, plymouth doesn't seem to be responding to any keyboard input.  I'm use to (on f14) being able to hit escape to see whats going on with services, but hitting escape during boot (of rawhide) doesn't have any effect.  It just appears to hang until after cryptsetup times out.

As this is consistently reproducible, let me know how I can further help debug it.

Comment 34 Bobby Powers 2011-03-25 06:41:22 UTC
Actually, I've rebooted twice since posting that, and both times I see a prompt (first time since upgrading to rawhide a week ago).  These are the updates I've installed today:


Mar 24 14:50:26 Updated: mysql-libs-5.5.10-2.fc16.x86_64
Mar 24 14:50:27 Updated: cyrus-sasl-lib-2.1.23-16.fc16.x86_64
Mar 24 14:50:28 Updated: 1:libreoffice-ure-3.3.2.2-2.fc16.x86_64
Mar 24 14:50:29 Updated: mysql-5.5.10-2.fc16.x86_64
Mar 24 14:50:30 Updated: libudev-166-2.fc16.x86_64
Mar 24 14:50:30 Updated: libgudev1-166-2.fc16.x86_64
Mar 24 14:50:31 Installed: vcdimager-0.7.23-13.fc13.1.x86_64
Mar 24 14:50:32 Installed: vcdimager-libs-0.7.23-13.fc13.1.x86_64
Mar 24 14:50:35 Updated: vlc-core-1.1.8-1.fc15.x86_64
Mar 24 14:50:37 Updated: udev-166-2.fc16.x86_64
Mar 24 14:50:39 Updated: cyrus-sasl-2.1.23-16.fc16.x86_64
Mar 24 14:50:39 Updated: zeromq-2.1.3-1.fc16.x86_64
Mar 24 14:50:40 Updated: pygobject2-2.28.3-1.fc16.x86_64
Mar 24 14:50:41 Updated: glibmm24-2.27.98-1.fc16.x86_64
Mar 24 14:50:41 Updated: pm-utils-1.4.1-7.fc16.x86_64
Mar 24 14:50:42 Updated: redland-1.0.12-3.fc16.x86_64
Mar 24 14:50:42 Updated: apr-util-1.3.10-7.fc16.x86_64
Mar 24 14:50:43 Updated: 1:net-snmp-libs-5.6.1-7.fc16.x86_64
Mar 24 14:50:44 Installed: libGLEW-1.5.8-3.fc16.x86_64
Mar 24 14:50:44 Updated: glew-1.5.8-3.fc16.x86_64
Mar 24 14:50:47 Updated: 1:net-snmp-5.6.1-7.fc16.x86_64
Mar 24 14:50:47 Updated: apr-util-ldap-1.3.10-7.fc16.x86_64
Mar 24 14:50:48 Updated: upower-0.9.9-2.fc16.x86_64
Mar 24 14:50:52 Updated: cyrus-sasl-devel-2.1.23-16.fc16.x86_64
Mar 24 14:50:54 Updated: vlc-1.1.8-1.fc15.x86_64
Mar 24 14:50:55 Updated: shotwell-0.8.90-2.r2758.fc16.x86_64
Mar 24 14:50:56 Updated: cyrus-sasl-gssapi-2.1.23-16.fc16.x86_64
Mar 24 14:50:56 Updated: cyrus-sasl-plain-2.1.23-16.fc16.x86_64
Mar 24 14:50:56 Updated: cyrus-sasl-md5-2.1.23-16.fc16.x86_64
Mar 24 14:50:57 Updated: mysql-connector-odbc-5.1.8-3.fc16.x86_64
Mar 24 14:50:58 Updated: MySQL-python-1.2.3-3.fc16.x86_64
Mar 24 14:51:00 Updated: rsyslog-5.7.9-2.fc16.x86_64
Mar 24 14:51:00 Updated: 1:folks-0.4.2-1.fc16.x86_64
Mar 24 14:51:01 Updated: visualvm-1.3.2-1.2.8.fc16.x86_64
Mar 24 14:51:03 Updated: qt3-3.3.8b-35.fc16.x86_64
Mar 24 14:51:03 Updated: cups-pk-helper-0.1.2-1.fc16.x86_64
Mar 24 14:51:04 Updated: 1:telepathy-mission-control-5.7.7-1.fc16.x86_64
Mar 24 14:51:04 Updated: libconfig-1.4.7-1.fc16.x86_64
Mar 24 14:51:05 Updated: upstart-1.2-1.fc16.x86_64
Mar 24 14:51:06 Updated: man-db-2.5.9-6.fc16.x86_64
Mar 24 14:51:06 Updated: 32:bind-license-9.8.0-2.fc16.noarch
Mar 24 14:51:07 Updated: libdbi-drivers-0.8.3-8.fc16.x86_64
Mar 24 14:51:08 Updated: 32:bind-libs-9.8.0-2.fc16.x86_64
Mar 24 14:51:08 Updated: perl-DBD-MySQL-4.018-3.fc16.x86_64
Mar 24 14:51:09 Updated: pygobject2-codegen-2.28.3-1.fc16.x86_64
Mar 24 14:51:09 Updated: pygobject2-doc-2.28.3-1.fc16.x86_64
Mar 24 14:51:10 Updated: 1:autocorr-en-3.3.2.2-2.fc16.noarch
Mar 24 14:51:11 Updated: 1:libreoffice-opensymbol-fonts-3.3.2.2-2.fc16.noarch
Mar 24 14:51:31 Updated: 1:libreoffice-core-3.3.2.2-2.fc16.x86_64
Mar 24 14:51:31 Updated: 1:libreoffice-impress-3.3.2.2-2.fc16.x86_64
Mar 24 14:51:33 Updated: 1:libreoffice-presenter-screen-3.3.2.2-2.fc16.x86_64
Mar 24 14:51:34 Updated: selinux-policy-3.9.16-6.fc16.noarch
Mar 24 14:51:35 Updated: 1:libreoffice-writer-3.3.2.2-2.fc16.x86_64
Mar 24 14:51:37 Updated: 1:libreoffice-calc-3.3.2.2-2.fc16.x86_64
Mar 24 14:51:39 Updated: mysql-server-5.5.10-2.fc16.x86_64
Mar 24 14:51:39 Updated: libdbi-dbd-mysql-0.8.3-8.fc16.x86_64
Mar 24 14:51:40 Updated: libdbi-dbd-pgsql-0.8.3-8.fc16.x86_64
Mar 24 14:52:05 Updated: selinux-policy-targeted-3.9.16-6.fc16.noarch
Mar 24 14:52:05 Updated: 1:libreoffice-langpack-en-3.3.2.2-2.fc16.x86_64
Mar 24 14:52:06 Updated: pygobject2-devel-2.28.3-1.fc16.x86_64
Mar 24 14:52:06 Updated: 32:bind-utils-9.8.0-2.fc16.x86_64
Mar 24 14:52:06 Updated: 32:bind-libs-lite-9.8.0-2.fc16.x86_64
Mar 24 14:52:07 Updated: glibmm24-devel-2.27.98-1.fc16.x86_64
Mar 24 14:52:08 Updated: zeromq-devel-2.1.3-1.fc16.x86_64
Mar 24 14:52:08 Updated: mysql-bench-5.5.10-2.fc16.x86_64
Mar 24 14:52:09 Updated: perl-HTTP-Message-6.02-1.fc16.noarch
Mar 24 14:52:22 Updated: google-chrome-unstable-12.0.712.0-79102.x86_64
Mar 24 14:52:23 Updated: perl-File-Listing-6.02-1.fc16.noarch
Mar 24 14:52:23 Updated: m17n-db-1.6.2-3.fc16.noarch
Mar 24 14:52:23 Updated: cyrus-sasl-lib-2.1.23-16.fc16.i686

Comment 35 Jóhann B. Guðmundsson 2011-03-25 13:32:59 UTC
Tim mentioned on devel channel that he had a problem unlocking/mounting his encrypted /home partition @boot on devel but he could mount it after running 'vgchange -a y' and ran systemd-tty-ask-password-agent.

Perhaps we are missing an After=fedora-storage-init.service for the ask-passwords services?

Comment 36 Adam Williamson 2011-03-25 18:31:25 UTC
can others try that workaround suggested by Johann and see if it works?

Comment 37 Adam Williamson 2011-03-25 18:33:46 UTC
Discussed at 2011-03-25 blocker review meeting. We agreed to keep monitoring this for more info. It definitely does not look like an SELinux issue. It would help if others can test Johann's conjecture.

Comment 38 Adam Williamson 2011-03-25 18:34:33 UTC
*** Bug 683835 has been marked as a duplicate of this bug. ***

Comment 39 Bobby Powers 2011-03-31 06:40:56 UTC
I haven't had any issues in the 10-15 reboots since my comment 34 above.

Comment 40 Bobby Powers 2011-03-31 06:41:30 UTC
(I didn't try Johann's suggestion, as my problem went away before he posted it)

Comment 41 Matěj Cepl 2011-03-31 13:44:45 UTC
(In reply to comment #37)
> Discussed at 2011-03-25 blocker review meeting. We agreed to keep monitoring
> this for more info. It definitely does not look like an SELinux issue. It would
> help if others can test Johann's conjecture.

Actually, I cannot test it either. Problem somehow evaporated, I don't know where exactly. I have made couple of reboots (including cold ones), and it seems to just work. As far as I am concerned, this could be closed. I would reopen if necessary.

Comment 42 Bruno Wolff III 2011-04-01 05:13:35 UTC
Created attachment 489303 [details]
dmesg output

This is still happening for me. I captured dmesg for a failure case with systemd at an elevated level of debugging. This might shed some additional light on things.
I haven't seen it recur recently on another machine. The one it is still happening on has more encrypted partitions (including swap) and has /var on
a separate encrypted partition.

Comment 43 Jóhann B. Guðmundsson 2011-04-01 06:31:38 UTC
Could you explain a bit more detail on how this is setup as in are you just using a single disk with multiple partitions or are you using multiple disks/raid basically how your setup differs from default. 

There was an bug in mdadm ( missing udev rules ) which is fixed in this update here https://admin.fedoraproject.org/updates/mdadm-3.1.5-2.fc15 

Not sure it's relevant in this case but we need to start tracking down peoples setup to find the cause for this but Bruno might be experiencing the same bug as Tim ( Bug 692198 )

Comment 44 Bruno Wolff III 2011-04-01 12:35:01 UTC
[root@bruno bruno]# blkid
/dev/md4: UUID="671767b0-ead3-47c5-a2f5-6b1fb99fc968" TYPE="ext3" LABEL="Boot" 
/dev/mapper/luks-58aa4879-4d9f-4074-ac4b-173be649c36d: LABEL="root" UUID="78a155be-b973-494c-bddf-0f583a250477" TYPE="ext3" 
/dev/sda1: UUID="b0e984e0-91ab-6ad2-66d7-41aae75c1ac4" TYPE="linux_raid_member" 
/dev/sda2: UUID="a72c91b7-1e68-a623-6e61-9a2266c37fa8" TYPE="linux_raid_member" 
/dev/sda3: UUID="99cd7b6c-82c5-76c1-a38d-42547d538f74" TYPE="linux_raid_member" 
/dev/sda5: UUID="952daa1d-4de6-b845-1f10-1088dc53b397" TYPE="linux_raid_member" 
/dev/sda6: UUID="df0371b7-af4a-cc67-4744-d2983e554330" TYPE="linux_raid_member" 
/dev/sdb1: UUID="b0e984e0-91ab-6ad2-66d7-41aae75c1ac4" TYPE="linux_raid_member" 
/dev/sdb2: UUID="a72c91b7-1e68-a623-6e61-9a2266c37fa8" TYPE="linux_raid_member" 
/dev/sdb3: UUID="99cd7b6c-82c5-76c1-a38d-42547d538f74" TYPE="linux_raid_member" 
/dev/sdb5: UUID="952daa1d-4de6-b845-1f10-1088dc53b397" TYPE="linux_raid_member" 
/dev/sdb6: UUID="df0371b7-af4a-cc67-4744-d2983e554330" TYPE="linux_raid_member" 
/dev/md6: UUID="bb224e36-976e-49fc-86a6-ee8c23b0694f" TYPE="crypto_LUKS" 
/dev/md10: UUID="f022434a-2aef-438a-836d-109e7b4ce931" TYPE="crypto_LUKS" 
/dev/md9: UUID="58aa4879-4d9f-4074-ac4b-173be649c36d" TYPE="crypto_LUKS" 
/dev/md8: UUID="585ccbdd-26aa-4d06-ac88-e412c7dc6135" TYPE="crypto_LUKS" 
/dev/mapper/luks-585ccbdd-26aa-4d06-ac88-e412c7dc6135: LABEL="var" UUID="78a155be-b973-494c-bddf-0f583a250477" TYPE="ext3" 
/dev/mapper/luks-f022434a-2aef-438a-836d-109e7b4ce931: LABEL="Home" UUID="c388440c-6f36-406b-a466-f624cba113dd" TYPE="ext3" 
/dev/mapper/luks-bb224e36-976e-49fc-86a6-ee8c23b0694f: UUID="984b69d9-d27d-42a4-b52f-56a4d4dbf989" TYPE="swap" 

/dev/mapper/luks-58aa4879-4d9f-4074-ac4b-173be649c36d /                ext3    d
efaults,noatime,barrier=1        1 2
/dev/mapper/luks-f022434a-2aef-438a-836d-109e7b4ce931 /home                   ex
t3    defaults,noatime,barrier=1        1 2
/dev/mapper/luks-585ccbdd-26aa-4d06-ac88-e412c7dc6135 /var                      
 ext3    defaults,noatime,barrier=1        1 1
/dev/md4                /boot                   ext3    defaults,noatime,barrier
=1        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/mapper/luks-bb224e36-976e-49fc-86a6-ee8c23b0694f swap                    sw
ap    defaults        0 0

Comment 45 Jóhann B. Guðmundsson 2011-04-01 12:56:15 UTC
And this is tested and still failing with the mentioned above mdadm upate?

( given that .. )

/dev/md6: UUID="bb224e36-976e-49fc-86a6-ee8c23b0694f" TYPE="crypto_LUKS" 
/dev/md10: UUID="f022434a-2aef-438a-836d-109e7b4ce931" TYPE="crypto_LUKS" 
/dev/md9: UUID="58aa4879-4d9f-4074-ac4b-173be649c36d" TYPE="crypto_LUKS" 
/dev/md8: UUID="585ccbdd-26aa-4d06-ac88-e412c7dc6135" TYPE="crypto_LUKS"

Comment 46 Bruno Wolff III 2011-04-01 13:26:46 UTC
Yes the dmesg output is from after I updated to mdadm-3.1.5-2.fc15.i686. I didn't run dracut again though.

Comment 47 Bruno Wolff III 2011-04-01 14:21:10 UTC
Created attachment 489416 [details]
Another dmesg sample

After updating to systemd-22-1.fc15.i686 and rerunning dracut in case that would pick up a newer version of mdadm in the initramfs, I did another reboot test.
This time I got asked for a password for / early in the boot process and then later for /home. This is different behavior than I have seen in the past but seemed to work (for at least this one boot) in that all of the encrypted file systems were mounted after the boot finished.

Comment 48 Lennart Poettering 2011-04-01 18:20:36 UTC
OK, closing for now, since this apparently is fixed. If not, please don't hesitate to open a new bug, nad mention this one. Please do not reopen this.

Comment 49 Tim Flink 2011-04-01 20:32:51 UTC
(In reply to comment #48)
> OK, closing for now, since this apparently is fixed. If not, please don't
> hesitate to open a new bug, nad mention this one. Please do not reopen this.

Discussed in the 2011-04-01 blocker bug review meeting. Since this bug is now closed, removing it as a blocker. If a new bug is created, it can be re-submitted for blocker review at that time.


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