Mailinglist Archive: opensuse (1108 mails)

< Previous Next >
Re: [opensuse] Booting with an encrypted home
On 2018-08-07 21:33, Andrei Borzenkov wrote:
07.08.2018 11:52, Carlos E. R. пишет:


On one machine (Leap 42.3) with encrypted home, when it boots and I'm
not there it waits forever at the password prompt (not using plymouth).

By default systemd service that decrypts container has no timeout. You
can change it in /etc/crypttab using timeout= option.

In Leap 42.3 it is as you say. In Leap 15.0 it has a 90 seconds timeout
and can not be changed by that setting.

No, I tried and the setting is ignored. Worse, it causes to be
impossible to type the password, the keyboard doesn't work. I have been
trying for hours.

All these lines make the system unbootable:

cr_sda8 UUID=1edf494d-d697-40b2-ba00-c7da0a1d5fbe - timeout=0
cr_sda8 /dev/disk/by-uuid/1edf494d-d697-40b2-ba00-c7da0a1d5fbe -
cr_sda8 /dev/sda8 - timeout=0
cr_sda8 /dev/sda8 none timeout=0

Only these work, with a time out of 90 seconds, unchangeable:

cr_sda8 /dev/sda8
cr_sda8 UUID=1edf494d-d697-40b2-ba00-c7da0a1d5fbe
cr_sda8 UUID=1edf494d-d697-40b2-ba00-c7da0a1d5fbe none none

This other line:

cr_sda8 UUID=1edf494d-d697-40b2-ba00-c7da0a1d5fbe none timeout=300

is accepted, but the prompt text changes (doesn't print the timeout) and
the timeout doesn't change.

Some more details on the post I just sent.

As it acts as my home server, this is incovenient:


cr_home /dev/disk/by-id/ata-KINGSTON... none none


/dev/mapper/cr_home /home xfs lazytime,exec,nofail 1 2

On another machine (a laptop wit 15.0) if I don't type the password fast
enough it goes into emergency mode, prompting me to repair or pressing
control-D. It doesn't even wait 3 minutes:


cr_sda8 /dev/sda8


LABEL=Home /home xfs lazytime 0 1

The difference is that in the former case systemd actually knows device
name (/dev/mapper/cr_home) and this device name has explicit dependency
on systemd-cryptsetup service which means job to mount filesystem is not
even started.

Actually, system stops at the password prompt for ever, thus it is
impossible to do a remote reboot.

While in the latter case there is no connection between
LABEL=Home and encrypted container (you need to decrypt it first to know
label) so mount job is started in parallel to decrypt job, times out and
triggers emergency mode.


But then the emergency mode prompt refuses to read my root password if I
wrote "timeout=0". I had to boot another partition in order to edit file
and try again.

If you use same configuration in both case they
also behave identically (i.e. Leap 15 will wait indefinitely just as well).

I'll try.

/dev/mapper/cr_sda8 /home xfs lazytime 0 1

cr_sda8 UUID=1edf494d-d697-40b2-ba00-c7da0a1d5fbe none none

Typing password accepted. Prompt doesn't print a timeout. [...] It is
still waiting there as I type this email, minutes later. So this works.


I don't know how to control these timings decissions.

timeout= option in /etc/crypttab. Sometimes I wonder why people even
bother to write manual pages if nobody reads them anyway ...

Because I thought it would be controlled in some more obscure way. And
anyway, the manual is wrong, timeout=0 crashes my system boot.

I now try:

/dev/mapper/cr_sda8 /home xfs lazytime 0 1

cr_sda8 UUID=1edf494d-d697-40b2-ba00-c7da0a1d5fbe none timeout=300

It doesn't print the timeout. If I press "enter" on the prompt it then
prints that the timeout is "no limit". Despite this, it times out at an
indeterminate time (I did not use a chronometer and the screen does not
say) but might be the 300 seconds I wrote.

The setting "timeout= " doesn't work as documented.

Note that is does not work with Plymouth.

I never use plymouth, it is removed on every install I do :-)

Passphrase query screen
remains stuck and neither X11 GUI appears nor can I switch to text login
(I just get empty terminal). I believe this is plymouth bug - there is
job to stop plymouth at the end of boot sequence and it has infinite
timeout and it probably fails to properly stop plymouth in this state.

On your next post:

On 2018-08-08 06:28, Andrei Borzenkov wrote:
07.08.2018 22:33, Andrei Borzenkov пишет:
07.08.2018 11:52, Carlos E. R. пишет:


It was not quite correct. systemd cryptsetup generator explicitly
disables start timeout for /dev/mapper/<device name>, so in the former
case it waits indefinitely for device to appear. In the latter case it
times out waiting for device with LABEL=Home because this device has no
connection to /dev/mapper/cr_sda8 (no way to scan for labels before it
is decrypted).

Yes, this matches my experiments.

Thus, by using or not /dev/mapper/path I can set infinite timeout or 90
second timeout.


Huh, no, one of my experiments timed out differently. See above.

Cheers / Saludos,

Carlos E. R.
(from 42.3 x86_64 "Malachite" at Telcontar)

< Previous Next >
Follow Ups