After reboot of Ubuntu installation, password for LVM encryption is not accepted

Bug #1362333 reported by Carla Sella on 2014-08-27
This bug affects 8 people
Affects Status Importance Assigned to Milestone
plymouth (Ubuntu)
ubiquity (Ubuntu)

Bug Description

I have tried several times to perform an installation of Gnome Ubuntu x64 (Utopic Beta 1 26/08/2014 ISO), after reboot, you are asked to insert your passphrase, but it is not accepted it keeps on displaying that the passphrase is not correct even though I am inserting the correct one, and so booting of Ubuntu Gnome isn't possible after install.
I have performed the installation on a Virtualbox VM and I still have it if you need something else.
I am attaching the /var/log directory of the /dev/sda5 LVM volume that I could manage to unencrypt, when unencrypting it manually the password was accepted and /dev/sda5 mounted, so I am sure the password I was trying to insert was the correct one.
This is the test I was carrying out when I detected this bug:
This is the ISO I tested on:

Carla Sella (carla-sella) wrote :
summary: - After reboot of Ubuntu Gnome install passowrd for LVM encryption is not
+ After reboot of Ubuntu Gnome install password for LVM encryption is not
description: updated

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
description: updated
summary: - After reboot of Ubuntu Gnome install password for LVM encryption is not
- accepted
+ After reboot of Ubuntu Gnome installation, password for LVM encryption
+ is not accepted
description: updated

I tried the same test on Ubuntu Utopic Daily ISO and the bug is not present, everything works fine, so it is Ubuntu Gnome related as far as I tested.

description: updated
Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Martin Wimpress (flexiondotorg) wrote :

I have been experiencing this issue for weeks, ever since plumouth 0.9.0 landed. I've discussed it with Alan Pope and Steve Langasek. I've just tried installing stock Ubuntu 14.10 Beta 2 desktop i386 on the following systems and selected full disk encryption on all of them during the install:

  * Thinkpad T43p (ATI/AMD graphics chipset, open source driver) - On reboot my pass phrase is not accepted.
  * Thinkpad X61s (Intel graphics chipset, open source driver) - On reboot I can enter my pass phrase.
  * VirtualBox Guest (no virtualbox-guest-* modules installed) - On reboot my pass phrase is not accepted.

Therefore I suspect this issue is in someway releated to the graphics driver. The following bug raised against Plymouth also describes the same issue.


The other concern is users running 14.04 with full disk encrpytion and who then upgrade to 14.10 could effectively brick their computer.

Daniel Marks (d3n14l) on 2014-10-20
summary: - After reboot of Ubuntu Gnome installation, password for LVM encryption
- is not accepted
+ After reboot of Ubuntu installation, password for LVM encryption is not
+ accepted
Nicholas Skaggs (nskaggs) wrote :

Can you comment on what graphics card and language you are installing with Carla?

Andy Whitcroft (apw) wrote :

I can confirm this occurs in a newly installed VM from todays amd64 desktop image.

Carla Sella (carla-sella) wrote :

I installed on a Virtualbox VM if you guys think it can be helpfull I could try an install on this hardware: (HP G62 notebook) or (the Virtualbox VM was running on this host).

Steve Langasek (vorlon) wrote :

In a VM, I've reproduced some very strange behavior with plymouth and cryptsetup. On a new install, I see:

 - plymouth ask-for-password exits non-zero, and returns an empty string to the cryptsetup hook
 - if I hit Esc to switch to the text interface instead of the graphical splash, then the first passphrase attempt after switching always fails, and the second one always succeeds
 - when in graphical mode, plymouth ask-for-password never return non-zero

I don't have any explanation for this behavior at the moment. It has also not been reproducible on my laptop (real hardware), where I use crypted root with cryptsetup+plymouth, but I will do a test shortly.

Andy Whitcroft (apw) wrote :

@Steve -- for me in a VM it always fails either way, in graphical or in text mode, totally consistantly I have never had a success. If I let things drop to initramfs and then luksOpen the disk by hand the same password opens the device without issue.

I also will note that (for me at least) the length of the input string seems to change behaviour. When I type anything fewer than 6 characters I get the expected "No key available with this passphrase", longer password do not elicit this response.

Andy Whitcroft (apw) wrote :

Experimenting on the image I think I am able to say that the "plymouth ask-for-password --prompt FOO" functionality is not working. If you envoke /lib/cryptsetup/askpass FOO and type a password you will get the password string as text on stdout, this does not occur with plymouth's ask-for-password, the prompt is shown and can be interacted but the client simply exits 1 rather then emitting the typed text.

Daniel Marks (d3n14l) wrote :

I think this bug is related to the following two bug-tickets:

If so, there is already a fix in the latest plymouth release.

Andy Whitcroft (apw) on 2014-10-21
Changed in plymouth (Ubuntu):
status: New → Confirmed
Andy Whitcroft (apw) wrote :

@Cyrus -- not sure they seem to be implying that the issue they solve is that the prompt is not displayed, but here it is just unusable.

Andy Whitcroft (apw) wrote :

Debugging the issue some I can say that (for me) the issue seems to be when the server sends the answer response to the client. It is running in "ply_boot_connection_send_answer" when it gets a SIGPIPE in the middle, implying the client has gone:

      if (!ply_write (connection->fd,
                      strlen (PLY_BOOT_PROTOCOL_RESPONSE_TYPE_ANSWER)) ||
          !ply_write_uint32 (connection->fd,
                             size) ||
          !ply_write (connection->fd,
                      answer, size))
          ply_trace ("could not finish writing answer: %m");

Now the client does wait for the server to respond before exiting blocking until the user hits return, and it reports a failure was sent. This however could come out for a lost connection also. The fact that it does wait hints that the response triggers the closure. Need more debug as to what if anything is received.

Andy Whitcroft (apw) wrote :

Ok fuller debug indeed confirms that the client reads the type of the message (ANSWER), and then attempts to read the size of the said answer. That is not yet present, so it gets EAGAIN because this is a NONBLOCKing socket. This is does not like and aborts the connection in failure, leading the server to report connection loss.

In short we are hitting normal behaviour, multiple writes and multiple reads can occur in any order. The correct fix is for the consumer to buffer the partial data, and to continue when the full data is available, this is non-trivial because the data we are trying to buffer as different form depending on type. Ideally we would start each message with a length, such that we could buffer it before introspecting it.

For now we can also avoid this by ensuring the server write is performed as a single operation. As long as we are below the buffering limits we will guarentee to only see the initial command type byte if the answer is also present.

Steve Langasek (vorlon) on 2014-10-21
Changed in plymouth (Ubuntu):
status: Confirmed → In Progress
importance: Undecided → Critical
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package plymouth - 0.9.0-0ubuntu7

plymouth (0.9.0-0ubuntu7) utopic; urgency=low

  * d/p/ubuntu-fix-split-writes.patch -- avoid the client seeing
    the beginning of our replies before the whole reply is ready for
    consumption. This avoids us aborting password lookups even though
    they were correctly entered. (LP: #1362333)
 -- Andy Whitcroft <email address hidden> Tue, 21 Oct 2014 12:55:18 +0100

Changed in plymouth (Ubuntu):
status: In Progress → Fix Released
Andy Whitcroft (apw) on 2014-10-22
Changed in ubiquity (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.