no password prompt for cryptsetup in 10.04 64-bit server

Bug #560105 reported by letstrynl
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
plymouth (Ubuntu)
Triaged
Medium
Unassigned

Bug Description

Binary package hint: cryptsetup

I normally manually run a short script that will restart the cryptdisks.
It will ask for the password and the script will mount the encrypted filsystem.

/etc/crypttab:
# <target name> <source device> <key file> <options>
secure /dev/sda6 none cipher=aes-cbc-essiv:sha256

After updating/upgrading today, the only thing I see from cryptdisks is the following:

root@bla~# service cryptdisks restart
 * Stopping remaining crypto disks... * secure (stopped)... [ OK ]
 * Starting remaining crypto disks... * secure (starting)..

That's it. No password prompt.

Extra information:

root@bla~# apt-cache policy cryptsetup
cryptsetup:
  Installed: 2:1.1.0~rc2-1ubuntu13
  Candidate: 2:1.1.0~rc2-1ubuntu13
  Version table:
 *** 2:1.1.0~rc2-1ubuntu13 0
        500 http://nl.archive.ubuntu.com/ubuntu/ lucid/main Packages
        100 /var/lib/dpkg/status

root@bla~# lsb_release -rd
Description: Ubuntu lucid (development branch)
Release: 10.04

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

Some extra information:

1) splash hangs also
2) strace output is attached

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

Thank you for taking the time to report this issue and help to improve Ubuntu.

Is the device mounted at the time you try to restart it?

Please run strace with the '-ff' option; the attached strace tells us nothing, since only the 'service' command is being traced and not the underlying cryptsetup scripts.

Changed in cryptsetup (Ubuntu):
status: New → Incomplete
Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

Thanks for replying.

strace -o strace.txt -ff service cryptdisks restart

results in one tracefile per pid, from which I attached the two that did not normally finish (I pressed Ctrl-C).

Regards

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

The device (as in /dev/sda6) is not mounted, of course. There aren't any /dev/mapper devices either, only /dev/mapper/control.
On the /dev/sda disk there are 3 filesystems in use (root, swap and data).

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :
Revision history for this message
Steve Langasek (vorlon) wrote :

strace.txt.1165 shows that 'plymouth --ping' gets called, and instead of immediately exiting because plymouthd isn't running, it manages to connect to plymouthd and then hangs waiting for an answer!

Why is plymouthd running on your system? It's only supposed to be running at startup or shutdown.

affects: cryptsetup (Ubuntu) → plymouth (Ubuntu)
Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

I don't know, actually.

The system has been upgraded since the alpha-1 stage.
So maybe it's some residue from earlier stages?

Would it been wise to reinstall (and update/upgrade) ?

Strange thing is that my Ubuntu 64-bit desktop installation doesnt seem to have this problem.

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

Could it be that "plymouth quit" is just not working ?

root 247 1 0 12:20 ? 00:00:02 /sbin/plymouthd --mode=boot --attach-to-session --pid-file=/dev/.initramfs/plymouth.pid
root 882 1 0 12:20 ? 00:00:00 /bin/plymouth quit
root 1587 1105 0 15:40 pts/2 00:00:00 grep ply

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

If I manually kill the plymouth commands:

mountall: Plymouth command failed

Seems it's going wrong in mountall ?

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

After killing the plymouth stuff manually, I'm able to use cryptdisks.

For now I 've adapted my script to kill everything called plymouth ;-)

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

Well, since you've killed plymouth manually, we may never find out now why it was hanging. Marking this bug as invalid; if you're able to reproduce the problem again on a subsequent reboot and can provide more debugging info (such as a backtrace of plymouthd with gdb), please reopen.

Changed in plymouth (Ubuntu):
status: Incomplete → Invalid
Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

The problem is reproducable.
After latest updates my 10.04 Ubuntu Desktop (with cryptdisk) also hangs in startup.

Ctrl-Alt-Del is working.
Switching to one of the tty's (Ctrl-Alt-Fx) doesn't.

The system seems to be up (server edition was reachable with SSH).

Maybe it has something to do with my script. I'll try to find out and let you know.

Changed in plymouth (Ubuntu):
status: Invalid → Incomplete
Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

OK, it doesnt seem to be related to my script.
In my script I set as root (after booting) CRYPTDISKS_ENABLE to Yes in /etc/default/cryptdisks.
Then I restart the crypdisks service, enter the password, it tries to mount the disk, and I put a No in /etc/default/cryptdisks for the next boot.
Works like a charm in 9.10.

