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

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

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1362333

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.

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

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.

  * https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1359689

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

I have encountered this issue installing today's Ubuntu Desktop amd64 ISO: http://cdimage.ubuntu.com/daily-live/20141017/utopic-desktop-amd64.iso.
http://iso.qa.ubuntu.com/qatracker/milestones/325/builds/82063/testcases/1451/results/.

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

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

I installed on a Virtualbox VM if you guys think it can be helpfull I could try an install on this hardware:
https://gist.github.com/anonymous/b62dca1c2b9dcd29034e (HP G62 notebook) or
https://gist.github.com/anonymous/3203c7c5a43a509c0f22 (the Virtualbox VM was running on this host).

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.

@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.

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.

I think this bug is related to the following two bug-tickets:
https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1359689
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752752

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

@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.

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:

  ply_boot_connection_send_answer()
  {
  [...]
      if (!ply_write (connection->fd,
                      PLY_BOOT_PROTOCOL_RESPONSE_TYPE_ANSWER,
                      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.

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.

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