does not ask for LUKS passphrases without plymouth

Status changed to 'Confirmed' because the bug affects multiple users.

Please:
  1. Report to <https://bugs.freedesktop.org/>.
  2. Paste the new report URL here.
  3. Set this bug status back to "confirmed".

Thank you.

That sounds like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779612 . Do you use plymouth, i. e. do you see the graphical sphash screen and boot with "splash"? Your CurrentDmesg.txt suggests that you aren't. Can you please try with that?

Same Problem here. Plymouth is enabled but asking password only for first of two crypt device.

I can confirm this also.

Steps to reproduce:
- install *buntu 15.04
- sudo systemctl set-default multi-user.target
- add some partition _other than root_ to /etc/crypttab

-> systemd doesn't ask for passphrase, stops at "starting cryptography for foo.."

booting with upstart and "text" kernel option (same as systemd and multi-user.target), it asks for passphrase and works correctly.

In my tests I had root without encryption and another partition in crypttab, then it doesn't ask for passphrase. In another test I had root encrypted and that in crypttab, then it asks for the passphrase.

I can't even unlock both encrypted drives when using plymouth.

Oops, my bad - I got my /etc/crypttab wrong. Fixing that allows multiple encrypted devices with plymouth.

I tested this on current Xenial amd64 with a LUKS partition for /opt. Indeed when dropping "splash" from the command line I only get "Starting cryptography for..." but no actual prompt. Theh same happens when I use "console=ttyS0" and thus see the boot messages on the QEMU serial console.

In this case, systemd-ask-password-console is supposed to kick in. Both systemd-ask-password-console.{path,service} have

   ConditionPathExists=!/run/plymouth/pid

with the idea that if plymouth is running, the password will be asked by plymouth, and the "console" askpass would actually get in the way. Asking passwords with plymouth does work for me (both on tty1 and the serial console ttyS0), and that's consistent with Julian's report in comment 8 and the original report by Michael whose kernel command line also does not have "splash".

Now, I observed that even when booting without "splash", plymouthd is *still* running, and /run/plymouth/pid exists. It isn't started by plymouth-start.service as its condition fail (no "splash" in command line). But I suppose it's already started in the initramfs and survives from there.

When I remove the above ConditionPathExists=!/run/plymouth/pid, then prompting for the password when booting without "splash" works fine for both tty1 and ttyS0, but this is of course not a solution.

I think the bug is that /usr/share/initramfs-tools/scripts/init-premount/plymouth defaults to starting plymouth if there is no "splash" argument, but plymouth's systemd units default to *not* starting plymouth without a "splash" argument.

Explicitly specifying "nosplash" works, but we need to make up our mind what the default should be for no "*splash*" argument at all. I'd argue that it should not start plymouth in this case, as that's the intent of cloud-config and friends, and the intent of plymouth's services.

See also debian/patches/ubuntu-add-splash-option.patch which explicitly documents that plymouth should only be started with "splash".

This bug was fixed in the package plymouth - 0.9.2-3ubuntu10

---------------
plymouth (0.9.2-3ubuntu10) xenial; urgency=medium

  * debian/local/plymouth.init-premount: Don't start plymouth if "splash" is
    not present on the kernel command line. This makes initrd behaviour
    consistent with what happens at boot (see ubuntu-add-splash-option.patch).
    Fixes password prompts when not booting with "splash". (LP: #1432265)

 -- Martin Pitt <email address hidden> Mon, 22 Feb 2016 13:15:42 +0100

On Mon, Feb 22, 2016 at 12:17:09PM -0000, Martin Pitt wrote:
> See also debian/patches/ubuntu-add-splash-option.patch which explicitly
> documents that plymouth should only be started with "splash".

... which appears to be a regression in xenial. The 'splash' commandline
option was previously used to control whether or not a graphical splash was
shown; it was *not* used to control whether plymouth itself was running,
only whether it was graphical.

Didier, why have you disabled the plymouth services when 'splash' is not
given on the commandline? What is the expected boot experience now for e.g.
filesystem checks on a server (that may require interaction)?

Le 29/02/2016 08:55, Steve Langasek a écrit :
> On Mon, Feb 22, 2016 at 12:17:09PM -0000, Martin Pitt wrote:
>> See also debian/patches/ubuntu-add-splash-option.patch which explicitly
>> documents that plymouth should only be started with "splash".
>
> ... which appears to be a regression in xenial. The 'splash' commandline
> option was previously used to control whether or not a graphical splash was
> shown; it was *not* used to control whether plymouth itself was running,
> only whether it was graphical.
>
> Didier, why have you disabled the plymouth services when 'splash' is not
> given on the commandline? What is the expected boot experience now for e.g.
> filesystem checks on a server (that may require interaction)?
>

The argument passed from "splash" to "nosplash" in debian by default. I
did try to reintroduce backward compatibility and this case handling. I
may have missed some parts (reminder: 150+ files difference), and that
was not the intend.
Remember as well that the description is made from most of the diff I
could understand. Indeed, even recent patches from people uploading
plymouth in ubuntu included new patches without any description (and not
following DEP3), which was making this merge even harder…

We did try with Martin on a vm when a passphrase was asked from the
start, and didn't see any issue, but that was maybe another case and we
didn't get into that one.

Feel free to amend and change for the expected user experience where the
fundation team feel the needs.

Cheers,
Didier

The argument passed from "splash" to "nosplash" in debian by default. I
did try to reintroduce backward compatibility and this case handling. I
may have missed some parts (reminder: 150+ files difference), and that
was not the intend.
Remember as well that the description is made from most of the diff I
could understand. Indeed, even recent patches from people uploading
plymouth in ubuntu included new patches without any description (and not
following DEP3), which was making this merge even harder…

We did try with Martin on a vm when a passphrase was asked from the
start, and didn't see any issue, but that was maybe another case and we
didn't get into that one.

Feel free to amend and change for the expected user experience where the
fundation team feel the needs.

patched into 215-16