[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 <ohering@suse.com> --- Created attachment 617055 --> http://bugzilla.suse.com/attachment.cgi?id=617055&action=edit boot-failure-0.jpg This is actually the first picture of the initial failure state.. -- 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 #2 from Olaf Hering <ohering@suse.com> --- And I added a timeout= option, but that does not change anything. Perhaps I misunderstand the man page. olaf@shuttle:~> head /etc/fstab /etc/crypttab ==> /etc/fstab <== LABEL=WD7500BPVT_root / ext4 noatime,acl,user_xattr 1 1 LABEL=WD7500BPVT_boot /boot ext3 acl,user_xattr 1 2 LABEL=WD7500BPVT_swap swap swap defaults 0 0 LABEL=WD7500BPVT_11.4 /11.4 ext4 noatime,acl 1 2 UUID=6EB817D4B8179A23 /NTFS ntfs-3g ro,noatime,users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0 LABEL=WD7500BPVT_dist /dist ext3 noatime,acl 1 2 LABEL=WD7500BPVT_maild /olh/maildir ext3 noatime,acl 1 2 LABEL=WD7500BPVT_priva /olh/privat ext3 noatime,acl 1 2 LABEL=WD7500BPVT_work /work ext3 noatime,acl 1 2 ==> /etc/crypttab <== cr_ata-WDC_WD7500BPVT-00HXZT1_WD-WX61A50R8246-part6 /dev/disk/by-id/ata-WDC_WD7500BPVT-00HXZT1_WD-WX61A50R8246-part6 none timeout=0 -- 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 #3 from Olaf Hering <ohering@suse.com> --- Dont know much about that crypt stuff. But it looks like the timeout in crypttab is one thing, a to-be-added timeout in the generated .service files is another thing. Looks like systemd does not fully understand the crypttab format. -- 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 #5 from Olaf Hering <ohering@suse.com> --- (In reply to Bernhard Wiedemann from comment #4)
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 <ohering@suse.com> --- (In reply to Olaf Hering from comment #5)
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 <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ohering@suse.com Flags| |needinfo?(ohering@suse.com) --- Comment #7 from Arvin Schnell <aschnell@suse.com> --- 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). Appart from that please avoid titles that indicate a solution when in fact the problem might be somewhere completely different. The title should describe the problem. -- 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 <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aschnell@suse.com -- 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 <ohering@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ohering@suse.com) | --- Comment #8 from Olaf Hering <ohering@suse.com> --- (In reply to Arvin Schnell from comment #7)
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 <ohering@suse.com> --- (In reply to Arvin Schnell from comment #9)
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 <ohering@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ohering@suse.com) | --- Comment #11 from Olaf Hering <ohering@suse.com> --- (In reply to Arvin Schnell from comment #7)
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 <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|aschnell@suse.com |bnc-team-screening@forge.pr | |ovo.novell.com --- Comment #12 from Arvin Schnell <aschnell@suse.com> --- For me the passphrase query does not time out (and is not text console but graphical). Looks more like problem with the boot process than YaST writing wrong entries to fstab or crypttab. -- 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 #13 from Olaf Hering <ohering@suse.com> --- Also graphical times out in 13.2. Right now systemd dediced to fsck the whole disk with all its partitions and mount points, so the system is busy for the next 12 hours (or more). -- 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 #14 from Olaf Hering <ohering@suse.com> --- hwinfo etc is in bug#909977 -- 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 #15 from Olaf Hering <ohering@suse.com> --- (In reply to Arvin Schnell from comment #12)
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 <chcao@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chcao@suse.com Assignee|bnc-team-screening@forge.pr |systemd-maintainers@suse.de |ovo.novell.com | --- Comment #16 from Chenzi Cao <chcao@suse.com> --- Hi System maintainers, would you please have a look at this issue? I'm really not sure whether it is right to assign it to you, please feel free to reassign, thanks. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912 Thomas Blume <thomas.blume@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thomas.blume@suse.com --- Comment #17 from Thomas Blume <thomas.blume@suse.com> --- (In reply to Olaf Hering from comment #5)
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 <ohering@suse.com> --- Fresh tumbleweed install. Bug still exists. The /whatever mountpoint is on an encrypted lvm volume. Something asks for the passphrase. But that something has a timeout, which forces the system into a wedged state. IMO that something has to wait for an infinite time per default. IMO having a /etc/crypttab like '<tag> <devnode> none none' is the culprit. The last 'none' should be like 'luks,timeout=0'. (Not sure if luks is required, my private 11.4 crypttab looks like that) The referenced fate#319069 is a different issue IMO. -- 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#c19 --- Comment #19 from Olaf Hering <ohering@suse.com> --- (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. -- 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 <ohering@suse.com> --- (In reply to Olaf Hering from comment #19)
(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 <ohering@suse.com> --- (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. -- 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 <ohering@suse.com> --- (In reply to Olaf Hering from comment #21)
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 <thomas.blume@suse.com> --- (In reply to Olaf Hering from comment #21)
(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 <ohering@suse.com> --- (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. -- 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 <ohering@suse.com> --- I'm not sure if systemd understands the crypttab format. At least just a single 'timeout=0' as fourth field causes the crypt branch to wait forever. It allows three tries, then returns. Now the fstab branch, which I think was already started, waits forever. Since there will be no more events the system became broken. To fix this bug there must be a separation between "providing block devices" and "find block devices listed in fstab". 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. But having either eternity or 90 seconds as timeout is fine with me. The latter can also handle timeouts. Just the bug is that both run in parallel. If they are separated in steps the regression is fixed and the case can be closed. -- 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#c26 --- Comment #26 from Thomas Blume <thomas.blume@suse.com> --- (In reply to Olaf Hering from comment #24)
(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 <ohering@suse.com> --- (In reply to Olaf Hering from comment #25)
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 <ohering@suse.com> --- (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'. -- 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 <thomas.blume@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(ohering@suse.com) --- Comment #29 from Thomas Blume <thomas.blume@suse.com> --- (In reply to Olaf Hering from comment #28)
(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 <ohering@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ohering@suse.com) | --- Comment #30 from Olaf Hering <ohering@suse.com> --- (In reply to Thomas Blume from comment #29)
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 <ohering@suse.com> --- (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. '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 <thomas.blume@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(ohering@suse.com) --- Comment #32 from Thomas Blume <thomas.blume@suse.com> --- (In reply to Olaf Hering from comment #31)
(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 <ohering@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ohering@suse.com) | --- Comment #33 from Olaf Hering <ohering@suse.com> --- Created attachment 643553 --> http://bugzilla.suse.com/attachment.cgi?id=643553&action=edit passphrase.jpg This does not really work. First it asks for the passphrase. If it times out the login prompt is shown. Using ctrl+d gives another prompt. But appearently no input is accepted, note the lone 's'. In followup attempts no input is accepted. And the final reboot is still waiting for the missing devices, which causes unneeded delay of reboot. All in all that user interface is bad. Unlikely our fault. As said earlier, the lack of separation between preparation and usage of block devices leads to this situation. Its a simple setup, which can be handled by the config files which are currently in use. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fbui@suse.com Flags| |needinfo?(ohering@suse.com) -- 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 <ohering@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ohering@suse.com) | -- 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#c36 Franck Bui <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS CC| |yast2-maintainers@suse.de Flags| |needinfo?(yast2-maintainers | |@suse.de) --- Comment #36 from Franck Bui <fbui@suse.com> --- (In reply to Olaf Hering from comment #28)
(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 <locilka@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ancor@suse.com Flags| |needinfo?(ancor@suse.com) --- Comment #37 from Lukas Ocilka <locilka@suse.com> --- Ancor, please, take a look (with your PO's hat on your head). Thx -- 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 <aschnell@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(yast2-maintainers | |@suse.de) | -- 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#c39 Ancor Gonzalez Sosa <ancor@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ancor@suse.com) | --- Comment #39 from Ancor Gonzalez Sosa <ancor@suse.com> --- (In reply to Franck Bui from comment #36)
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 <fbui@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|systemd-maintainers@suse.de |ancor@suse.com --- Comment #40 from Franck Bui <fbui@suse.com> --- (In reply to Ancor Gonzalez Sosa from comment #39)
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 <ancor@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://trello.com/c/cT1bQI | |Ns Assignee|yast2-maintainers@suse.de |yast-internal@suse.de -- 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#c41 Steffen Winterfeldt <snwint@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #41 from Steffen Winterfeldt <snwint@suse.com> --- I did some testing with Leap 15.1 and I don't see any timeouts at all. Neither with LVM nor with plain device encryption. Also, the LVM setup uses /dev/mapper/XXX in fstab already, so no change would have been needed there. Basically historic now, but anyway: I would have implemented variant 1 (explicit timeout setting in config) even if it looks a bit ugly. Mainly because using UUID=/LABEL= is quite common and it would (imho) surprise the user that the way a devices is referred to would make a difference. While explicitly attaching an option to LUKS devices has at least some educating value. ;-) -- 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#c42 Steffen Winterfeldt <snwint@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #42 from Steffen Winterfeldt <snwint@suse.com> --- Seems I spoke too soon. -- 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#c43 Steffen Winterfeldt <snwint@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(ancor@suse.com) --- Comment #43 from Steffen Winterfeldt <snwint@suse.com> --- 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. 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). Ancor, what's your opinion? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=909912 Steffen Winterfeldt <snwint@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |snwint@suse.com -- 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#c44 Ancor Gonzalez Sosa <ancor@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ancor@suse.com) | --- Comment #44 from Ancor Gonzalez Sosa <ancor@suse.com> --- (In reply to Steffen Winterfeldt from comment #43)
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 <ancor@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |WORKSFORME --- Comment #45 from Ancor Gonzalez Sosa <ancor@suse.com> --- (In reply to Ancor Gonzalez Sosa from comment #44)
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