Encrypted partition problem in Karmic alternate CD

[kevinc]

Hi. I've been using encrypted partitions during install since available during installation, in 2007 April.

I have dual boot and have been running Jaunty and Karmic since alpha3. I tried a few other distros and came back to Karmic at alpha6, and found then that after installing an encrypted partition, it would not accept the password. The same problem exists with the current Karmic alternate CD. When a partition is encrypted during installation, on boot entering the passphrase and 'return' results in nothing. Entering 'return' a second time gives "no key found with this passphrase". I've entered the correct passphrase many times and it is rejected. After two or three attempts it needs a number of 'enter' or 'return' before there is a response from the system.

I re-installed without any encrypted partitions, then added the needed lines to /etc/fstab and /etc/crypttab which then still refused to accept my passphrase during boot. But, from a terminal I could manually mount the encrypted partitions with

sudo cryptsetup luksOpen /dev/sda2 sda2_crypt
sudo mount -t ext3 /dev/mapper/sda2_crypt /home

This has two problems, the need to manually mount and umount for /home and using the quick access browser next to kickoff doesn't respond.

Any ideas?

[zenarcher]

Re: Encrypted partition problem in Karmic alternate CD

I'm not sure about your setup there, but I also run an encrypted hard drive (except for a small boot partition, of course), but not a dual boot system. I don't know if that would make a difference.

Anyway, I am using Kubuntu 9.10 here and do the install using the Alternate Install CD. I have four computers running the same way, all with encrypted hard drives and have experienced no issues with the setup I use. Here is what I use when I get to the partitioning point, using the Alternate Install CD:

http://kuparinen.org/martti/comp/ubu...cryptolvm.html

It's a pretty simple method and has worked very reliably for me. Possibly that method might help you.

Cheers,
zenarcher

[kevinc]

Re: Encrypted partition problem in Karmic alternate CD

Thanks. That helps to clarify something. I read the article, quite a good one in 2007 and I like that method. It uses LVM which has certain advantages and is probably more secure because everything except the /boot partition is encrypted in one physical volume which is managed by LVM.

In previous installations I don't remember the distinction between encrypted partitions and LVM partitions, but with Karmic this time there seemed to be more options. I will try the install again with LVM and report if that solves the problem.

[zenarcher]

Re: Encrypted partition problem in Karmic alternate CD

Good luck with using that method. I have used it here with Kubuntu 9.04 and now with Kubuntu 9.10, on 4 64 bit desktop installs, as well as on my Dell Mini 9 with the SSD drive. It has worked flawlessly for me on all. I agree....I like the idea of having everything encrypted except for the small boot sector. In this way, even swap is encrypted and I consider it to be quite secure.

Regards,
zenarcher

[kevinc]

Re: Encrypted partition problem in Karmic alternate CD

I tried it, but couldn't get it to boot. I used GRUB instead of GRUB2 as previous trials with GRUB2 have messed up a perfectly useful MBR. As a matter of interest, did you use GRUB or GRUB2?

I also tried my the slightly simpler method of encrypting one partition for /home, as I already have swap partition which is encrypted by each distro but found the same error.

There seems to be a Ubuntu bug #475293 to which I've added comments.

[zenarcher]

Re: Encrypted partition problem in Karmic alternate CD

I'm not sure about the problem. I used GRUB2 and EXT4 file system here. As I say, I've followed the same procedure on four desktop systems with 9.10 and the little Dell Mini 9, as well. Previously, I used the same layout with 9.04 without problems, as well. It's a bit tricky following the directions and I always make sure my layout looks the same as the ones in the screenshots, just to verify. I've messed up a couple of times in getting it right. I wonder if anyone else on the forums has used this method with success.

Regards,
zenarcher

[kevinc]

Re: Encrypted partition problem in Karmic alternate CD

Thanks for that info. I will try again with GRUB2 and ext4, although I'm still happier with GRUB and ext3.

The problem seems to be in processing the password to unlock the dm-crypt key. In Jaunty and earlier, it works as expected, type a password, enter, and it tells you the key slot 0 is unlocked and booting continues.
With Karmic, type a password, enter and nothing. Type enter again, wait, and finally it tells you that that password does not unlock the key slot. At least you get another chance to type the password, but each time it seems to require pressing the enter key more times, before there is any response. I don't think it's my enter key because it gets a good workout and everything else works fine with it.

[zenarcher]

Re: Encrypted partition problem in Karmic alternate CD

That is quite strange, for sure. But, I've only used it on Karmic with GRUB2 and EXT4, so I don't know if there is an issue using others. I've incorrectly typed my passphrase more than once and it a few seconds was asked to enter it again. Hitting Enter once after typing the password again unlocks the system quite quickly.

Regards,
zenarcher

[kevinc]

Re: Encrypted partition problem in Karmic alternate CD

Well, six weeks later, while trying to find out what Xubuntu uses for network manager, I found the release notes for Ubuntu Karmic gives this information: http://www.ubuntu.com/getubuntu/releasenotes/910

Optional encrypted partitions must be marked bootwait in /etc/fstab
In addition to the above, users who have configured any encrypted partitions in /etc/crypttab to start at boot time (i.e., not using the noauto option) should make sure that the filesystems on these volumes are listed in /etc/fstab if they are not mounted at a standard system mountpoint. Failure to do this on a desktop system will lead to problems from the X server and cryptsetup trying to control the console at the same time. At best, this will prevent the user from seeing the passphrase prompt; at worst it will also cause the X server to spin and consume 100% CPU. (430496)

This work around allows me to boot with an encrypted partition, but still get two messages during boot saying that the system is waiting for the encrypted partitions, but finally a prompt for the password and it does accept the password, so after that, everything works OK.