[opensuse] Booting with an encrypted home
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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). As it acts as my home server, this is incovenient: /etc/crypttab: cr_home /dev/disk/by-id/ata-KINGSTON... none none /etc/fstab: /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: /etc/crypttab: cr_sda8 /dev/sda8 /etc/fstab: LABEL=Home /home xfs lazytime 0 1 Now, I would like to change things. I would prefer the first machine to boot anyway after, say, 5 minutes. And the same for the laptop. Another option would be to have the laptop wait forever. The rationale for the first one, the server, is that I might ssh as root or as plain user with home defined to somewhere different than /home, and enter the encryption password remotely. The rationale for the second one is that I boot it and I go look somewhere else; when I look again it is at the ^D prompt and I have to ctrl-alt-supr to retry. It is inconvenient, it waits too little time. I don't know how to control these timings decissions. - -- Cheers Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAltpXd4ACgkQtTMYHG2NR9XYCwCfVFat3KrYIeisWtpLta3wOxtG G/MAnjQDQfvYR1X1k05+qhLrpN0geOTd =BueO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/07/2018 03:52 AM, Carlos E. R. wrote:
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). As it acts as my home server, this is incovenient:
The best way to handle that seems to be using an ecryptfs home directory. That way, "/home" is not encrypted but your home directory and content is encrypted. So the system can boot unattended, and your home directory is decrypted when you next login. When I last did this, I kept my ".ssh" directory elsewhere, and used symlinks so that ".ssh" showed up in my home directory whether or not unlocked. That way I could login over ssh with public key authentication, and then unlock the home directory (using my login password). -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEv7/MJoKYXv2p0PaIZJcsjNEnCIUFAltpn/IACgkQZJcsjNEn CIU6ygf+OB3BYoOBPCJ669uYB9nCuBQ76RT9BgtheE5axv8AUXNCpPwlK0PVIlLC 2g/KQeaZeZXOOkxibS7SoO/74ma2F1jlrtSvvldNSn9thQOicmWGMmG3sNSknwCf j7fZ0xrrlvT2aG/qW1VC6/Pv67oNn/tJRDmLCSR4dMZaHQAk1j0cSuQM0Wt/DSGI iP5aX4yWYprnmeV+Bsy8fLvoAD5bOuwKRCegadQpsfpGKWy2RjXiiLRrpNoa0E8X sf1rWiR4AeQXs8oo9NtExWxcUMNHAHyHvIAm4PlthIM0aq8Jo9zbr8xkSc+EUXv4 0j2N/2fFz0bmm0kkXXGh8FhXLkFEAQ== =wkVm -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/07/2018 09:34 AM, Neil Rickert wrote:
When I last did this, I kept my ".ssh" directory elsewhere, and used symlinks so that ".ssh" showed up in my home directory whether or not unlocked. That way I could login over ssh with public key authentication, and then unlock the home directory (using my login password).
Wouldn't this cause problems if, when /home/ is mounted, Carlos might try to read ~/.ssh ... I mean the directory and files would *not* be encrypted, but encryptfs -- and so then also the system -- would act (or try to act) as if that directory and its files *were* encrypted. What happens then? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/07/2018 10:17 AM, ken wrote:
Wouldn't this cause problems if, when /home/ is mounted, Carlos might try to read ~/.ssh ... I mean the directory and files would *not* be encrypted, but encryptfs -- and so then also the system -- would act (or try to act) as if that directory and its files *were* encrypted. What happens then?
It doesn't work that way. The home partition is not itself encrypted. So "/home" can be mounted during boot without needing a password. A user owns two directories there: "/home/user" and "/home/.ecryptfs/user". There is a subdirectory "/home/.ecryptfs/user/.Private" which contains the encrypted version of the user home directory. When that is unlocked, the decrypted version is mounted on top of "/home/user". The idea is to put ".ssh" in "/home/.ecryptfs/user" and have a symlink to it in "/home/user" which will be what you see when the encrypted directory is not unlocked. And then you need another symlink that is put there when the encrypted directory is unlocked. That second symlink is only visible with the encrypted directory is unlocked. And, of course, there is an encrypted version of that symlink in "/home/.ecryptfs/user/.Private/". As long as mount and umount are atomic operations, ".ssh" will always be available, though which of those symlinks it follows will depend. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEv7/MJoKYXv2p0PaIZJcsjNEnCIUFAltp5fMACgkQZJcsjNEn CIUwCQf+LNkUmOadKLkXosoAb8j9uDG61F5WcuwgkhuYh2J80JsHWjkF/VBQ5oPB fXWf/Hut1R+wQuipU8SaxdD8LyWBkEynOGoA5zJKODO4/EkxTGl/k4xv+XjDZ7Uj FK8Mh2WzWpjq8aoblQ/Iy05naZxbtkwfMYD7Q8gvGz5+PpFzZfV2H0POAiNZAKDt ShnDrGY3TCV5gfdnBdwTqSUj2FtOC2dO5l6Z16LyawccTtYXmkbt8TAjyLzj0D16 NVVmm6C6yhd+3/C48ChF3CITastaX8mqxXVLZWq7KWEOqRxgw1N4iSI6eSj5+9TV 6FqHvHq2yBeh+duI1MJjRoBKTJTnPw== =NwKM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/07/2018 02:33 PM, Neil Rickert wrote:
A user owns two directories there: "/home/user" and "/home/.ecryptfs/user". There is a subdirectory "/home/.ecryptfs/user/.Private" which contains the encrypted version of the user home directory. When that is unlocked, the decrypted version is mounted on top of "/home/user".
The idea is to put ".ssh" in "/home/.ecryptfs/user" and have a symlink to it in "/home/user" which will be what you see when the encrypted directory is not unlocked. And then you need another symlink that is put there when the encrypted directory is unlocked. That second symlink is only visible with the encrypted directory is unlocked. And, of course, there is an encrypted version of that symlink in "/home/.ecryptfs/user/.Private/".
Neil, Thanks for the additional details. Some of the process is much clearer with them. But there must be a lot more magic to it, because, as given, there are still theoretical gaps in the functioning of the files and symlinks. For instance, if I have encrypted files in /home/.encryptfs/user/.ssh/ and then a symlink from that directory to /home/user/, prior to the former being decrypted, I should not be able to read the files there. Just creating a symlink to an encrypted directory does not decrypt it and its files. So I don't see how it would be possible to remotely log into such a system, being that ~/.ssh (the symlink) would point to an encrypted directory. As well, I'm not understanding the endpoints of the second symlink. It's created after /home/.encryptfs/user/ is decrypted (and mounted), yes? What would be the command to create that symlink then? If I can sufficiently understand encryptfs, as you seem to do, then it would be a really nice solution to an issue I'm looking at. Thanks much. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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.
As it acts as my home server, this is incovenient:
/etc/crypttab:
cr_home /dev/disk/by-id/ata-KINGSTON... none none
/etc/fstab:
/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:
/etc/crypttab:
cr_sda8 /dev/sda8
/etc/fstab:
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. 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. If you use same configuration in both case they also behave identically (i.e. Leap 15 will wait indefinitely just as well). ...>
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 ... Note that is does not work with Plymouth. 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.
07.08.2018 22:33, Andrei Borzenkov пишет:
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.
As it acts as my home server, this is incovenient:
/etc/crypttab:
cr_home /dev/disk/by-id/ata-KINGSTON... none none
/etc/fstab:
/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:
/etc/crypttab:
cr_sda8 /dev/sda8
/etc/fstab:
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. 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. If you use same configuration in both case they also behave identically (i.e. Leap 15 will wait indefinitely just as well).
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).
...>
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 ...
Note that is does not work with Plymouth. 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 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. 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 the timeout doesn't change. Some more details on the post I just sent.
As it acts as my home server, this is incovenient:
/etc/crypttab:
cr_home /dev/disk/by-id/ata-KINGSTON... none none
/etc/fstab:
/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:
/etc/crypttab:
cr_sda8 /dev/sda8
/etc/fstab:
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.
Right. 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. fstab: /dev/mapper/cr_sda8 /home xfs lazytime 0 1 /etc/crypttab: 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: 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. 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)
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.
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. ...
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.
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.
The setting "timeout= " doesn't work as documented.
It does, even if you misinterpret what you see. 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.
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.
[...]
Huh, no, one of my experiments timed out differently. See above.
Well, my experiments work exactly as you wanted. So either you do not describe your situation with enough details or you actually want something different than you described.
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.
...
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 /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, 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.
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.
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.
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 :-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
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.
On 2018-08-09 06:04, Andrei Borzenkov wrote:
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.
Sometimes it does, sometimes there is another line that prints it. I can take photos.
...
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.
Well, it is not, not here. It is 90 seconds when fstab has: /etc/fstab: LABEL=Home /home xfs lazytime 0 1
/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".
Call it what you wish :-)
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".
Well, boot process 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.
I don't know if it conflicts. What I see is that I can not type the partition password, and that later when it times out at 90 seconds I can not type the root password. That's the symptoms. What is the cause (a conflict) I have no idea.
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.
I currently have, in one machine (laptop): fstab: /dev/mapper/cr_sda8 /home xfs lazytime 0 1 crypttab: cr_sda8 UUID=1edf494d-....... none timeout=300 which is working. I initially wanted "timeout=0" but that is impossible as it locks me out of the system. Or it did with the initial fstab entry. The initial setting: LABEL=Home /home xfs lazytime 0 1 was written by YaST, I believe, as I did not know it was possible. I think it happened because at install time I specified I wanted (for all partitions) that I wanted mount by label instead of the default which is mount by uuid (at the bottom of the yast display when looking at a disk), and then I wrote a label for the encrypted partition. On another machine, the home server, I have written: fstab: /dev/mapper/cr_home /home xfs lazytime,exec,nofail 1 2 /dev/mapper/cr_hoard2 /data xfs user,lazytime,exec,nofail 1 2 crypttab: #cr_home /dev/disk/by-id/ata-KINGSTON...part5 none none cr_home /dev/disk/by-id/ata-KINGSTON...part5 none timeout=300 cr_data /dev/disk/by-uuid/24f77e... /home/cer/Keys/the_data_key auto which I will test as soon as I can reboot it, after some updates. The doubt is what will happen with the other encrypted partitions that have the key on a file - do they need setting a timeout, or will they be ignored as the path to the keyfile was not mounted? Thank you, I have got what I needed with your help :-) -- Cheers / Saludos, Carlos E. R. (from 42.3 x86_64 "Malachite" at Telcontar)
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
ken -
Neil Rickert