I've got baselayout-2.0.0 and openrc-0.3.0-r1; my /home is encrypted with dmcrypt and dmcrypt is in the "boot" runlevel. Without parallel startup, the boot sequence stops when I am asked to enter the dmcrypt password. With parallel startup, after I'm asked for the password, I get dozens of "service XXX is waiting for dmcrypt", which while technically correct completely hide the password prompt. This isn't a serious problem, since I can type my password even without prompt, but it is a glitch nonetheless. Expected behaviour: password prompt, and in general any service script requiring user interaction, should not be cluttered by the messages of other services.
If you give the dmcrypt init script the notimeout keyword and apply the OpenRC patch found on bug #247036 this should fix the issue. Yes?
I upgraded to openrc-0.4.3-r1 and I modified /etc/conf.d/dmcrypt as following: options='notimeout' swap=crypt-swap source=/dev/sda4 target=crypt-data source=/dev/sda3 The problem DOES persist.
I Want to suggest to improve the gpg-encrypted key example in /etc/conf.d/dmcrypt by adding gpg_options='--homedir /root/.gnupg --no-tty --decrypt --quiet' By this way, you'll get the pinentry for the passphrase of the corresponding gpg-key to decrypt the dmsetup secret. my config looks like target=home source='/dev/disk/by-id/ata-HITACHI_HTS541612J9SA00_3H_....-part7' options='--cipher aes-plain' key='/root/.gnupg/home.key:gpg' # the encrypted secret for cryptsetup gpg_options='--homedir /root/.gnupg --no-tty --decrypt --quiet' ok, the encrypted secret and the decryption key on the hard disk, secured by only a passphrase is only weak compromise, but compared to the gpg-less key mode, you can switch the interactive supplied passphrase without reencrypt the whole partition. my 2 cents
background addition to comment 3, without the --homedir, gpg searches in /.gnupg vor the keyring and without the --no-tty, you'll geht an "no such device" from the kernel.
