Hi!
In the openSUSE 12.1 installation I chose to encrypt the whole home partition. So I have to input a password at every boot process. The problem is, that there is a timeout (few minutes) for the password entry. If I don’t input a password in that time, the boot process continues automatically (of course without mounting the home partition) to the user login screen (KDM).
How can I disable this timeout so that the password prompt waits forever?
Regards,
endym
On 2012-02-22 13:36, endym wrote:
> How can I disable this timeout so that the password prompt waits
> forever?
I think you have to find how in “/etc/init.d/boot.crypto”.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
It is probably better to leave the timeout there. Or, at least, that was my decision.
If it booted with the timeout, and you know the root password, you can use “cryptsetup” to provide the password, and then manually mount “/home”. Or you could reboot.
I am currently using an encrypted LVM. And I don’t think there’s a timeout with that. The crypto is done earlier in the boot cycle, and the prompt for password is less likely to be hidden among other messages.
@nrickert
Leaving the timeout enabled is not an option for me, because it is a family notebook. It happens quit often, that someone switch on the notebook and go away to do something else. After coming back the user login screen is shown (without mounted home partition) and the trouble starts… In my opinion this behavior is very confusing for an average user! And doing a reboot in this case is very frustrating too.
@robin_listas
I have found the mount option “timeout=<sec>” (see “man crypttab”) and have changed the fourth parameter in “/etc/crypttab” from none to timeout=0. Unfortunately this does not solve the problem.
I think your hint with “/etc/init.d/boot.crypto” points to the right direction. The init script exists (and works), but with 12.1 the old init system SysV was replaced by systemd, so the appropriate services are now “crypto-early.service” and “crypto.service” in “/lib/systemd/system/”. The command
systemctl show crypto-early.service
lists the properties of the unit, amongst others the property TimeoutUSec=1min 30s. I have measured 120s, but anyhow, it sounds very interesting…
Now I have to find out how to modify these properties, but not today.
So long
endym
On 2012-02-22 23:06, endym wrote:
@robin_listas
> I have found the mount option “timeout=<sec>” (see “man crypttab”) and
> have changed the fourth parameter in “/etc/crypttab” from -none- to
> -timeout=0-. Unfortunately this does not solve the problem.
Ah.
> I think your hint with “/etc/init.d/boot.crypto” points to the right
> direction. The init script exists (and works), but with 12.1 the old
> init system SysV was replaced by systemd, so the appropriate services
> are now “crypto-early.service” and “crypto.service” in
> “/lib/systemd/system/”.
Yes, systemd is a complication, I did not mention it. I know too little
about it to be of help. I simply hoped that systemd in the end calls the
script, which has been polished a lot. It is an openSUSE feature.
Those services you mention, in my 12.1 test system are symlinks to
/dev/null :-?
> Now I have to find out how to modify these properties, but not today.
I’ll be interested in learning your progress 
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
You are right, the two crypto-services are symlinks to /dev/null. Until now I’m not sure, if systemd or SysV are responsible. I tried some modifications in “/lib/cryptsetup/boot.crypto.functions”, which is included in “/etc/init.d/boot.crypto-early” - without success.
When the timeout occurs, the message log shows this entry: “systemd[1]: Job dev-mapper-cr_sdb3.device/start timed out.”. So systemd after all?
By the way, the timeout is 1min 20s, not 120s as I mentioned before.
On 2012-02-23 23:26, endym wrote:
>
> You are right, the two crypto-services are symlinks to /dev/null. Until
> now I’m not sure, if systemd or SysV are responsible. I tried some
> modifications in “/lib/cryptsetup/boot.crypto.functions”, which is
> included in “/etc/init.d/boot.crypto-early” - without success.
> When the timeout occurs, the message log shows this entry:
> “-systemd[1]: Job dev-mapper-cr_sdb3.device/start timed out.-”. So
> systemd after all?
Systemd can call systemv scripts when the service has not been ported, I
understand (I don’t know the exact mechanism). But it still controls things.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
On 2012-02-23 23:48, Carlos E. R. wrote:
> On 2012-02-23 23:26, endym wrote:
> Systemd can call systemv scripts when the service has not been ported, I
> understand (I don’t know the exact mechanism). But it still controls things.
I’m looking a bit on 11.4. The boot script calls
“/lib/cryptsetup/boot.crypto.functions”, and this has two references to the
word “timeout”, one lowercase, the other uppercase. And it is assigned the
value “120” precisely. You can try increasing the value to something absurd
like 6000.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
“/lib/cryptsetup/boot.crypto.functions”, and this has two references to the
word “timeout”, one lowercase, the other uppercase. And it is assigned the
value “120” precisely.
The value 120s is not that, what I have measured: 1min 20s. It looks similar only…
Nevertheless it was exactly, what I have tried. I changed “TIMEOUT=120” to “TIMEOUT=0”. Unfortunately it makes no difference.
I have fiddled around with systemd services and the command “systemctl show cryptsetup@cr_sdb3.service” gives some more information:
Id=cryptsetup@cr_sdb3.service
Names=cryptsetup@cr_sdb3.service
Requires=systemd-stdout-syslog-bridge.socket
BindTo=dev-disk-by\x2did-ata\x2dWDC_WD2500BEVS\x2d60UST0_WD\x2dWXE808P0A960\x2dpart3.device dev-mapper-cr_sdb3.device
RequiredBy=cryptsetup.target dev-mapper-cr_sdb3.device
...
ConditionTimestamp=Sun, 26 Feb 2012 15:21:22 +0100
...
ExecStart={ path=/lib/systemd/systemd-cryptsetup ; argv]=/lib/systemd/systemd-cryptsetup attach cr_sdb3 /dev/disk/by-id/ata-WDC_WD2500BEVS-60UST0_WD-WXE808P0A960-part3 none none ; ignore_errors=no ; start_time=[n/a] ; stop_time=[Sun, 26 Feb 2012 15:22:52 +0100] ; pid=1993 ; code=exited ; status=1 }
...
The service was started at 15:21:22 and the start command “ExecStart={ path=/lib/systemd/systemd-cryptsetup” has the parameter “stop_time=[Sun, 26 Feb 2012 [b]15:22:52 +0100]” which are 1min 30s difference. Not far away from 1min 20s…
The start command /lib/systemd/systemd-cryptsetup is a binary file, so no chance to filter out the stop_time parameter there. The service cryptsetup@cr_sdb3.service is not a static file which can be edited, but a dynamic generated file on every boot. So the question is, who generates the service?
It’s a quite complex issue so I think an openSUSE systemd expert is needed. Does anybody know one? Maybe it’s a good idea to file a bug report, but on the other side it is not really a bug, more a miss configuration - at least for me.
Regards,
endym
Hi,
180 sec is the default timeout for most systemd units.
The files /run/systemd/generator/cryptseutp@blabla.service are indeed created at boot up. This is done by /lib/systemd/generator/systemd-cryptsetup-generator, which appearently parses /etc/crypttab, but ignores the timeout option. I would consider this a bug, since timeout is properly documented in the crypttab manpage.
Sadly, the config files in /run/systemd/generator override those in /etc/systemd/system. You can try to copy the .service file from /run/systemd/generator to /etc/systemd/system, add an appropriate timeout option, and hope that the cryptsetup-generator realizes that it should not recreated the /run/…-file at the next boot since it is already present in /etc/… . But I doubt it.
If anyone finds a usefull documentation of systemd-cryptsetup-generator or of the generator-protocol in general, please tell us. I’m also having some trouble with this mechanism.
I have two solutions to offer.
You can comment out your crypttab line (add #). Then put a cryptsetup@bla.service file to /etc/systemd/system and change the settings to your needs. Use the /run/systemd/generator/cryptsetup@bla.service file as template. Without that line in crypttab, the generator should not create a competing file. You might have to copy additional files/settings from the /run/…/generator directory, such as .wants-directories or .device files. I’m not sure about that, just try.
Alternatively, follow the idea of nrickert. You don’t have to create an LVM for that. Do this as root
$ mkinitrd -f luks
This will recreate your initrd and add luks-at-bootup support to it. Then add “luks=cr_sdb3 luks_cr_sdb3=/dev/disk/by-id/ata-WDC_WD2500BEVS-60UST0_WD-WXE808P0A960-part3” to your kernel command line in /boot/grub/menu.lst (I assume you don’t have any other encrypted partitions). This will make your initrd ask you for the luks passphrase at bootup (before systemd even starts). You can add the kernel command line somewhere in /etc/sysconfig/bootloader (I think it’s the DEFAULT_APPEND variable), so it does not get removed when grub or kernel or whatever get updated. Unfortunatelly, the luks support /will/ get removed from the initrd at kernel update, so you will have to run the quoted command again when this happens. I hope there is no timeout in the initrd luks module.
Yarny
P.S.: Third idea: Just add ‘initrd’ to the option list in your crypttab. ‘man crypttab’ says this will make the initrd unlock the device at bootup. Then you can just call ‘mkinitrd’ and it should take care of everything; no need to add kernel command line options or calling mkinitrd again after each kernel update. – Yarny
Yarny,
many thanks for your ideas!
First I tried your first suggestion: I commented out the line in “/etc/crypttab” and copied all entries of “/run/systemd/generator” to “/etc/systemd/system”. No success.
But your third suggestion was a hit! I added the option “initrd” in “/etc/crypttab”
cr_sdb3 /dev/disk/by-id/ata-WDC_WD2500BEVS-60UST0_WD-WXE808P0A960-part3 none initrd
and run “mkinitrd” as root in the console. The password prompt appears earlier now (before systemd starts as you told). After the first restart I waited more than 5min - no timeout!
So, for me this issue is solved now. Nevertheless I will file a bug report to openSUSE, because of ignoring the timeout parameter in “/etc/crypttab”.
Thanks to all!
endym
On 2012-02-27 22:56, endym wrote:
> Thanks to all!
Welcome! Don’t forget to put the number of the bugzilla here, so that
people searching here in times to come can find the reference.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)