From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20070718 Fedora/1.5.0.12-4.fc6 Firefox/1.5.0.12 Description of problem: Since my last yum system upgrade, cryptsetup does not work to either open (luksOpen) or format (luksFormat) filesystems (on files via loopback). The command exits with no error messages. The The files themselves are intact as I can open them on an i386 FC6 laptop that I have not patched yet. I can also open them on the affected machine using the pre-compiled AMD64 cryptsetup binary at http://luks.endorphin.org/dm-crypt. The latter is a static binary built for a 2.4 kernel. /sbin/cryptsetup appears to be a statically linked binary, so I don't see how it could be broken. Here are the packages that were changed during the last upgrade: Oct 08 23:04:47 Updated: kdelibs.i386 3.5.7-1.fc6 Oct 08 23:05:02 Updated: kdelibs.x86_64 3.5.7-1.fc6 Oct 08 23:05:30 Updated: kdebase.x86_64 3.5.7-1.fc6 Oct 08 23:05:43 Updated: kdebase.i386 3.5.7-1.fc6 Oct 08 23:05:44 Updated: perl-Net-DNS.x86_64 0.61-1.fc6 Oct 08 23:05:46 Updated: selinux-policy.noarch 2.4.6-94.fc6 Oct 08 23:05:48 Updated: postgresql-libs.i386 8.1.10-1.fc6 Oct 08 23:05:49 Updated: postgresql-libs.x86_64 8.1.10-1.fc6 Oct 08 23:05:52 Updated: tzdata.noarch 2007h-1.fc6 Oct 08 23:06:06 Installed: kernel-devel.x86_64 2.6.22.9-61.fc6 Oct 08 23:06:09 Updated: kernel-headers.x86_64 2.6.22.9-61.fc6 Oct 08 23:06:28 Installed: kernel.x86_64 2.6.22.9-61.fc6 Oct 08 23:06:30 Updated: elinks.x86_64 0.11.3-1.fc6 Oct 08 23:06:40 Updated: selinux-policy-targeted.noarch 2.4.6-94.fc6 The kernel upgrade also forced me to rebuild my NVidia graphics drivers. Version-Release number of selected component (if applicable): cryptsetup-luks-1.0.3-2.3.fc6 kernel-2.6.22.9-61.fc6 How reproducible: Always Steps to Reproduce: 1. Create a luks encrypted file system on a file (this step fails if bug exists at "cryptsetup luksFormat /dev/loopN name"). If you have a pre-existing file you can try script below to try to open it. 2. use the script supplied below to mount it. (argument is path to file to be mounted) 3. Script detects that nothing created under /dev/mapper and removes loopback. Actual Results: sudo ~/bin/copen2 ./encryptedfs Password: /dev/mapper/encryptedfs does not exist removing loopback. Expected Results: sudo ~/bin/copen ./encryptedfs Password: Enter LUKS passphrase: key slot 0 unlocked. Command successful. Additional info: #!/bin/sh pathto=$1 base=`basename $pathto` loop=`/sbin/losetup -f` /sbin/losetup $loop $pathto /sbin/cryptsetup -v luksOpen $loop $base if [ -e /dev/mapper/$base ]; then mkdir /mnt/$base mount /dev/mapper/$base /mnt/$base else echo /dev/mapper/$base does not exist removing loopback. /sbin/losetup -d $loop fi
Looks like a problem with the updated SELinux packages, although I don't see any problems in logs. See: # getenforce Enforcing # cryptsetup luksOpen /dev/hda3 stuff <- nothing happens here # setenforce 0 # cryptsetup luksOpen /dev/hda3 stuff Enter LUKS passphrase: key slot 0 unlocked. Command successful. <- YAY! Also see another workaround: # getenforce Enforcing # which cryptsetup /sbin/cryptsetup # cp /sbin/cryptsetup /tmp # ls -Z /sbin/cryptsetup /tmp/cryptsetup -rwxr-xr-x root root system_u:object_r:lvm_exec_t:s0 /sbin/cryptsetup -rwxr-xr-x root root user_u:object_r:tmp_t:s0 /tmp/cryptsetup # /tmp/cryptsetup luksOpen /dev/hda3 stuff Enter LUKS passphrase: key slot 0 unlocked. Command successful. <- interesting, the same cryptsetup binary, executed from another directory, with another context, works What do you think, Daniel? Thanks.
2.4.6-107.fc6 Should fix this.
I hope this is the correct component now.
Great! I'm not seeing this issue with 2.4.6-107.fc6 from updates-testing anymore.