Upstart doesn't activate luks volumes (also non luks) in cryptsetup

[Gabriel Ambuehl]

My laptop's home is a LUKS encrypted volume that's listed in crypttab to be mapped to /dev/mapper/home which worked wonderfully in dapper (i.e. boot interrupted, asked for pw, continued), in edgy however boot freezes, after a while the splash goes away, I get to single user and fsck complains about not being able to check /dev/mapper/home (which is in fstab) because the LUKS volume was not activated. Activating the volume by hand lets the boot process continue.

[Scott James Remnant (Canonical) (canonical-scott)]

Not an upstart bug, cryptsetup is incorrectly accessing the console to ask for input during boot

[Dennis Austmann (daustmann)]

Same problem here, encrypted volumes not mapped. I could see cryptsetup messages briefly flowing by during boot, so it really looks like upstart calls cryptsetup to map these volumes.

[Scott James Remnant (Canonical) (canonical-scott)]

sysv-rc calls cryptsetup, as it iterates /etc/rc?.d

[Gabriel Ambuehl (gabriel-ambuehl)]

Is cryptsetup perhaps being loaded and sent to the background detached from the console? If I boot the kernel without splash I see it complaining about not being able to read the password. It definitely needs to be run interactively.

[Scott James Remnant (Canonical) (canonical-scott)]

It's loaded detached from the console, which is why it has code at the top of the cryptsetup.functions file to explicitly reattach it to the console.

Unfortunately it appears that it may also need that to be its "controlling tty"

[Projekt (projekte)]

Same problem here. I get this message two times before it tries to mount my partition:

> Enter LUKS passphrase: Command failed: error reading passphrase

Init/upstart offers me to enter root-pw to login, but even with this login I get the same error. After boot is completed I can log into a console and start cryptsetup.

Is there any workaround yet? It annoys me to log into a console and restart /etc/init.d/cryptdisks manually each reboot.

[naheed (naheed)]

Quite annoying bug each time you boot the system.

[anwe (wegener)]

no news on this?

imho we are talking about a very important feature ...

[Norm Walsh (ndw)]

I can confirm the behavior as well, FWIW. And it is certainly annoying...

[Norm Walsh (ndw)]

Also FWIW, this is probably the same issue as bug #56319.

[Reinhard Tartler (siretart)]

this bug is reproducible. Importance high, because this is a regression from previous ubuntu releases. Before, with sysvinit, it was possible to have filesystems like /home mounted at boot-time.

[Scott James Remnant (Canonical) (canonical-scott)]

Note that this is also a universe package, so it's very low priority for main developers.

The problem appears to be that whatever asks for the password does so from /dev/tty, which isn't openable.

[Reinhard Tartler (siretart)]

any progress on this? can we target this for edgy?

[Norm Walsh (ndw)]

Ok. What is the supported mechanism for reading user input during the boot process? I'm happy to attempt a patch.

[Matthias Hilbig (hilbig)]

An alternative to reading the password from console might be to use pam_mount, to mount the encrypted filesystem when the user logs in.

Here is a description of using pam_mount together with dmcrypt:
http://deb.riseup.net/storage/encryption/dmcrypt/

[Norm Walsh (ndw)]

Yes, if it was just the home directory, that would be a possibility. But I also encrypt a partition that daemons (e.g., Apache) need, so it's not really practical to postpone it all to login time.

With respect, it seems to me that even if cryptdisk is in Universe, this is a pretty substantial regression.

