Description of problem: dracut creates initscripts that ignore keyfile option in crypttab /usr/share/dracut/modules.d/90crypt/cryptroot-ask.sh does not compy with crypttab(5) where it's said: The third field specifies the encryption password. If the field is not present or the password is set to none, the password has to be manually entered during system boot. Otherwise the field is interpreted as a path to a file containing the encryption password. For swap encryption /dev/urandom or the hardware device /dev/hw_random can be used as the password file; using /dev/random may prevent boot completion if the system does not have enough entropy to generate a truly random encryp‐ tion key.
Yes, but what is your use case? Including a password file in the initramfs does not help security...
Usecase is quite stupid I know, I have 1TB of encrypted data and I recently moved it to safe enough location, but I don't have resources to store data somewhere else while I'll remove encryption. Is there way to drop encryption without data loss?
(In reply to comment #2) > Usecase is quite stupid I know, I have 1TB of encrypted data and I recently > moved it to safe enough location, but I don't have resources to store data > somewhere else while I'll remove encryption. Is there way to drop encryption > without data loss? and why does the data have to be decrypted during the initramfs boot phase and not later on?
probably later. It should be ok if systemd took care of it but I guess it ignores crypttab too and as it wants to mount that disk, it fails.
(In reply to comment #4) > probably later. It should be ok if systemd took care of it but I guess it > ignores crypttab too and as it wants to mount that disk, it fails. no, systemd is fine with crypttab
Hey, it is a bug because system does not boot, you say that systemd is fine so why it won't boot? Than it has to be dracut as it stops and waits for user input. Should I open bugreport on systemd?
(In reply to comment #6) > Hey, it is a bug because system does not boot, you say that systemd is fine so > why it won't boot? Than it has to be dracut as it stops and waits for user > input. Should I open bugreport on systemd? 1. please show me your kernel command line 2. please boot without "rhgb" and "quiet" on the kernel command line Do you see "Welcome to ..." ? If yes, then systemd is running and dracut has finished
I looked on machine's setup so: - root is on raid md0 - md0 consists of: 30gb volume on sda and 30gb volume on LVM - LVM disk is encrypted so by documentation shis should work and yes it's mad :(
ok, try this: # dracut --install <my_password_file> /boot/initramfs-<kernel_version>.img <kernel_version> ... I will fix dracut, so that you can put install_items=" <my_password_file> " in /etc/dracut.conf.d/99-mypwfile.conf
well for now I see only ./sbin/cryptroot-ask in initrd, which does not seem to be capable of opening encrypted device with key from file. But yes it worked and I have key file in initrd.
dracut-013-19.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/dracut-013-19.fc16
Package dracut-013-19.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dracut-013-19.fc16' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-16098/dracut-013-19.fc16 then log in and leave karma (feedback).
dracut-013-19.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
Today I got to the machine and after update it worked fine. Thank you.
I updated to Fedora 18 and this seemed to stop working. I have to type my password again. Anyone else see this?
(In reply to John Villalovos from comment #15) > I updated to Fedora 18 and this seemed to stop working. I have to type my > password again. Anyone else see this? I think I figured out the issue. dracut doesn't seem to be copying /etc/crypttab into the initrd. I'll look and see if there is a bug on that. I created my dracut file by just doing: # dracut --force My keyfile got copied but not the /etc/crypttab :( But I was having this issue after doing the upgrade and I did not manually run dracut. I have fixed the issue temporarily by doing: # dracut --force --install /etc/crypttab
My initial theory is that this commit broke things for the use case of this BZ: commit 3d12d7a2cc5d4fc76ac87514dae2ab27bac8208c Author: Harald Hoyer <harald> Date: Mon Sep 24 13:15:08 2012 +0200 crypt: install /etc/crypttab only in host-only mode diff --git a/modules.d/90crypt/module-setup.sh b/modules.d/90crypt/module-setup.sh index 485cbe0..5c1c71b 100755 --- a/modules.d/90crypt/module-setup.sh +++ b/modules.d/90crypt/module-setup.sh @@ -47,7 +47,7 @@ install() { inst_hook cmdline 10 "$moddir/parse-keydev.sh" inst_hook cmdline 30 "$moddir/parse-crypt.sh" inst_hook cleanup 30 "$moddir/crypt-cleanup.sh" - inst_simple /etc/crypttab + [[ $hostonly ]] && inst_simple /etc/crypttab inst_simple "$moddir/crypt-lib.sh" "/lib/dracut-crypt-lib.sh" dracut_install -o \
My workaround to fix this issue was to do this: # cat /etc/dracut.conf.d/99-mypwfile.conf install_items="/etc/<my_password_file> /etc/crypttab" After doing that both my passphrase file and /etc/crypttab were copied into the initrd. Hopefully that helps someone else who runs into this.