does not ask for LUKS passphrases without plymouth
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| plymouth (Ubuntu) |
High
|
Martin Pitt | ||
| systemd (Debian) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
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-
sdb1_crypt UUID=8b568ed8-
/etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/
/dev/sda1 /boot ext3 discard,
/dev/mapper/
#
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/
ProcVersionSign
Uname: Linux 3.19.0-9-generic x86_64
NonfreeKernelMo
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=
SourcePackage: systemd
SystemdDelta:
[EXTENDED] /lib/systemd/
[EXTENDED] /lib/systemd/
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.
dmi.product.name: Precision M4800
dmi.product.
dmi.sys.vendor: Dell Inc.
Michael Neuffer (neuffer) wrote : | #1 |
Please:
1. Report to <https:/
2. Paste the new report URL here.
3. Set this bug status back to "confirmed".
Thank you.
Changed in systemd (Ubuntu): | |
importance: | Undecided → Critical |
status: | Confirmed → Incomplete |
tags: | added: asked-to-upstream |
That sounds like https:/
summary: |
- after the upstart replacement with systemd, the system fails to boot - with 2 LUKS encrypted devices. + does not ask for multiple LUKS passphrases |
summary: |
- does not ask for multiple LUKS passphrases + does not ask for multiple LUKS passphrases without plymouth |
Changed in systemd (Ubuntu Vivid): | |
importance: | Critical → High |
status: | Incomplete → New |
status: | New → Confirmed |
Changed in systemd (Debian): | |
status: | Unknown → New |
no longer affects: | systemd |
Changed in systemd (Ubuntu Vivid): | |
status: | Confirmed → Triaged |
Same Problem here. Plymouth is enabled but asking password only for first of two crypt device.
Changed in systemd (Ubuntu Vivid): | |
milestone: | none → vivid-updates |
tags: | added: rls-w-incoming |
Kimmo Satta (ksatta79) wrote : | #6 |
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.
Changed in systemd (Ubuntu): | |
assignee: | nobody → Martin Pitt (pitti) |
Julian Gilbey (jdg) wrote : | #7 |
I can't even unlock both encrypted drives when using plymouth.
Julian Gilbey (jdg) wrote : | #8 |
Oops, my bad - I got my /etc/crypttab wrong. Fixing that allows multiple encrypted devices with plymouth.
tags: |
added: rls-x-incoming removed: rls-w-incoming |
no longer affects: | systemd (Ubuntu Vivid) |
summary: |
- does not ask for multiple LUKS passphrases without plymouth + does not ask for LUKS passphrases without plymouth |
Martin Pitt (pitti) wrote : | #9 |
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-
ConditionPat
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-
When I remove the above ConditionPathEx
I think the bug is that /usr/share/
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.
affects: | systemd (Ubuntu) → plymouth (Ubuntu) |
Martin Pitt (pitti) wrote : | #10 |
See also debian/
Changed in plymouth (Ubuntu): | |
status: | Triaged → Fix Committed |
Launchpad Janitor (janitor) wrote : | #11 |
This bug was fixed in the package plymouth - 0.9.2-3ubuntu10
---------------
plymouth (0.9.2-3ubuntu10) xenial; urgency=medium
* debian/
not present on the kernel command line. This makes initrd behaviour
consistent with what happens at boot (see ubuntu-
Fixes password prompts when not booting with "splash". (LP: #1432265)
-- Martin Pitt <email address hidden> Mon, 22 Feb 2016 13:15:42 +0100
Changed in plymouth (Ubuntu): | |
status: | Fix Committed → Fix Released |
Steve Langasek (vorlon) wrote : Re: [Bug 1432265] Re: does not ask for LUKS passphrases without plymouth | #12 |
On Mon, Feb 22, 2016 at 12:17:09PM -0000, Martin Pitt wrote:
> See also debian/
> 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) wrote : | #14 |
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/
>> 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) wrote : | #13 |
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) wrote : | #15 |
patched into 215-16
Changed in systemd (Debian): | |
importance: | Unknown → Undecided |
status: | New → Fix Released |
Status changed to 'Confirmed' because the bug affects multiple users.