does not ask for LUKS passphrases without plymouth

[Michael Neuffer]

after the recent upstart -> systemd "migration" my system is left unable to complete it's boot process.
It asks for the first passphrase, but not for the second.

When booting with upstart (via the advanced boot options), the system behaves correctly and asks for both passphrases.

/etc/crypttab
sda2_crypt UUID=32a5c8b9-cccc-4b06-9224-0dc595e320b7 none luks,discard
sdb1_crypt UUID=8b568ed8-842b-462c-9ecd-789d80fb913f none luks,discard

/etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/sda2_crypt / ext4 discard,noatime,nodiratime,commit=300,errors=remount-ro 0 1
/dev/sda1 /boot ext3 discard,relatime,nodiratime,commit=300,defaults 0 2
/dev/mapper/sdb1_crypt /opt btrfs nofail,autodefrag,discard,enospc_debug 0 1
#
tmpfs /tmp tmpfs relatime,nosuid 0 0
#/dev/mapper/swap none swap sw,discard 0 0

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: systemd 219-4ubuntu5 [modified: usr/share/dbus-1/system-services/org.freedesktop.systemd1.service]
ProcVersionSignature: Ubuntu 3.19.0-9.9-generic 3.19.1
Uname: Linux 3.19.0-9-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.16.2-0ubuntu3
Architecture: amd64
CurrentDesktop: XFCE
Date: Sun Mar 15 00:10:02 2015
InstallationDate: Installed on 2014-05-30 (288 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
MachineType: Dell Inc. Precision M4800
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.19.0-9-generic root=UUID=c72e0d8e-4822-45c8-b95f-6e13971940d3 ro nomodeset allow-discards root_trim=yes nomdmonddf nomdmonisw crashkernel=384M-:128M nogpumanager init=/sbin/upstart
SourcePackage: systemd
SystemdDelta:
 [EXTENDED] /lib/systemd/system/graphical.target → /lib/systemd/system/graphical.target.d/xdiagnose.conf
 [EXTENDED] /lib/systemd/system/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

 2 overridden configuration files found.
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 06/26/2014
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A09
dmi.board.name: 0PMFT3
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA09:bd06/26/2014:svnDellInc.:pnPrecisionM4800:pvr01:rvnDellInc.:rn0PMFT3:rvrA00:cvnDellInc.:ct9:cvr:
dmi.product.name: Precision M4800
dmi.product.version: 01
dmi.sys.vendor: Dell Inc.

[Launchpad Janitor (janitor)]

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

[Alberto Salvia Novella (es20490446e)]

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.

[Martin Pitt (pitti)]

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?

[Toon (toon2)]

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

[Kimmo Satta (ksatta79)]

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.

[Julian Gilbey (jdg)]

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

[Julian Gilbey (jdg)]

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

[Martin Pitt (pitti)]

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.

[Martin Pitt (pitti)]

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

[Launchpad Janitor (janitor)]

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

[Steve Langasek (vorlon)]

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)?

[Didier Roche (didrocks)]

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

[Didier Roche (didrocks)]

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.

[dino99 (9d9)]

patched into 215-16