If both /etc/crypttab has an entry and /etc/default/cryptdisks has an CRYPTDISKS_ENABLE=Yes the 10.04 systems boot normally without asking for a password.
I'm however not able to use 'service cryptdisks restart' to get a password prompt to enable my encrypted disk.

If ENABLE_AT_STARTUP=No in /etc/default/cryptdisks is set (as I use succesfully on 9.10) the 10.04 systems hang at boot.
On my server system I can log in via SSH then, but my desktop system is useless.

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

sorry, ENABLE_AT_STARTUP should be CRYPTDISKS_ENABLE, of course.

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

If you have a hung plymouthd process again, please attach to it with gdb ('sudo gdb /sbin/plymouthd $pid') and paste the output of the 'bt' command.

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

Hmmm, I'm puzzled again.

Just upgraded 10.04 server and desktop to kernel 2.6.32-20.

Desktop starts up fine (without asking for a password).
I'm able (from commandline) to start my encrypted disk with service cryptdisks restart now.

On server I still have a hanging plymouth.

I'm getting kinda annoyed by this.
It's taking too much time, I have a job to do.

Just close the call, I will work my way through this and wait it out until the final release.

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

> Just close the call, I will work my way through this and wait it out
> until the final release.

You are the only user reporting this issue. If you're not able to provide the requested backtrace, it's unlikely that this will be resolved for the final release.

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

With all due respect, Steve, after all the instability problems with cryptsetup in the last 2 years, I'm wondering if I'm indeed the only user left ;-)

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

.. and it's 10.04 BETA, so I'm not sure how many users there are.

But OK, I've attached the gdb backtrace output.

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

with debugging symbols:

gdb /sbin/plymouthd 250

(gdb) bt
#0 0x00007f99c2742500 in write () from /lib/libc.so.6
#1 0x00007f99c2c0bd8b in ply_write (fd=7, buffer=0x40a7d0, number_of_bytes=<value optimized out>) at ply-utils.c:306
#2 0x0000000000404797 in ply_boot_connection_on_request (connection=0x80ad70) at ply-boot-server.c:633
#3 0x00007f99c2c030f6 in ply_event_loop_handle_met_status_for_source (loop=<value optimized out>) at ply-event-loop.c:1025
#4 ply_event_loop_process_pending_events (loop=<value optimized out>) at ply-event-loop.c:1291
#5 0x00007f99c2c039d0 in ply_event_loop_run (loop=0x800140) at ply-event-loop.c:1312
#6 0x000000000040a224 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1911
(gdb)

and the same for plymouth:

gdb /bin/plymouth 802

(gdb) bt
#0 0x00007fa115f37cb3 in epoll_wait () from /lib/libc.so.6
#1 0x00007fa1161d8f2b in ply_event_loop_process_pending_events (loop=0x1a28010) at ply-event-loop.c:1248
#2 0x00007fa1161d99d0 in ply_event_loop_run (loop=0x1a28010) at ply-event-loop.c:1312
#3 0x00000000004039ed in main (argc=<value optimized out>, argv=<value optimized out>) at ./plymouth.c:1127
(gdb)

Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

> after all the instability problems with cryptsetup in the last 2 years

I have to correct myself on this, it's Ubuntu boot process that made it instable

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

Ok, it looks like what we have here is a blocking write from plymouthd to some client that has stopped listening. There's not enough information to tell us what client or why, but I think it's a bug that the plymouth server doesn't have a sensible timeout for writes.

If you have time to also track down what process is the client connection for this socket, we would certainly like to fix this end of the problem as well.

> With all due respect, Steve, after all the instability problems
> with cryptsetup in the last 2 years, I'm wondering if I'm
> indeed the only user left ;-)

Oh, there are definitely quite a few cryptsetup users around, and I've heard from many of them through the Lucid development cycle - and a lot of effort has gone into fixing their bugs for 10.04 LTS (and my own bugs, since I'm a cryptsetup user myself). This particular bug hasn't come up before now.

Changed in plymouth (Ubuntu):
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
letstrynl (letstry-deactivatedaccount) wrote :

Might that process be 'mountall', like I mentioned in #9?

message was:

mountall: Plymouth command failed

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

Yes, it's very possible that mountall is the process in question. Is mountall also still running after boot?

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

Looks like bug #554737 is the same issue; marking this as a duplicate.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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