If upstart really can't be tuned to support this, I'd be hard pressed to support upstart (not that anyone's really going to make any decisions based on what I would support, of course).

[Scott James Remnant (Canonical) (canonical-scott)]

This has absolutely nothing to do with upstart.

This bug is caused by the decision to not have standard input or output available to boot scripts by default.

If we still used sysvinit, the same bug would be present

[Scott James Remnant (Canonical) (canonical-scott)]

I have a proposed fix for this, could somebody who uses cryptsetup try this...

Edit the init.d script, at the top you'll find some code that looks like:

stdin=`readlink /proc/self/fd/0`
if [ "${stdin#/dev/null}" != "$stdin" ]; then
    exec </dev/console >/dev/console 2>&1
fi

Modify that so it reads:

stdin=`readlink /proc/self/fd/0`
if [ "${stdin#/dev/null}" != "$stdin" ] && [ "$ON_VT" != "yes" ]; then
    exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` $0 "$@"
fi

[jott (ottjochen)]

The patch works somehow, in the sense that it is now possible to enter
something. But
* the boot process continues, so that the graphical system pops up
before it is possible to enter the complete passphrase. Particularly,
mountall.sh is executed (and the crypted partitions are not mounted...).
* the passphrase is shown as it is typed.

[Scott James Remnant (Canonical) (canonical-scott)]

The alternate fix is to add "console owner" to /etc/event.d/rcS and /etc/event.d/rc2

[Scott James Remnant (Canonical) (canonical-scott)]

Oh, add "-w" to the openvt call

[jott (ottjochen)]

For me, both patches work, but the passphrase is still displayed (which
was never the case before...)

[Reinhard Tartler (siretart)]

I can confirm jott's observations.

When using cryptsetup on the shell (manually), the password is hidden. When used via the init script, the passphrase is shown in plaintext!

[Norm Walsh (ndw)]

Oddly, I can't confirm those observations. The patches work for me and the password is not displayed when used via init. Very odd. I saw that upstart was updated recently, maybe that changed something?

[Matthias Hilbig (hilbig)]

The init script fix works for me too. When I started ubuntu with the kernel parameters quiet and splash, the password was visible on the console. When I removed quiet and splash the password was not visible.

[Reinhard Tartler (siretart)]

I can confirm that removing 'splash' from the boot options, together with scott's patch solves the problem for me.

I'm not sure what this has to do with usplash, but I created a bugtask for it and leave it unconfirmed.

[Reinhard Tartler (siretart)]

I prepared a new upload with the fixes and workarounds so far.

I had to disable translations because of an unsubstituted MKINSTALLDIRS variable in Makefiles. Debian's cryptsetup pakage doesn't run automake at build time, and we have probably no time left to investigate that issue, so better release a package which doesn't FTBFS and has the workarounds for making this package usable.

[Hamish Downer (mishd)]

The fix worked for me :)

As a possible improvement to the code, to include the old option (ie "ON_VT" == "yes" )

stdin=`readlink /proc/self/fd/0`
if [ "${stdin#/dev/null}" != "$stdin" ]; then
    if [ "$ON_VT" != "yes" ]; then
        exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` $0 "$@"
    else
        exec </dev/console >/dev/console 2>&1
    fi
fi

[Hamish Downer (mishd)]

Oh and I had to do a little searching for the file (as no one seems to mention it in the text above). The fix should be applied to

/lib/cryptsetup/cryptdisks.functions

(I'm not familiar with patch, so after a little blundering around failing to get it to work I went for the direct edit).

[loko (arph)]

I did what mish says above, but for me the fix don't work.

i get a command prompt, with this:

Enter Password: Enter Password: there must be a error, cause it seems that the second "Enter Password" is inserted automaticaly.when i then try to enter my real password (plaintext) i get an error about a wrong password and mounting it later manually fails with something that says cannot read keyfile or so.

[loko (arph)]

according to a tip from somebody, i forgot to change the line:

 exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` $0 "$@"

to

 exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 "$@"

Now it works, but in plaintext like some other users posted before.
maybe this can be changed in the near future.

[Zak Kipling (zak-k)]

I'm using loop-aes for encryption, and experiencing similar issues when /etc/init.d/mountall.sh attempts to mount the encrypted volumes listed in /etc/fstab with loop= and encryption= options.

Adding "console owner" to /etc/event.d/rcS fixed that, but I also found that the password was echoed to the screen unless I removed "splash" from the boot command line.

Instead, I added the following to do_start() in /etc/init.d/mountall.sh, based on the suggestions above:

        local stdin=`readlink /proc/self/fd/0`
        if [ "${stdin#/dev/null}" != "$stdin" ]; then
                exec /usr/bin/openvt -s -w /etc/init.d/mountall.sh "$@"
        fi

This seems to work correctly with or without "splash". Note that I found "openvt -s -w" to work better than "openvt -w -f -c `fgconsole`" in that regard -- ie switching to a new console rather than using the current one (which splash is potentially interfering with).

The ON_VT part doesn't seem to be necessary, since once we're running on a VT, stdin will be /dev/tty<something> and the "if" block will be skipped anyway.

Another point to note is that /usr might not be mounted yet when these scripts run, if it's not part of the root fs -- in which case openvt won't be available.

[Christoffer Kjølbæk (ostehamster)]

Isn't this a problem with cryptsetup? I have a setup where a partition on my harddrive is encrypted with a key. This key is saved in a file, encrypted with openssl. Then I use pam_mount to mount it, whenever I log in.

I have this on two laptops, so when the first laptop was reinstalled with Edgy, I found out that I couldn't mount the encryptet system anymore. Cryptsetup didn't complain, but mount couldn't find the ext3 filesystem that should be on the device. I made a new encrypted partition using cryptsetup, which works just fine.

When I came to installing edgy on the other laptop, I wrote this info down:
1. The unencrypted key
2. The first ten lines from a hexdump of the encrypted partition
3. The first ten lines from a hexdump of the unencrypted partition “mounted” on /dev/mapper/_dev_hda3 through cryptsetup

After installation of Edgy and cryptsetup, I did the same as above:
1. The unencrypted key was the same, which must indicate that openssl works like in Dapper
2. The first ten hexdump lines of the encrypted partition was the same, so the partition might not have changed (I should have made a MD5SUM of the entire partition, but I am quite sure it is unchanged.)
3. Then I made a hexdump of /dev/mapper/_dev_hda3 after mounting it with cryptsetup, which wasn’t like the one from the Dapper installation. Cryptsetup didn’t complain about anything, but my guess is that the version of cryptsetup in Edgy don’t work the same way as in Dapper.

I might be wrong, but I can’t see what else should cause this?

Regards
Christoffer

(By the way, this is how I have made my setup: http://www.kjoelbaek.dk/linux/encrypted.php)

[seldon7 (ubuntu-pengo)]

hey - i've got a workaround that I use, but not a fix.

ive set up an encrypted partition on /dev/hdb3

to get it to ask for the password when gnome loads up (and mount it then), ive taken the reference to it out of /etc/fstab, and included it into /etc/pmount.allow

then in the gnome startup programs (preferences>sessions>startup programs) ive added:
gnome-terminal -e "pmount /dev/hdb3"

so the LUKS password prompt shows up each time gnome starts, and mounts the disk. i prefer this anyway to a password prompt half way through boot up.

not a fix, though, but it might help someone.

[Jari Kankaala (jari-kankaala)]

Hi,

I'm also trying to get encryption to work under Edgy Eft. The tip given above seems to work, but after entering the LUKS password I get dumped into a root shell. I can exit and everything seems to continue as normal. Is there anyway to avoid getting into the root shell?

The tip I followed (I put this into /lib/cryptsetup/cryptdisks.functions):
stdin=`readlink /proc/self/fd/0`
if [ "${stdin#/dev/null}" != "$stdin" ] && [ "$ON_VT" != "yes" ]; then
    exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 "$@"
fi

[Jari Kankaala (jari-kankaala)]

Hmmm, this only seems to be true when I boot with an image created by "yaird". The Ubuntu one works fine. Sorry guys. I'm trying to follow this but I'm adapting it to Ubuntu:
http://www.debianhelp.org/node/1116

[Swen Thümmler (swen-thuemmler)]

I have solved this issue for my crypted root filesystem by making the following modification to /usr/share/initramfs-tools/scripts/local-top/cryptroot:
--- cryptroot.orig 2006-11-12 12:31:08.000000000 +0100
+++ cryptroot 2006-11-12 12:30:41.000000000 +0100
@@ -160,7 +160,11 @@

 # Loop until we have a satisfactory password
 while [ 1 ]; do
- if [ -x "/sbin/cryptgetpw" ]; then
+ if [ -x "/sbin/usplash_write" -a -p /dev/.initramfs/usplash_outfifo ]; then
+ /sbin/usplash_write "INPUTQUIET Password:"
+ $cryptcreate < /dev/.initramfs/usplash_outfifo
+ /sbin/usplash_write "CLEAR"
+ elif [ -x "/sbin/cryptgetpw" ]; then
                /sbin/cryptgetpw < /dev/console | $cryptcreate
        else
                $cryptcreate < /dev/console

This works for me (in the 2 tests I have made :-)).
Hope this helps.

--Swen

[Jari Kankaala (jari-kankaala)]

Vielen Dank Swen!

Together with the modifications of /lib/cryptsetup/cryptdisks.functions it works like a charm.

//Jari

[Paul Sladen (sladen)]

Keybuk: is Swen's patch above the Right Thing To Do(tm)?

[Ondřej Nový (onovy)]

hi, i have same problem. i have /crypt mounted as encrypted partition. I'm using passphrase. i don't' have root partition encrypted so swen's patch doesn't fix my problem :( - it's only for crypt root partition.

[Stefan Rehm (stefan-rehm)]

Did you try Marc Schiffbauer`s Patch (https://launchpad.net/products/upstart/+bug/62751/comments/53)? Except for the password being printed plain text to the console it seems to work fine for LUKS volumes even with usplash.

Extending the patch to support other dm-crypt volumes is only a matter of modifying the do_noluks() function in the same way as he did with do_luks().
There is already a bug report (#55159) for the password echoing. This is caused by usplash not disableing the echo of its stdin.
With the "stty" command it is still possible to disable it in any shell script, but this is IMHO definitivly the wrong place (otherwise the usplash INPUTQUIET function should be renamed INPUTHIDDEN ;) ). But as the bugreport is still undecided it seems necessary to (temporarily) fix it in cryptdisks.functions.
The attached patch is again based on the original patch by Marc Schiffbauer and adds both no_luks usplash support and disabled stdin echo (by guarding usplash_write commands with "stty --file=$stdin -echo"). It also checks more strictly for a running usplash daemon as the existance of the fifo files just indicates that there once was a daemon running, but this may not be the case anymore when the function is called (at least they dont seem to get deleted).

I tested it over the weekend with standard dm-crypt and Luks volumes using keyfiles and passphrases to decrypt and (unlike my last futile attempt) this one worked fine with or without usplash. I did not test ssl and gpg encrypted keyfiles since there was no change within the keyscripts.

[Max Ischenko (ischenko)]

I didn't bother with Marc's patch when I found a one-liner and I'm OK without usplash.

[Hunz (ubuntu-hunz)]

I 'fixed' (since stty -echo didn't work) the password echo problem using this trick:

added echo -n -e "Enter password: \033[40;30m" before the
$CRYPTCMD $PARAMS create $dst $src ... line
and echo -n -e "\033[40;37m" after it

it sets the fore+background color to black/black using an ansi color escape sequence and restores it to white/black using the same method afterwards

not nice but works for me

:-]

[Reinhard Tartler (siretart)]

cryptsetup (2:1.0.4-8ubuntu2) feisty; urgency=low
 .
   * fix and improve initramfs hook: terminate usplash if running, since
     adequate secure text input is not possible with usplash ATM
   * usplash support: Terminate usplash before asking a password.
     Closes https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/62751

[Lars Volker (lv)]

today i spent a whole 10hours on updating from dapper to edgy. Most of the time i spent while trying to debug the latest cryptsetup-package i compiled from feisty sources - with the final conclusion that it couldn't work on my installation because the patches suggested in this bug rely on /usr/bin/openvt which won't work for anyone who has /usr on a separate volume like i do.

I can't however think of a better circumvention than commenting out that lines and replacing <&1 by "< /dev/console > /dev/console 2>&1" where necessary.

Would one with greater knowledge of the situation please change the scripts to make them run on systems with separate /usr.

Thanks
Lars

[Sven Lilienthal (sven-lilienthal)]

Using feisty with cryptsetup 2:1.0.4+svn26-1ubuntu1 I still don't get a proper password prompt. Usplash is terminated correctly but the console isn't switched. If I switch it manually, I can't enter the password anymore. (I can write but all I write is shown in plain text).
Which means I have to wait a moment until usplash terminates ,enter the password and afterwords switch to console 1.

[Hamish Downer (mishd)]

Don't know if it's related but the latest cryptsetup update in edgy appears to have broken setting up my (non luks) partition. I have usplash turned off, but have been unable to get a passphrase prompt. I have tried manually putting in the fixes to /lib/cryptsetup/cryptdisks.functions but have had no success. In the end I had to use cryptsetup from the command line (which worked fine).

The version of cryptsetup I now have is 2:1.0.4+svn26-1ubuntu1~edgy1 - command line reports

$ sudo cryptsetup --version
cryptsetup-luks 1.0.5

More on ubuntuforums at

http://www.ubuntuforums.org/showthread.php?p=2291494

[loko (arph)]

like mish, i have the same problems with 2:1.0.4+svn26-1ubuntu1~edgy1 on edgy.

it totally broke my system. i couldn't mount the encrypted home-partition.

i switched back to 1.0.3, but now i get this error, the password-promt on boot is not shown anymore, except this error:

"enter passphrase: command failed: key reading error"

it's annyoing that this bad piece of software is released as a "tested" update.

what has this update done to my system in case that even downgrade to 1.0.3 didn't solve the problems?

[Hamish Downer (mishd)]

A little further information. On my other (luks) system it works fine. Anyone got ideas as to what might be the non-luks specific bug?

[Ondřej Nový (onovy)]

you must edit /etc/crypttab and add to last row: 'vol_id'
in previous version this was default, now you must explicit add it.

my crypttab:
onovy@lajka:~$ cat /etc/crypttab
# <target device> <source device> <key file> <options>
crypt /dev/hda2 none vol_id

[loko (arph)]

ok, adding vol_id does the trick.

i now installed feisty and there is no need to add vol_id anymore. but i got another problem.

The boot-splash switches to console, where i can see "Starting Cryptodisks" (or similar message) but it didn't go automaticaly to the next step, "Enter Passphrase".
I always have to press a button (not enter, only the letters do it) then the console switch to the message "Enter Passphrase" and now i can enter the password. Without pressing a letter-button, nothing happens and it waits forever.

[sander (sander2)]

hi!
tonight i installed the latest feisty and set up an encrypted root partition. the enter passphrase dialog showed up but was interrupted by some USB kernel messages. after pressing enter the enter passphrase dialog showed up again and i entered my (correct) passphrase. i got a message that the passphrase is wrong. after reading this bug report i tried adding another *simple* passphrase that doesn't contain any "strange" symbols like ~. using the simple passphrase i can unlock the keyslot! looks like you can't enter symbols that need "two fingers", or at least you can't have a ~ in your passphrase!

[Gabriel Ambuehl (gabriel-ambuehl)]

> can't enter symbols that need "two fingers", or at least you can't have a ~
> in your passphrase!

Could it be that you use a non US keyboard before the keymap is actually
initialize?

[Fabián Rodríguez (magicfab)]

Let me know if I can help reproducing / testing this bug. I could test this on most any Ubuntu version pretty quickly.

[Fabián Rodríguez (magicfab)]

As this package is in the " universe " repository, is is unlikely it will get any non-critical / non-security updates in any other versions than Gutsy. If anyon can test this against Gusty Tribe 4, I think it would help in determining if this bug can be closed.

There have been a number of updates since 1.0.4+svn26-1ubuntu1, thank you for providing feedback on any remaining issues. The complete changelog is at:
http://changelogs.ubuntu.com/changelogs/pool/universe/c/cryptsetup/cryptsetup_1.0.4+svn29-1ubuntu4/changelog

[Floris Bruynooghe (flub)]

Additional issue with crytroot setup in initramfs.

Usplash exits as it should, and the password gets read from console. However the password prompt is never displayed. To solve this I changed line 210 (feisty) from:

$cryptcreate < /dev/console

to

$cryptcreate < /dev/console > /dev/console 2>&1

Hope this is useful

[Reinhard Tartler (siretart)]

I have to admit that I lost a bit track of this bugreport. In gutsy, I don't have any problems mounting my LUKS volume. I see a lot of feisty reports in this bugreport, which probably won't get fixed, please open another bugreport with [feisty] in the subject.

Is anyone seen this problem in gutsy for now?

[Gabriel Ambuehl (gabriel-ambuehl)]

Works ok in Gutsy for me. At least for non root volumes, as I don't have
cryptroot myself.

[faithful (strangecode)]

In Gutsty doesn't work for me the error I get is this:
exec: 34: env: not found.
I use luks with keyfiles so commented out this lines in /lib//cryptsetup/cryptdisks.functions:
## Always output to console
#stdin=`readlink /proc/self/fd/0`
#if [ "${stdin#/dev/null}" != "$stdin" ] && [ "$ON_VT" != "yes" ]; then
# exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 "$@"
#fi
This fixes my configuration but isn't a solution.

Cryptsetup version: 2:1.0.5-1ubuntu3.

[Reinhard Tartler (siretart)]

faithful <email address hidden> writes:

> In Gutsty doesn't work for me the error I get is this:
> exec: 34: env: not found.
> I use luks with keyfiles so commented out this lines in /lib//cryptsetup/cryptdisks.functions:
> ## Always output to console
> #stdin=`readlink /proc/self/fd/0`
> #if [ "${stdin#/dev/null}" != "$stdin" ] && [ "$ON_VT" != "yes" ]; then
> # exec env ON_VT=yes /usr/bin/openvt -f -c `fgconsole` -w $0 "$@"
> #fi
> This fixes my configuration but isn't a solution.
>
> Cryptsetup version: 2:1.0.5-1ubuntu3.

Scott, you added that part above to the cryptsetup initramfs scripts. I
pretty sure that env used to be in the initramfs, but now isn't
anymore. Do you know if there is a variant of the above which doesn't
use {/usr,}/bin/env?

  affects ubuntu/cryptsetup
  assignee keybuk

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Kjell Braden (afflux)]

Reinhard, correct me if I'm wrong but isn't the init.d call to cryptdisks.functions already in the rootfs instead of the initramfs?

I'm running gutsy, and this configuration works fine:

$ cat /etc/crypttab
croot32 /dev/sda11 none luks,cipher=aes-cbc-essiv:sha256
chome32 /dev/sda12 none luks,cipher=aes-cbc-essiv:sha256
cvar32 /dev/sda13 /cvarfile luks,cipher=aes-cbc-essiv:sha256
cswap /dev/sda6 /dev/urandom swap
$ cat /etc/fstab
/dev/mapper/croot32 / ext3 defaults,errors=remount-ro 0 1
LABEL=cvar32 /var ext3 defaults 0 1
LABEL=chome32 /home ext3 defaults 0 1
/dev/mapper/cswap none swap sw 0 0

The only patch I use is for usplash:
--snip--
--- /lib/cryptsetup/cryptdisks.functions 2007-09-23 16:29:57.000000000 +0200
+++ /lib/cryptsetup/cryptdisks.functions 2007-09-23 16:29:57.000000000 +0200
@@ -271,11 +271,15 @@
                        cryptsetup $PARAMS luksOpen $src $dst <&1
                else
                        if [ -x /sbin/usplash_write -a -p /dev/.initramfs/usplash_outfifo ]; then
- /sbin/usplash_write "QUIT"
- # saftey sleep !
- sleep 2
+ while [ "$tried" -lt "$TRIES" ]; do
+ usplash_write "INPUTQUIET Enter password for $dst ($src): "
+ PASS="$(cat /dev/.initramfs/usplash_outfifo)"
+ echo -n "$PASS" | cryptsetup $PARAMS luksOpen $src $dst > /dev/null 2>&1 && break
+ tried=$(( $tried +1 ))
+ done
+ else
+ cryptsetup $PARAMS luksOpen $src $dst <&1
                        fi
- cryptsetup $PARAMS luksOpen $src $dst <&1
                fi
        fi

--snip--

Hope that helps.

[Reinhard Tartler (siretart)]

no it doesn't. You are reenabling password input in usplash, which isn't a good idea with current usplash
(try switching virtual consoles when entering your password to find out why)

[Kjell Braden (afflux)]

Well, when starting without the splash parameter, everything works fine, too. I meant to say that I've done no changes to the cryptdisk.functions that would matter for this issue ;)

[Scott James Remnant (Canonical) (canonical-scott)]

env exists as a magic built-in in the initramfs busybox

[Reinhard Tartler (siretart)]

faithful: Please check if you really have no /usr/bin/env. (which is in coreutils). Your system seems to be broken in strange ways.

Gabriel: are you still experiencing this bug with current gutsy? I'm using cryptsetup on several machines in several configuration, and had no problems mentioned in this bugtrail. I'm therefore inclined to assume that the Problem of the original reporter has been fixed in the mean time.

[Reinhard Tartler (siretart)]

need more input on this bug

[Reinhard Tartler (siretart)]

zak, I'm rejecting the loop-aes-utils subtask, because this bug clearly isn't about that part. at least, it is not visible at in in the bugtrail what would need fixing in the loop-aes-utils package. If you still have the bug, please file a new bug. thanks

[faithful (strangecode)]

Ok my problem is resolved. Recent updates solved it.
Thanks.

[Reinhard Tartler (siretart)]

Due to the lack of responses that anyone can still confirm that the described problem still appears, and the recent feedback that an unrelated issue has been solved (thanks faithful for reporting back), I come to the conclusion that this bug has been fixed some time ago. I cannot really reproduce it in gutsy. I'm therefore closing this bug.

Please, if you think this bug is still valid, please consider filing a new bug with a clearer description than this one. Thanks!

[gpaharenko (gpaharenko)]

A problem still exists:

ubuntu-7.10-desktop-amd64

[loko (arph)]

I have to say that this bug is not completely solved.

Some problems still exist. this is what i experience.

Using gutsy, up-to-date as of 08.03.2008

Encrypted partitions: home and swap
Type of encryption: Luks

crypttab:

home /dev/sda3 none luks,retry=1,cipher=aes-lrw-benbi
swap /dev/sda4 /dev/random swap

fstab:

/dev/mapper/home /home ext3 defaults 0 0
/dev/mapper/swap none swap sw 0 0

During boot-up the following behavior i can report:

boot-up starts, splash goes away and i see "Starting early crypto disks..."
then there is "Enter LUKS passphrase:"

And i enter the passprase. After that i press "Enter" and can see "key slot 0 unlocked. command successful"

but then boot doesn't continues until i move my fingers over the touchpad. well, pressing any key doesn't let the boot-process continuing.
so it seems that there is an input expected which in my case only with the touchpad can be made.

after moving the fingers over the pad, i can see "Starting remaining cryptodisks..." and boot-up goes on.

could it be, that the swap is the problem or the order of the lines in the fstab/crypttab

Could this be explained and or confirmed by somebody?

[loko (arph)]

Well it seems that is is a problem with the encrypted swap.

i changed the lines in fstab and crypttab this way:

fstab:

/dev/mapper/swap none swap sw 0 0
/dev/mapper/home /home ext3 defaults 0 0

crypttab:

swap /dev/sda4 /dev/random swap
home /dev/sda3 none luks,retry=1,cipher=aes-lrw-benbi

in fact, it seems that for the encrypted swap an input is needed otherwise boot does not go on.

so in this case, i first see "Starting early crypto disks..."

and then nothing comes until i move my fingers over the touchpad. after i did this, "Enter LUKS passphrase" appears.
I enter it, press "enter" and boot-up goes on.

So is this a upstart problem, or a configuration problem?

[Patrick J. LoPresti (lopresti)]

/dev/random blocks until it has enough entropy to guarantee
randomness. That is probably why wiggling the touchpad gets things
going again.

If you have /dev/hwrandom, you can use that... Otherwise, you can use
/dev/urandom to avoid blocking, but theoretically this could give up
some security (since the random generator's internal state could be
predictable at boot).

[Hamish Downer (mishd)]

I think your problem is related to using /dev/random in your crypttab

swap /dev/sda4 /dev/random swap

/dev/random collects entropy from different parts of the system (including mouse/touchpad usage). I'm not sure, but I suspect entropy is not saved at shutdown, so entropy must be collected again at start up. /dev/random will block without enough entropy, and using the touchpad is putting some entropy into the random number system.

If you want it to not block, try using /dev/urandom instead. It is not quite as secure, but I think it is more than secure enough for the key for the swap partition.

For more on the differences between /dev/random and /dev/urandom, see

$ man urandom

(On reading that it mentions a way to save entropy on shutdown, though I think you would want to change the place to save it to not in /var/run as that is a filesystem in RAM created by ubuntu on start up).

[loko (arph)]

Patrick J. LoPresti and mish,

thank you both for the help.

indeed /dev/random is the problem. Like mish said i could use /dev/urandom. I don't have /dev/hwrandom, so the urandom solution or the script mentioned in the manpage of random is the one i need.

As a theoretically question, how can i use this script mentioned in the manpage? Mishs tip is helpful not to save entrophy in /var/run. but i stuck with putting the scripts at the right place.

I put them to /etc/rcS.d for sart-up and there i put it with a name like S25... but this seems not to working as i get something like "dd: cat unknown command" or something equal like that.

the shutdown-script i put in rc0.d and rc6.d but also there i don't know if this is correct and which numbers i should use. i assume it should be something like S... because if i understand this right, S is for starting the script. rc0.d and rc6.d are for shutdown and restart, if i am right.

can somebody help me with this please.

thanks in advance

[Patrick J. LoPresti (lopresti)]

What version of Ubuntu are you using?

On mine (7.10 aka. Gutsy), /etc/init.d/urandom already propagates the
random seed across reboots in /var/lib/urandom/random-seed.

This should make /dev/urandom very safe to use, assuming that file
itself is never compromised.

[loko (arph)]

I use 7.10 but i didn't know that urandom saves the random seed during start, restart and shutdown.

Everywhere on the net there can be read that urandom is not as secure as random is. but i am a bit confused now. how could it be that urandom is not as secure as random if uradom just saves the entropy of random and resores it when it's needed.

can you explain this to me?

[Patrick J. LoPresti (lopresti)]

It's a long story that depends on how you define "random" and
"secure". And this is really the wrong forum for this question and
answer. But I'll give it a whack anyway. :-)

/dev/random never hands out more bits than it has entropy available.
(It collects entropy from the timings of keyboard interrupts, mouse
interrupts, and the like; and it tries to conservatively estimate how
many bits of randomness each event adds to the pool.) If the entropy
estimator is conservative -- which its creators believe but which is
impossible to prove -- then /dev/random is perfectly random and
perfectly secure, in the sense that, from an attacker's point of view,
any one of the 2^N possible strings of N bits is equally likely to be
output.

/dev/urandom hands out as many bits as you ask for, using the truly
random state of /dev/random as a seed for a cryptographic
pseudo-random number generator (PRNG). So even if the /dev/random
entropy pool only has (say) 256 bits of entropy, /dev/urandom will
gladly give you 1000, 1 million, or 1 billion bits of output. In this
example, since there are only 256 bits of entropy, there are only
2^256 possible outputs, so each of the 2^1000, 2^(1 million) or 2^(1
billion) possible outputs from /dev/urandom is NOT equally likely. In
this sense, /dev/urandom is "less secure" than /dev/random. If the
PRNG is cryptographically strong -- which its creators believe but
which is impossible to prove (at present) -- then there is no
*practical* way to distinguish the output of /dev/random from that of
/dev/urandom... Because for practical purposes, 2^256 might as well
be 2^1000.

The point of preserving the entropy pool across reboots is to give the
entropy pool an initial state that is unknown to any attacker. In
other words, even if the attacker knows a lot about your system --
like what state it is in when you first turn it on -- he will not know
anything about your entropy pool as long as he does not know what is
in the saved state file.

Does this help?

[loko (arph)]

Yes that helps.

Thank you for the explanation.

[Josef Wolf (jw-raven)]

I have this problem after an upgrade from 9.04 to 9.10. With 9.04, the boot was interrupted and resumed again after I entered the passphrase

After upgrade to 9.10, the passphrase prompt appears and immediately the graphical login screen appears. I switch back with ALT+CTRL+F1, but no keystrokes are accepted. When I switch to tty2 and login, I can see cryptsetup and pinentry programs nag. I have to kill them several times, since they are restared again and again.

Eventually, cryptdisks gives up, but still a simple "/etc/init.d/cryptdisks start" don't work. I have to use force-start to get the disks started.