[Bug 909912] New: install with encrypted partition lacks timeout parameter
http://bugzilla.suse.com/show_bug.cgi?id=909912 Bug ID: 909912 Summary: install with encrypted partition lacks timeout parameter Classification: openSUSE Product: openSUSE Factory Version: 201412* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening@forge.provo.novell.com Reporter: ohering@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Created attachment 617054 --> http://bugzilla.suse.com/attachment.cgi?id=617054&action=edit boot-failure-1.jpg A fresh install which includes an encrypted partition does not include a timeout= parameter in crypttab (Not sure if thats the actual cause here!). The result is that one is FORCED to pay attention to the boot process to quickly enter the passphrase. Otherwise the user is presented with a black screen and geeky output. I wonder what the value is to not just sit there and wait forever for a passphrase, instead of enter failing state as its done now... If one grabs a translator to decode whats printend on the screen, ctrl D will not actually help. It asks for the password for a few seconds, then the bootsplash is started again. Nothing happens during that time. After a while the same geek screen is shown. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
--- Comment #1 from Olaf Hering
http://bugzilla.suse.com/show_bug.cgi?id=909912
--- Comment #2 from Olaf Hering
http://bugzilla.suse.com/show_bug.cgi?id=909912
--- Comment #3 from Olaf Hering
http://bugzilla.suse.com/show_bug.cgi?id=909912
--- Comment #5 from Olaf Hering
before systemd, a timeout would just let the boot continue without the crypted partition mounted (giving you a chance to mount it over ssh). maybe to get a similar behaviour now, try the "nofail" mount option
How would one enter anything via ssh? I'm sure the system just stops booting way before network is available. Looks like timeout=0 + nofail shows the graphical prompt longer. Still, why is that not the default? The current way of handle encrypted stuff appears to be very unfriendly, even if its done that way since forever... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
--- Comment #6 from Olaf Hering
Looks like timeout=0 + nofail shows the graphical prompt longer.
Unrelated to this bug: If one really wants to proceed, three attempts to enter passphrase do not result in "success" for the generated $mnt.service files. Instead systemd still waits for the mount (or whatever) to appear. Fortunately this time with a timeout of maybe 90 seconds. I think failed passphrase should mark the mount point as available because otherwise something still asks for the passphrase in the background (according to the screen shown by the ESC key)… -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
Arvin Schnell
http://bugzilla.suse.com/show_bug.cgi?id=909912
Arvin Schnell
http://bugzilla.suse.com/show_bug.cgi?id=909912
Olaf Hering
On a openSUSE 13.2 installation the boot process seems to wait forever when asking for the passphrase. Please check whether you can confirm that (a change from 13.2 to factory).
I cant, this system has Factory installed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
--- Comment #10 from Olaf Hering
But you can install a system with openSUSE 13.2.
Yes, I found some spare room in the LVM volume for a 13.2 test system. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
Olaf Hering
On a openSUSE 13.2 installation the boot process seems to wait forever when asking for the passphrase. Please check whether you can confirm that (a change from 13.2 to factory).
At least when booting a fresh 13.2 with empty /proc/cmdline the booting will enter failure state once the ask-for-passphrase on text console times out. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
Arvin Schnell
http://bugzilla.suse.com/show_bug.cgi?id=909912
--- Comment #13 from Olaf Hering
http://bugzilla.suse.com/show_bug.cgi?id=909912
--- Comment #14 from Olaf Hering
http://bugzilla.suse.com/show_bug.cgi?id=909912
--- Comment #15 from Olaf Hering
For me the passphrase query does not time out (and is not text console but graphical).
Is this encrypted lvm or encrypted filesystem? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
Chenzi Cao
http://bugzilla.suse.com/show_bug.cgi?id=909912
Thomas Blume
Looks like timeout=0 + nofail shows the graphical prompt longer.
Still, why is that not the default? The current way of handle encrypted stuff appears to be very unfriendly, even if its done that way since forever...
Hm, but timeout=0 is already the default (see man crypttab): -->-- timeout= Specifies the timeout for querying for a password. If no unit is specified, seconds is used. Supported units are s, ms, us, min, h, d. A timeout of 0 waits indefinitely (which is the default). --<-- You refer to the 'nofail' mount option then? This should be covered by: https://fate.suse.com/319069 (see bug 926330 for details) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c18
--- Comment #18 from Olaf Hering
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c19
--- Comment #19 from Olaf Hering
Fresh tumbleweed install. Bug still exists.
tweaking crypttab does not change anything. even with 'timeout=0' something still has a hard timeout. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c20
--- Comment #20 from Olaf Hering
(In reply to Olaf Hering from comment #18)
Fresh tumbleweed install. Bug still exists.
tweaking crypttab does not change anything. even with 'timeout=0' something still has a hard timeout.
Poking further at this, man crypttab lists a systemd option, which is also ignored: encrypted_lvm \ /dev/disk/by-uuid/8d95b6eb-1dc4-44f8-8883-76fbf70e5fb0 \ none \ x-systemd.device-timeout=12 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c21
--- Comment #21 from Olaf Hering
x-systemd.device-timeout=12
This option has to go into fstab. I think what happens is that one branch processes crypttab and another fstab. There is no connection between both. Even if the timeout paramemter for crypttab would be processed, the other branch for fstab waits for the entry to appear. Since it has no idea what the backing device is it times out. Both seem to lack the concept of "wait forever". So the workaround is to append "x-systemd.device-timeout=1234567890h" to all the mount options in fstab for devices backed by crypttab entries. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c22
--- Comment #22 from Olaf Hering
So the workaround is to append "x-systemd.device-timeout=1234567890h" to all the mount options in fstab for devices backed by crypttab entries.
This variant has the drawback that the branch which waits for the fstab entry will wait for the specified time. If the branch which retrieves the passphrase exits without providing a passphrase (or whatever it does) then the fstab branch will continue to wait. Either the fstab branch should be made aware that it waits for crypt, or the crypt branch terminates the remaining fstab branches. Looks like crypt handling isnt well designed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c23
--- Comment #23 from Thomas Blume
(In reply to Olaf Hering from comment #20)
x-systemd.device-timeout=12
This option has to go into fstab.
I think what happens is that one branch processes crypttab and another fstab. There is no connection between both. Even if the timeout paramemter for crypttab would be processed, the other branch for fstab waits for the entry to appear. Since it has no idea what the backing device is it times out.
Both seem to lack the concept of "wait forever".
So the workaround is to append "x-systemd.device-timeout=1234567890h" to all the mount options in fstab for devices backed by crypttab entries.
Yes, you need: timeout=0 in crypttab for the crypt device and x-systemd-device-timeout=0 in fstab for the backing device in order to suppress the timeouts. Reason is that these are indeed 2 separate devices. The crypt device is created by devicemapper on top of the backing device, but for the system it is standalone. That was the same, even before systemd. IMHO, the only difference is that before, the backing device never timed out. However, having a connection between the crypt and the backing device does make sense. Maybe it's worth a feature request? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c24
--- Comment #24 from Olaf Hering
Maybe it's worth a feature request?
Why is this a feature? Its a clear regression! In 11.4 the crypt branch just waited for the specified timeout (In fact it was not a branch, but a step). Once it returned with failure or success the following steps just used what was available. To get that back the fstab thing has to depend on crypt. There is no need for timeout or anything in fstab. The fstab step just has to reuse what earlier steps provide. I will double check if your suggested timeout values actually work. In my testing they dont, and a value of zero does actually nothing. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c25
--- Comment #25 from Olaf Hering
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c26
--- Comment #26 from Thomas Blume
(In reply to Thomas Blume from comment #23)
Maybe it's worth a feature request?
Why is this a feature? Its a clear regression!
In 11.4 the crypt branch just waited for the specified timeout (In fact it was not a branch, but a step). Once it returned with failure or success the following steps just used what was available.
To get that back the fstab thing has to depend on crypt. There is no need for timeout or anything in fstab. The fstab step just has to reuse what earlier steps provide.
I will double check if your suggested timeout values actually work. In my testing they dont, and a value of zero does actually nothing.
It should work, see: https://bugzilla.redhat.com/show_bug.cgi?id=861123 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c27
--- Comment #27 from Olaf Hering
The former can already handle the infinte timeout by using 'timeout=0'. Not sure if the thing would allow other values for timeout, or number of retries.
At least 'timeout=0,tries=5' as fourth field in crypttab is handled by the crypt branch. Good. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c28
--- Comment #28 from Olaf Hering
His first comment clearly shows that he does not understand (or just ignores) the underlying design bug: The handling of user input for the passphrase and the result of this action (block device appears or not) has to come before any other step. And this step is independend from fstab actions. The latter may get a different timeout per entry (like setting it to 1sec for the entries which are known to come from crypt). Again: do separation of 'provide block devs' from 'use block devs for fstab'. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c29
Thomas Blume
(In reply to Thomas Blume from comment #26)
His first comment clearly shows that he does not understand (or just ignores) the underlying design bug:
The handling of user input for the passphrase and the result of this action (block device appears or not) has to come before any other step. And this step is independend from fstab actions. The latter may get a different timeout per entry (like setting it to 1sec for the entries which are known to come from crypt).
Again: do separation of 'provide block devs' from 'use block devs for fstab'.
Actually there is a separation. Providing block devices is done by udev when the device appears. Udev also controls when a device will be presented to systemd by setting the systemd and/or SYSTEMD_READY tag. Using the block devices is done by creating mount units via systemd-fstab-generator. I have to submit that in this light, it is a bit misleading that x-systemd.device-timeout is an fstab parameter. However, apparently does what it should do. But coming back to the initial issue, there is already an upstream commit that address exactly this: http://systemd-devel.freedesktop.narkive.com/89Dn3OnK/patch-cryptsetup-gener... I've checked that this is included in 13.2. However, the code for this part has changed upstream, so we might have a regression here. You've reported that on 13.2 the behaviour is as expected, right? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c30
Olaf Hering
You've reported that on 13.2 the behaviour is as expected, right?
This is current TW. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c31
--- Comment #31 from Olaf Hering
http://systemd-devel.freedesktop.narkive.com/89Dn3OnK/patch-cryptsetup- generator-add-jobtimeoutsec-0-for-all-known-crypt-devices
That patch may be in TW. But does it really make crypted lvm (or crypt in general) userfriendly? What I expect is: - waiting for passphrase takes a given amount of time (4th field in crypttab) - failing to enter the passphrase drops into shell. 'nofail' in fstab may be the way to tell that a given mnt is not essential -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c32
Thomas Blume
(In reply to Thomas Blume from comment #29)
http://systemd-devel.freedesktop.narkive.com/89Dn3OnK/patch-cryptsetup- generator-add-jobtimeoutsec-0-for-all-known-crypt-devices
That patch may be in TW.
But does it really make crypted lvm (or crypt in general) userfriendly?
What I expect is: - waiting for passphrase takes a given amount of time (4th field in crypttab) - failing to enter the passphrase drops into shell.
Tested with recent tumbleweed (20150802). The above expectations are met with the following changes. In /etc/crypttab: -->- #cr_whatever /dev/crypt/vol1 none none cr_whatever /dev/crypt/vol1 none timeout=40 --<-- In /etc/fstab: -->-- #/dev/mapper/cr_whatever /whatever ext4 acl,user_xattr,nofail 0 2 /dev/mapper/cr_whatever /whatever ext4 acl,user_xattr 0 2 --<-- When the system goes to emergency shell, you can press Control-d in order to get again the password prompt for decrypting the device. When you then enter the correct password, the system will boot up completely.
'nofail' in fstab may be the way to tell that a given mnt is not essential
This is the default after installation and lets the system boot up instead of dropping into the emergency shell. The 'nofail' behaviour will only be visible when you configure a timeout in /etc/crypttab. The default in crypttab (e.g. 'none' in the 4th filed) just lets the system wait for ever for a passphrase. So, your expectations are configurable. Setting them as defaults would be easy, but maybe other users would then complain that the system doesn't wait. However, can you confirm that this works for you? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c33
Olaf Hering
http://bugzilla.suse.com/show_bug.cgi?id=909912
Franck Bui
http://bugzilla.suse.com/show_bug.cgi?id=909912
Olaf Hering
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c36
Franck Bui
(In reply to Thomas Blume from comment #26)
His first comment clearly shows that he does not understand (or just ignores) the underlying design bug:
The handling of user input for the passphrase and the result of this action (block device appears or not) has to come before any other step. And this step is independend from fstab actions. The latter may get a different timeout per entry (like setting it to 1sec for the entries which are known to come from crypt).
Again: do separation of 'provide block devs' from 'use block devs for fstab'.
That's not really possible with the current design of systemd: the block device used in fstab is a dependency of a mount unit, and as such systemd simply waits for it and there's no way to inform that it should wait for it after another unit: device units are special, they can't be ordered, they're just active when udev sends the respective events. So I'm afraid that the only way we have is to disable the job timeout for the cypto device and I can only see 2 possible workarounds: - the one that Lennart proposed in the aforementioned BZ: disable the timeout for the job waiting for the crypto device by adding x-systemd.device-timeout=0 to the relevant entry in fstab. The installer should know which entries in fstab refer to crypto devices. - stop using UUID=/LABEL=/... for referring to a crypto device in fstab and use the devnode canonical path (/dev/mapper/xxx) instead. In this case, systemd automatically disables the job timeout. Again, only the installer can change this. Yast team, would that work for you ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c37
Lukas Ocilka
http://bugzilla.suse.com/show_bug.cgi?id=909912
Arvin Schnell
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c39
Ancor Gonzalez Sosa
So I'm afraid that the only way we have is to disable the job timeout for the cypto device and I can only see 2 possible workarounds:
- the one that Lennart proposed in the aforementioned BZ: disable the timeout for the job waiting for the crypto device by adding x-systemd.device-timeout=0 to the relevant entry in fstab. The installer should know which entries in fstab refer to crypto devices.
With storage-ng (i.e. SLE>=15, Leap>=15.0 and TW) we can easily know in advance which entries in fstab rely on a LUKS device directly (i.e. an encrypted and formatted partition) or indirectly (i.e. a filesystem in an LV of a VG with encrypted PVs). Adding that option by default during installation should not be rocket science.
- stop using UUID=/LABEL=/... for referring to a crypto device in fstab and use the devnode canonical path (/dev/mapper/xxx) instead. In this case, systemd automatically disables the job timeout. Again, only the installer can change this.
Yes, we could do that as well. Also easy to implement.
Yast team, would that work for you ?
So technically both are possible and relatively easy to implement. But the usage of UUID vs Label vs kernel name is a quite sensible topic. We have got quite some bug reports about what is expected depending on the type of device, the architecture, the product and whatnot... and everybody seems to have a quite strong opinion about which is the correct option. So I'm afraid of opening the can of worms behind the second option. Implementing the first one looks like a safer bet to me. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c40
Franck Bui
So I'm afraid of opening the can of worms behind the second option. Implementing the first one looks like a safer bet to me.
Using /dev/mapper/xxx in fstab looks safe at a first glance since this path should be stable across reboots. And the major advantage of this solution is that if new options must be added/modified in the future, this can be done simply (especially during updates) by fixing the cryptsetup generator. OTOH fixing fstab to add the new options doesn't seem appealing. But if you feel that implementing the other solution is safer then fine. Anyway, it seems that the fix will belong to YaST, so I'm re-assigning the bug accordingly. Hope that makes sense. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
Ancor Gonzalez Sosa
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c41
Steffen Winterfeldt
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c42
Steffen Winterfeldt
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c43
Steffen Winterfeldt
http://bugzilla.suse.com/show_bug.cgi?id=909912
Steffen Winterfeldt
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c44
Ancor Gonzalez Sosa
Ok, so the non-essential devices time out.
But: I would argue that the current default system behavior is intentional and it's not the task of yast to clutter config files with options to favor a non-canonical non-upstream behavior.
I agree. If the default behavior of the systemd that is shipped with openSUSE is (as I understood from Steffen comment): - Wait forever for essential devices - Time out for non-essential devices I also feel is not YaST task to clitter config files to fight against that behavior provided by systemd.
That said it *might* be an interesting feature to list 'x-systemd.device-timeout' (fstab or crypttab) and 'timeout' & 'tries' (crypttab) in the expert partitioner dialog (maybe in the fstab option box).
Yes, adding some extra fstab/crypttab information (and allowing to edit it) for encrypted device would indeed be useful for people who does want to edit the systemd defaults. I will create a task for it in the Trello board we use to prioritize the YaST Team work. But improving the options in the Partitioner is kind of a different topic. As said, thinking about the original suggestion of this bug report ("the installer should enforce special timeout parameters to change default systemd behavior") I would say is a WONTFIX or WORKSFORME. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912
http://bugzilla.suse.com/show_bug.cgi?id=909912#c45
Ancor Gonzalez Sosa
I would say is a WONTFIX or WORKSFORME.
Doing so. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com