Usually I am booting my workstation directly and enter the gpg`s passphrase manually. But when booted by Wake On Lan`s magic packet it becomes a problem - it blocks the booting proces, and I do not want to mess with boot order (esp. if encrypted drives are mounted by localmount script which is far,far away from sshd/net scripts). Attached patch adds two conf.d/dmcrypt params per target: - noninterrupted_boot a) yes - user is asked to confirm (striking any key will suffice) whether he wants to enter the password. After read_timeout seconds dialogs times out and boot process continues b) no - old behaviour - this is the default - read_timeout - amount of time to wait in seconds for user input. Default is 1 s. Reproducible: Always Steps to Reproduce: 1. setup the /home mapping with gpg encrypted key 2. reboot 3. try to log on via ssh Actual Results: SSH and network is not set up. System is waiting indefinatelly for input Expected Results: Let the user decide whether he needs his server to wait for input or just continue booting after specified amount of time
Created attachment 264763 [details, diff] Patch adding noninterrupted_boot and read_timeout parameters to the /etc/conf.d/dmcrypt file Forgot to attach the patch :)
Created attachment 264775 [details, diff] Patch adding noninterrupted_boot and read_timeout parameters to the /etc/conf.d/dmcrypt file, now without errors. I have attached wrong file - it had two bugs. Now it should be OK.
why cant you use the option that already exists ? # Max number of checks to perform (1 per second) #dmcrypt_max_timeout=120
(In reply to comment #3) > why cant you use the option that already exists ? > > # Max number of checks to perform (1 per second) > #dmcrypt_max_timeout=120 > Because currently I do not store the key on a removable device, and section using this variable is executed only if "$remdev" is defined. What is more, if you forget to take your key with you this will not work and pinentry will block your PC. My intention was to make it more flexible, but of course I am open to a discussion :)
the intention was for the variable to apply to all timeouts, not just removable. so the existing variable should be extended/unified.
OK, I got your point. But IMHO we still should allow people to choose: either they are not using WakeOnLan and we let the pinentry wait for the passphrase indefinatelly (this way nobody will miss it and though will have to unlock the device manually), or they need the system to boot eventually and they set noninterrupted_boot=yes. If you find my proposition reasonable, I will implement your suggestion to the patch.
WOL is irrelevant to the issue. any remote system will have the same issue. with the variable i mentioned, you already have the ability to make it wait practically indefinitely: set it to 10000000 or something even larger.
should be all set now in the tree; thanks for the report! Commit message: Adapt the timeout logic to apply to the gpg command too http://sources.gentoo.org/sys-fs/cryptsetup/cryptsetup-1.6.7.ebuild?rev=1.1 http://sources.gentoo.org/sys-fs/cryptsetup/files/1.6.7-dmcrypt.confd?rev=1.1 http://sources.gentoo.org/sys-fs/cryptsetup/files/1.6.7-dmcrypt.rc?rev=1.1
