cryptsetup prompt is overriden by upstart and xsplash in Karmic

[Saivann Carignan]

Binary package hint: cryptsetup

My computer has /dev/sda5 (mounted as /) and /dev/sda7 (encrypted, mounted as /media/X).

My /etc/crypttab file contains this :
X /dev/sda7 none luks

My /etc/fstab file contains this :
/dev/mapper/X /media/X ext4 defaults,relatime 0 0

The problem in Karmic is that the password is asked in the console (since we don't use usplash anymore), but xsplash suddenly hide the cryptsetup prompt, and the computer continues to boot while cryptsetup still waits for the password in background, but will never get it as the user can't access console anymore due to Xserver.

ProblemType: Bug
Architecture: i386
Date: Mon Sep 21 15:42:18 2009
DistroRelease: Ubuntu 9.10
Package: cryptsetup 2:1.0.6+20090405.svn49-1ubuntu4
ProcEnviron:
 LANG=fr_CA.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-10.34-generic
SourcePackage: cryptsetup
Uname: Linux 2.6.31-10-generic i686

[Saivann Carignan (oxmosys)]

Scott James Remnant : subscribed at your request in bug 430496 since it does not seem to be fixed in that situation.

[Steve Langasek (vorlon)]

As of the latest upload of initramfs-tools, this should be working again, but only by accident: cryptsetup is now setting up usplash unconditionally in the initramfs, whereas it should only do this if it's needed for decrypting the root filesystem or swap. So I'm leaving this bug open since we should have a separate check for usplash in the cryptdisks init script using whatever mechanism will be used for fsck prompting.

[Steve Langasek (vorlon)]

Having looked into this, it's too much effort to bother with to get usplash /not/ started in initramfs for the case where cryptsetup is not needed for the rootfs; so I'm wontfix'ing this bug for karmic and downgrading it since we effectively will always have usplash already running before reaching this point.

[Saivann Carignan (oxmosys)]

Steve Langasek : You probably means "upstart"? Anyway that sounds correct AFAIK, unless there was some easy way to prompt the password through xsplash rather than usplash or console. Since root filesystem does not depend on cryptsetup in this case, upstart does not need to wait on cryptsetup while it asks the password, the real problem here is simply that cryptsetup prompt is not accessible. Is there such feature in xsplash that I could take a look at in order to bring a potential fix?

[Ulrich Lukas (ulrich-lukas)]

Hi, Steve,

the current situation is unbearable.

If I set up my encrypted /home exactly like all the HOWTOs say (i.e. manually after installation), the password prompt is not accessible unless switching back to the first text console. (And even there the password prompt is horribly broken and cluttered with other boot messages, but that is another story)

This is breaking working setups.

Unless the password prompt functionality is added to upstart, xsplash or KDM (or GDM) in the next few days, leaving things as they are is a really bad option prior to the impending Karmic release.

[Saivann Carignan (oxmosys)]

Ulrich Lukas : Please don't change the bug status, Triaged is more appropriate than Confirmed here. As mentionned in previous comments, this bug affect very rare user customisations where the root filesystem does not depend on cryptsetup. In your case, you can easily use a workaround to enjoy Karmic without that bug, you just need to edit /etc/initramfs-tools/conf.d/cryptroot so usplash ask you the passphrase from the initramfs (before ubuntu starts to boot, like when you install ubuntu on cryptsetup partitions using ubuntu alternate CD).

Or you can simply copy these commands (in good order) in a terminal (and take care to change /dev/sda1 by the device name of your real cryptsetup partition). These will do all the job for you.

sudo bash
echo 'CRYPTROOT=target=pvcrypt,source=/dev/sda1' > /etc/initramfs-tools/conf.d/cryptroot
update-initramfs -u

If you need more assistance, please don't comment in the bug report, you can contact me directly if you want, or use ubuntuforums or launchpad answers.

[Ulrich Lukas (ulrich-lukas)]

Thanks for the reply and the workarounds, but please consider that there are systems with custom kernels and without an initramfs.

While I admit that that concerns a smaller number of installations, using a non-encrypted root partition with encrypted /home, /tmp, /var is best practice if you run Ubuntu on a portable computer.

[5tan (kamildor)]

First, I'm sorry for my bad english, but I want help with this cryptsetup problem :)

Saïvann Carignan: according to:
> My /etc/crypttab file contains this :
> X /dev/sda7 none luks
>
> My /etc/fstab file contains this :
> /dev/mapper/X /media/X ext4 defaults,relatime 0 0

echo 'CRYPTROOT=target=pvcrypt,source=/dev/sda1' > /etc/initramfs-tools/conf.d/cryptroot
should be:
echo 'CRYPTROOT=target=X,source=/dev/sda7' > /etc/initramfs-tools/conf.d/cryptroot

And I advice to make copy of initrd - for kernel 2.6.31-14-generic it should be:
cp /boot/initrd.img-2.6.31-14-generic /boot/initrd.img-2.6.31-14-generic.copy

*For other currently running kernel number
cp /boot/initrd.img-`uname -r` /boot/initrd.img-`uname -r`.copy

AND call update-initramfs with -k option
update-initramfs -u -k `uname -r`

For what? If initrd.img won't boot system then in grub start menu we need edit line with copy of initrd.img

And again: I'm very sorry for my english

[Steve Langasek (vorlon)]

On Fri, Oct 30, 2009 at 03:41:56AM -0000, Ulrich Lukas wrote:
> While I admit that that concerns a smaller number of installations,
> using a non-encrypted root partition with encrypted /home, /tmp, /var is
> best practice

It most certainly is not best practice.

[Cédric Dufour (cdufour-keyword-ubuntu-086000)]

Well, the EXACT (and USB-disk-proof) syntax is:
  echo 'target=#TARGET#,source=/dev/disk/by-uuid/#UUID#' > /etc/initramfs-tools/conf.d/cryptroot
(thus leading to a '/dev/mapper/#TARGET#' device; otherwise, you get a '/dev/mapper/cryptroot' device)

Also, make sure to add the proper modules in '/etc/initramfs-tools/modules'. Mine are:
  dm_crypt
  aes_i586
  gf128mul
  lrw
(this depends on which ciphers you use; 'diff' the 'lsmod' output before/after activating the LUKS partition to find out which additional modules may be needed)

As for "best practices": I personally see no benefits (more like drawbacks) in encrypting my system libraries, executables, package cache, etc. on a netbook with a slow CPU...

Cheers

[5tan (kamildor)]

Cédric Dufour,
You right! In my testing system target is /dev/mapper/cryptroot and it was OK.
But when I try change it to anything else... device path is still /dev/mapper/cryptroot

source=/dev/SOMETHING (where SOMETHING means something like hda2, sda1, sda2, ...) should also work, but your way is probably better for almost all cases.

"best practices": with not encrypted libraries, executables, etc. any person with usb-live or cd-live and access to your computer can replace your libraries and executables with "extended" functionality (it can write on disk or send by network your files and/or passwords) Anyway: I can see benefits not encrypted libraries, executables... And YES, not encrypting of root in some cases may be reasonable. :)

