http://bugzilla.suse.com/show_bug.cgi?id=909912 --- Comment #1 from Olaf Hering --- 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 #3 from Olaf Hering --- 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 #6 from Olaf Hering --- (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 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 --- Comment #10 from Olaf Hering --- (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 Arvin Schnell changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|aschnell@suse.com |bnc-team-screening@forge.pr | |ovo.novell.com --- Comment #12 from Arvin Schnell --- 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 #14 from Olaf Hering --- 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 Chenzi Cao 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 --- 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 http://bugzilla.suse.com/show_bug.cgi?id=909912#c18 --- Comment #18 from Olaf Hering --- 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#c20 --- Comment #20 from Olaf Hering --- (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#c22 --- Comment #22 from Olaf Hering --- (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#c24 --- Comment #24 from Olaf Hering --- (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#c26 --- Comment #26 from Thomas Blume --- (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#c28 --- Comment #28 from Olaf Hering --- (In reply to Thomas Blume from comment #26)

https://bugzilla.redhat.com/show_bug.cgi?id=861123

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#c30 Olaf Hering changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ohering@suse.com) | --- Comment #30 from Olaf Hering --- (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#c32 Thomas Blume changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(ohering@suse.com) --- Comment #32 from Thomas Blume --- (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 Franck Bui 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 http://bugzilla.suse.com/show_bug.cgi?id=909912#c36 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS CC| |yast2-maintainers@suse.de Flags| |needinfo?(yast2-maintainers | |@suse.de) --- Comment #36 from Franck Bui --- (In reply to Olaf Hering from comment #28)

(In reply to Thomas Blume from comment #26)

...

https://bugzilla.redhat.com/show_bug.cgi?id=861123

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 Arvin Schnell 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#c40 Franck Bui changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|systemd-maintainers@suse.de |ancor@suse.com --- Comment #40 from Franck Bui --- (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 http://bugzilla.suse.com/show_bug.cgi?id=909912#c41 Steffen Winterfeldt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #41 from Steffen Winterfeldt --- 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#c43 Steffen Winterfeldt changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(ancor@suse.com) --- Comment #43 from Steffen Winterfeldt --- 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 http://bugzilla.suse.com/show_bug.cgi?id=909912#c44 Ancor Gonzalez Sosa changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ancor@suse.com) | --- Comment #44 from Ancor Gonzalez Sosa --- (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.