encrypted /tmp partition doesn't mount during boot after update to lucid

[mirirai]

After an upgrade from karmic to lucid (kubuntu) my luks-encrypted /tmp partition failes to mount during booting the system.

It then gives me the option to boot it manualy and then to continue with booting. The mounting of tmp works, but unfortunatly I'm not able to decrypt my ecrytptfs-encrypted home directory for some reason.
On the other hand, when I continue booting without mounting /tmp and then first login to a console (graphical login fails due to missing tmp-directory) and then mount tmp with sudo everything works fine.

Here is the relevant entry of my fstab:
/dev/mapper/tmp /tmp ext2 defaults 0 0

And this is what my cryptab looks like:
tmp /dev/disk/by-id/ata-WDC_WD800JD-55MUA1_WD-WMAMD5727339-part6 /dev/urandom tmp,cipher=aes-xts-plain,size=256

I'm not sure if this bug is related to https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/544812 so I decided to report it as a new bug for now.

[Victor Vargas (kamus)]

reassigned to cryptsetup package then

[mirirai (mirirai)]

I don't think its a duplicate of bug #522341 cause it doesn't work eather when I change the cryptab entry to

tmp /dev/sda6 /dev/urandom tmp,cipher=aes-xts-plain,size=256

[Steve Langasek (vorlon)]

With the new crypttab line, does /dev/mapper/tmp exist at the end of the startup sequence?

[mirirai (mirirai)]

yes, it does exist even from that point on when it ask me to mount it manualy within the boot-process.

$ ls -l
--> brw-rw---- 1 root disk 252, 0 Nov 15 14:11 /dev/mapper/tmp

[mirirai (mirirai)]

I mentioned that the system asks me to mount /tmp manually during the boot process (If I press "M" I get a root shell) and that when I mounted /tmp at that state I was unable to decrypt my ecrytptfs-encrypted home directory. Well, now I found out that it doesn't matter if I mount /tmp at that state or not. It suffices to open the root shell as mentioned above to not beeing able to decrypt my home directory (it seems that it doesn't accept my password, thought it's correct/ I tried several times).

Maybe that's another issue but it might be connected somehow with the /tmp-mount problem.

[Steve Langasek (vorlon)]

If /dev/mapper/tmp exists, then that doesn't appear to be a problem with cryptsetup, but rather a problem with mountall. Reassigning to that packagle.

The failure to decrypt the /home partition is probably unrelated. It may be caused by a change to cryptsetup's default ciphers; you may need to specify the cipher on the commandline when invoking cryptsetup, or specify it in your /etc/crypttab, depending.

[mirirai (mirirai)]

Thanks for your advice, so I better write an additional/look for a bug report for that /home-decrypt issue.

There's one think I don't understand. I use Ecryptfs and not Luks for my home-directory and I thougt /etc/crypttab is only related to Luks-partitions or am I wrong?

[quazgar (quazgar)]

Could the be a duplicate of bug #493480? That one seems to be delegated to cryptsetup again, though. The symptoms (/dev/mapper/tmp is created and manual mounitng works) look similar at least.

[quazgar (quazgar)]

The first workaround proposed in the first comment in bug #475936 works here (changing the running order of cryptdisks-enable and mountall). The only trouble left was the wrong permissions of /tmp, which could be easily fixed with

exec /bin/chmod 1777 /tmp/

in the post_stop section of /etc/init/mountall.conf.