[GOo (francesco-follonica)]

I tried to do an install of karmic amd64 from alternate installation disc with encrypted root, /var, /home, swap partitions on top of a RAID10 fp2 4 disks array.

Results are:
System boots then xsplash starts asking me for the passphrase of the root partition. I enter the passphrase then I get to the console:

sreadahead main process terminated with status 1
....
enter passphrase to unlock /dev/mapper/home-data_crypt

Not able to do this since xplash suddenly hides the console prompt:

One or more of the mounts listed in /etc/fstab cannot yet be mounted
/home: waiting for /dev/mapper/home-data_crypt
Press ESC to enter a recovery shell

In the recovery shell I am not able to do anything since typing is nearly inhibited. Just got few random characters out of my keyboard.
So, same behavior here but also with encrypted root fs.

[Cédric Dufour (cdufour-keyword-ubuntu-086000)]

@5tan: Strange, my 'target=...' in '/etc/initramfs/conf.d/cryptroot' IS respected in my two LUKS setups, one on Karmic and the other one still on Jaunty.

[vbargsten (vbargsten)]

@Ulrich Lukas
I agree that only encrypting home, var, tmp.. is a good way to secure personal data while keeping the system fast.
@5tan
Indeed security is gone if someone unnoticedly gets hardware access and returns modified hardware/software; This is true even if the whole root filesystem is encrypted too (think of hardware keylogger/editing mbr code...).

