Mailinglist Archive: opensuse (1108 mails)

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


Hi,

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.


Both behave identically if configured identically. You compare apples
and oranges.

Maybe. I have not done exhaustive testing on 42.3.


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 -
timeout=0
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

I have no idea what does it mean. What prompt you are talking about,
when it appears etc.

The prompt to enter the crypto password when booting, without plymouth
installed.


This prompt never "printed timeout" so I still do not understand what
you mean.



...


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


"Crashes" what? Kernel? Systemd? What you write makes no sense.


It was detailed on another post in this same thread.

When I use "timeout=0" combined with

timeout=0 is default anyway, so is redundant.


/etc/fstab:

LABEL=Home /home xfs lazytime 0 1


then the prompt to ask the crypto password does not accept any text
entry. After 90 seconds, thus ignoring the timeout, it goes into
emergency mode,

That is not "crash".

which asks for my root password but also refuses to
accept any text. Ctrl-D is not accepted, only ctrl-alt-supr works; I
then boot a different partition, and in that auxiliary system I edit the
main system /etc/crypttab to try again. All the tests I did are
detailed in the other post I mentioned.


Yes, I have seen this too. We are left with two processes competing for
console - passphrase query (which waits indefinitely) and emergency
shell. Feel free to open bug report.

It still is not "crash". "Crashed" means "program or kernel stopped
execution unintentionally".


I now try:

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

/etc/crypttab:
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.


It *does* timeout after number of seconds specified in timeout= option.

I'm testing this again. The clock says 23:04, it should time out at 23:09.

When it is waiting, if I press enter I get a message saying that a
startup job is waiting and that there is no time limit - which is false:
at almost 23:09 it went into emergency mode.



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


It does, even if you misinterpret what you see.

No. timeout=0 locks me out of the system. The password can not be typed.


This is entirely different problem. Even in this case "timeout=0" works
as documented by disabling timeout and waiting for passphrase input
indefinitely. That it conflicts with emergency mode is unfortunate bug.


Anyway, there was no "press ENTER" in your original question. You wanted
passhrase request to timeout after some time to allow boot to continue.
That is exactly what option timeout= does. If you need something
different, you forgot to describe it.

I wanted the situation reversed on both machines, and I got that. Kind
of. timeout=0 crashes or locks or whatever the system. I can not enter.


If you insist on using configuration that cannot work due to (arguably,
limitations of) systemd design, it is up to you. To properly track
dependencies systemd absolutely needs /dev/mapper/<crypto-container> in
/etc/fstab.



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


Those are two entirely different timeouts in two entirely different
places. You again mix apples and oranges.

Maybe, but I got it working that way :-)


Nice. My test systems wait for exactly timeout= seconds (tried several
values from 10 to 120 seconds) and then boot normally without encrypted
filesystem if passphrase was not provided. But I readily admit I
misunderstood you and this is not what you wanted.

< Previous Next >
Follow Ups