no VT switch for passphrase prompt w/o 'splash' (prompt on VT7)

Bug #520122 reported by Martin Pool
22
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Invalid
Undecided
Unassigned
plymouth (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

I have a Lucid laptop with root-on-lvm-on-luks. It works fine when starting normally, but in single user mode it hangs before unlocking the crypted partition.

I think the last message printed in the first case is 'running init-bottom' and then it just stays stuck. I have lvm-on-luks and it does not ask for a passphrase to unlock the pv containing the root partition.

I'm pretty sure this is a regression from karmic.

Revision history for this message
Martin Pool (mbp) wrote :
Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Moving over to cryptsetup, since you report that you're never asked for the passphrase to unlock the root partition

if the root partition isn't mounted, you haven't even *got* to Upstart yet

affects: upstart (Ubuntu) → cryptsetup (Ubuntu)
Revision history for this message
Steve Langasek (vorlon) wrote :

Please post your /etc/fstab and /etc/crypttab.

Changed in cryptsetup (Ubuntu):
status: New → Incomplete
Revision history for this message
Steve Langasek (vorlon) wrote :

(the latter case is certainly not related to cryptsetup, but let's tackle the first one first)

Revision history for this message
Martin Pool (mbp) wrote :
Revision history for this message
Martin Pool (mbp) wrote :

fstab attached.

I will try removing the probably-unnecessary bind mounts and see if that helps.

Revision history for this message
Martin Pool (mbp) wrote :

Getting down to singleuser mode now seems to be fixed: after a pause I get the recovery menu. So now it's just a matter of getting cryptsetup to run.

Changed in cryptsetup (Ubuntu):
status: Incomplete → New
Revision history for this message
Steve Langasek (vorlon) wrote :

Please boot with 'break=top' to interrupt the boot sequence, and post the output of 'cat /conf/conf.d/cryptroot'.

Revision history for this message
Martin Pool (mbp) wrote :

I put 'sh -x' into local-top/cryptroot, and it seems to show that it's trying to read the passphrase through plymouth, but maybe plymouth isn't able to read a passphrase when booting in recover mode? I'll post a screenshot and try break=top

Revision history for this message
Martin Pool (mbp) wrote :

/conf/conf.d/cryptroot has
target=crypt_sda5,source=/dev/sda5,key=none,rootdev,lvm=lithe_ssd-root

which seems reasonable.

Here is a screenshot of where it sticks, running

plymouth/sbin/cryptsetup ask-for-password -T --prompt 1

If I type here it's echoed to the screen but nothing else happens.

If the problem is that plymouth can't ask for the passphrase in recovery mode that would be consistent with it working in normal mode but blocking here in recovery mode.

Martin Pool (mbp)
description: updated
Revision history for this message
Steve Langasek (vorlon) wrote :

> plymouth/sbin/cryptsetup ask-for-password -T --prompt 1

That's... very odd. What it should be running (and what I think it actually is running) is

  plymouth ask-for-password --prompt "Unlocking the disk /dev/sda5 (crypt_sda5)\nEnter passphrase:" | /sbin/cryptsetup -T 1 luksOpen /dev/sda5 crypt_sda5

but for whatever reason the two commands are being interleaved here in the output of sh -x?

Anyway, if this command is hanging, I think it must be a plymouth bug. I'll try to reproduce it here.

Changed in cryptsetup (Ubuntu):
status: New → Invalid
Revision history for this message
Steve Langasek (vorlon) wrote :

Ok, I can reproduce this behavior. When it appears to hang, have you tried pressing Alt+F7? Plymouth is running on a different VT, but hasn't switched over to it.

I believe this is going to be fixed by Scott's refactoring of terminal handling in plymouth.

Changed in plymouth (Ubuntu):
status: New → Triaged
Revision history for this message
Martin Pool (mbp) wrote :

Switching to vt7 does indeed let me enter the passphrase. The text mode handling is a bit messed up, with the prompt being reprinted for every keypress I type, so that eventually it's repeated N times down the screen.

After that I do get to the recovery menu, which is good.

However, if I choose 'resume normal startup', the machine comes up to multiuser mode, but it does not start X. I'm just left on vt7 in text mode. I can then switch to vt1 and log in. I verified there that gdm was not running at all. If I do 'sudo service gdm start' then it does come up properly. This might be a separate bug?

Revision history for this message
Steve Langasek (vorlon) wrote :

Yes, gdm not starting is bug #436936.

Steve Langasek (vorlon)
summary: - can't get to single-user mode
+ no VT switch for passphrase prompt w/o 'splash' (prompt on VT7)
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.1 KiB)

This bug was fixed in the package plymouth - 0.8.0~-13

---------------
plymouth (0.8.0~-13) lucid; urgency=low

  [ Steve Langasek ]
  * Don't attach /proc/cmdline to apport reports, this is already in the
    standard info that gets collected...

  [ Alberto Milone ]
  * ubuntu_logo theme:
    - New logo from Otto Greenslade.
    - Switch off dots starting from the ones on the left instead of
      switching them off all at once.

  [ Scott James Remnant ]
  * Move the Ubuntu logo up as discussed with Otto, this makes the mouse
    cursor appear between the logo and dots and solves the optical illusion
    of the logo being too low. LP: #535014.
  * Don't include message about disk checks, which can come from mountall.
  * Drop the rc script splash functions, we don't want the SysV-rc compat
    stuff messing around with the splash screen - this can be entirely
    managed by Upstart now. LP: #528787, #537262.

  * Plymouth Fix Mega Patch:
    - This hasn't yet been broken up into enough bits to send upstream, and
      doesn't *quite* address all the issues yet, but it's a major step.

    - Rewrite the VT handling, rather than abusing /dev/tty0 keep all VT
      operations on the actual VT (tty7), this avoids issues where we set
      the graphics mode of the wrong VT or put the wrong VT into VT_PROCESS
      mode. LP: #520460, #522598, #526321, #533135
    - Don't attempt VT switch when using non-VT consoles.
    - Make VT mandatory for renderer plugins, so we fallback gracefully to
      text when the console is not a VT. LP: #516825, #527083.
    - Restore VT when finished displaying the splash unless plymouth quit
      is called with --retain-splash. LP: #506297.
    - Activate VT from text and details plugins, rather than haphardly in
      the main code, this means the textual boot is also on VT7.
      LP: #518352, #520122.
    - Add a --has-active-vt command that can let gdm inquire whether it
      should reuse Plymouth's VT; fixes the issue where Plymouth has no
      visible splash screen and X ends up on VT1. LP: #519641, #533572.

    - Don't open terminal device in X11, fixes the issue where X will crash
      when debugging plugins using the X11 renderer.
    - Add --tty option to plymouthd for debugging when X is running and
      thus using an alternate VT.

    - Improve deactivate command so that the terminal is no longer watched
      for keyboard input, session is closed, etc. LP: #528787, #531650.
    - Ignore mode changes while deactivated, otherwise we can end up
      resetting the VT back into text mode while X is starting up.
      LP: #523788, #502509.

    - Fix races with simultaneous quit and deactivate commands, or multiples
      of those commands.
    - Ignore --show-splash, --hide-splash, etc. commands while deactivated.
    - Add reactivate command for testing purposes.

    - Don't scan out drm buffer contents to fbcon when not called with
      quit --retain-splash. LP: #527180.

    - Avoid resetting the terminal to unbuffered mode on every write, this
      results in setting X's VT into raw mode and results in the X server
      crashing on key presses. LP: #532047, #534861, #519460, #520...

Read more...

Changed in plymouth (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
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.