There are several bug reports concerning broken/hidden/vanished cryptsetup password promt at boot and I can not understand why this should not be a serious bug.

I recently changed from opensuse 11.2 to xubuntu 9.10, because of kde3 not beeing supported anymore and kde4 too memory consuming for my laptop. I have an encrypted data partition with home var tmp ....
After updating crypttab of newly installed xubuntu, I am prompted for my password at boot, but I have to enter the password fast before the prompt is gone.
see 475293 468208 468208 461442 ....

Tried to use cryptmount(-early) etc. instead of crypttab. Doesn't work yet automatically, though invoking cryptmount-early init script manually asks for password and creates /dev/mapper/... entry

[gkey (gmkey)]

To me it seems that cryptsetup has two startup scripts (in /etc/init.d):

cryptdisks-early
cryptdisks

AFAIK both read /etc/crypttab and cryptdisks-early reads the 1st line
(probably what's needed to boot) and cryptdisks reads the remaining lines.
For some reason upstart doesn't wait for the entry of passwords at the
prompt of cryptdisks.

[Saivann Carignan (oxmosys)]

AFAIK, The reason is that upstart never wait for a task to end before starting another one, unless a task depend on the first task. No task depends on cryptsetup and actually no task should depend on it. However, many tasks depend on root filesystem and won't start until filesystem gets available. That is why cryptsetup prompt only works when root filesystem depends on cryptsetup.

Therefore the best way to handle this at the moment is really throught initramfs as once the system starts to boot, cryptsetup can't have the power to stop the computer from booting. If xsplash is about to have that functionnality, a potential fix would be to ask the passphrase through xsplash like it did in the past with usplash, at the exception that xsplash would need to hide gdm or prevent the login screen to appear until user answered the prompt.

[vbargsten (vbargsten)]

cryptsetup can't have the power to stop <- why not?
If I need the filesystems, everything depends on it, so everything else should wait (or at least it should be possible to set that manually). I mean, if I don't set the noauto option in crypttab, I want 'auto' and not manual.

[Saivann Carignan (oxmosys)]

vbar : Giving the ability to a software to freeze the boot can lead to many problems, this is not how upstart works. Upstart let you do it in a very more flexible way as you can define which tasks require each other, which slightly reduce probabilities of boot problems. This concept boost boot preformances by starting tasks by events, and many tasks at the same time.

What you say is already implemented, most of task depend on root filesystem, but the computer does not need other filesystem than root to be mounted to boot correctly, therefore it makes no sense to depend on other filesystems then root. If your Windows NTFS partition doesn't want to mount because it is unclean, or if your fstab is misconfigured, would you be happy to see your computer wait infinitely for it? Anyhow, there is no reason why the computer wouldn't continue to boot at the same time that it asks your password.

This bug only need something to be done that would be compatible with new setup. As I said earlier, maybe that implementing password prompt via xsplash would be a potential solution. Ubuntu developer probably alreaday have a idea about how to fix this problem in the future.

Until that moment, it's possible to mount a cryptsetup partition from initramfs or directly in GNOME, so technically speaking, no real feature as been lost in this bug. Cryptsetup simply needs to be configured differently than before.

[Ulrich Lukas (ulrich-lukas)]

vbar wrote:
> cryptsetup can't have the power to stop <- why not?

Because that would interfere with Ubuntu's boot speed ambitions, I
recon. I.e. there might be cases (e.g. with key files, RFID-cards etc.)
where it might make sense to continue booting while cryptsetup does its
work unattendedly.

Saïvann Carignan wrote:
> That is why cryptsetup prompt only works when
> root filesystem depends on cryptsetup

So, isn't it a solution to simply make root filesystem depend on
cryptsetup in cases where interactive input is needed? I.e. when no
other (xsplash, key file) method is used?

[Ulrich Lukas (ulrich-lukas)]

> but the computer does not need other filesystem than root to be mounted
> to boot correctly, therefore it makes no sense to depend on
> other filesystems then root.

What if any of the essential directories (/var, /home, ...) reside on
other filesystems, are mounted onto the root filesystem, like when
encrypted or on a remote server and might not be available yet?

[Saivann Carignan (oxmosys)]

>So, isn't it a solution to simply make root filesystem depend on
>cryptsetup in cases where interactive input is needed? I.e. when no
>other (xsplash, key file) method is used?

Actually, root filesystem already depends on cryptsetup by design when root partition is encrypted, since it will never get mounted until cryptsetup prompt gets the good passphrase (therefore upstart wait in that situation). In other situations, it's not possible to make filesystem "depends" on cryptsetup since filesystem is a event, not a task. This bug only concern cryptsetup installations which does not mount root filesystem AFAIK.

>What if any of the essential directories (/var, /home, ...) reside on
>other filesystems, are mounted onto the root filesystem, like when
>encrypted or on a remote server and might not be available yet?

That is a very interesting question, I wouldn't be able to answer that (I'm not a developer myself). My guess is that everything except / is ignored since many other mount point can be necessary or not for the system, depending on the distribution and many other variables (ex. : /var, /media/*) . I guess that there is many chances that it's not upstart job to look at all these mount points and decide which ones are really needed since there are many many possibilities, unless upstart follows some FHS specification, but I might be wrong. I don't know how upstart handle these cases, but I think that it only react to the event of / becoming mounted and readable/writable.

[T.O.D. (linuxuser-sky)]

Hi

I have a encrypted hdd and in it it looks like:

encrypted hdd
(enter passwd)
    -- root (/) not encrypted
    -- home (/home) encrypted
(asks for pw,can type it)
    -- data (/mnt/data) encrypted
(ask for pw, cant type it)

I i use the solution from above i cant boot anymore cause my hdd encryption is not gonna be decrypted.

When ubuntu asks me for the second passwd for my data, Ubuntu still caries on booting and x is starting.

Thanks

[Ulrich Lukas (ulrich-lukas)]

Hi Tod,

as a workaround, I suggest that you use a custom init script
containing the "cryptsetup luksOpen..." and mount commands.

Or switch to openSuse; they have a maintainer who actually maintains this.

[Steve Langasek (vorlon)]

T.O.D.,

> When ubuntu asks me for the second passwd for my data, Ubuntu still caries on booting and x is starting.

The solution for this is documented in the Ubuntu 9.10 release notes at
<http://www.ubuntu.com/getubuntu/releasenotes/910#Optional%20encrypted%20partitions%20must%20be%20marked%20bootwait%20in%20/etc/fstab>.

[Steve Langasek (vorlon)]

This bug is also fixed in lucid, where plymouth is now used to serialize all passphrase prompts and other boot time interaction.

[Lex Berger (lexberger)]

I am using an encrypted home partition, and I experience the same problem as GOo in #13 _although_ I am using the "bootwait" option in /etc/fstab. However, using "bootwait" on /home should not have any effect anyway.

There are currently lots of bugs related to this issue, and bug reports seem to overlap.

I have been using Ubuntu from the beta of Warty Warthog, and this is the third release that broke my encryption setup, which is not complex at all anyway. I know I am being unprofessional now, but this SUCKS, guys. It really should be possible to mount an encrypted home at system boot without months of bug-reporting. Karmic is final, is it?

[Steve Langasek (vorlon)]

af-fsfe,

I understand your frustration at this regression. Please realize, though, that filesystem-level encryption of /home is at the bottom of a long list of disk encryption solutions that should be preferred over this in all but the most specific of corner cases:

 - full-disk encryption of a single partition including / and /home
 - encryption of a single LVM VG containing both / and /home filesystems
 - disk-level encryption of /, /home on a separate unencrypted filesystem using ecryptfs for user-level encryption
 - passphrase-based encryption of /, with keyfile-based encryption of other partitions

All of the above work in karmic; the only configuration that really doesn't work is passphrase-based encryption of disks other than the root partition. This is a bug, certainly, and will be resolved for the 10.04 LTS release; but it was not a blocker for the 9.10 release, with reason.