Karmic series kernel won't load encrypted main disk after upgrade from jaunty

[Kirit Sælensminde]

After upgrading a laptop from Jaunty to Karmic the encrypted main disk won't mount when loading the current Karmic kernel (2.6.31-5).

The disk was encrypted using the Jaunty installer (earliest kernel is 2.6.26-5, from memory it was probably a pre-release one, and probably the alternate installer). On loading the new kernel does not see a disk with the UUID that it expects to find. There is a disk under /dev/disk/by-uuid (with a different UUID), but I don't know how to try to mount it using ash to see if it is the right disk or not.

Booting the laptop with the last Jaunty kernel (2.6.28-14) works fine. I have since done a manual upgrade to grub 2, but the problem is still there.

The laptop is running the 32 bit version of Kubuntu.

[Kirit Sælensminde (kayess)]

This has now happened to me on a second laptop that I upgraded. I'll see if I can work out a set of steps to reproduce this on a VM tomorrow if I get time.

[Kirit Sælensminde (kayess)]

I had a go at reproducing this. I can't get a successful install from the alpha 2 jaunty installer any more so that didn't help. I also wasn't able to install from any of the kubuntu jaunty ISO images -- they always gave me corrupt file errors. The standard GNOME installer seemed to upgrade fine, and I also tried the mini.iso and installed kubuntu-desktop and that upgraded without problem.

I can't really work out what is going on here. The uuid I see in ash when the boot fails is the one for the root partition. This is the same as the uuid that I see in /boot/grub/grub.cfg after I run update-grub2. What I can't see is where the uuid that it is trying to mount comes from. I tried to disable the grub 2 option for passing the uuid to the kernel, but that made no difference.

I suspect that the best thing to do at this point is to write off the installations and re-install both laptops. Hopefully it's a problem caused by jaunty alpha 2 and there won't be too many other people who have problems with this.

[Jimmy Hedman (jimmy-hedman)]

I got the exact same problem, could boot on one of my old kernels but not the newly installed.
I did an update to Karmic from Jaunty with aptitude and changed the /etc/apt/sources.list to use Karmic insted.

Can I solve this by hand? I really like to try the 2.6.31 kernel from Karmic Koala.

[Kirit Sælensminde (kayess)]

After I couldn't reproduce this with a fresh install on a VM I gave up and re-installed both machines. Did you also install from a pre-release version of Jaunty? That might be the common aspect.

[Michael Fritscher (michael-fritscher)]

try to use /dev/sda2 or something instead of the UUID-crap in the /etc/crypttab and /dev/mapper/sda2_crypt in the root=parameter in grub.
After this you must run update-initramfs and update-grub again.

[Jimmy Hedman (jimmy-hedman)]

I've compared my initrd with an initrd from a fresh install and both my upgraded and freshly installed has the UUID-"crap" in /etc/crypttab and as the root-option to the kernel.

[Michael Fritscher (michael-fritscher)]

Btw, you can mount it in the busybox with cryptsetup luksOpen /dev/... name and then mount /dev/mapper/name /mnt.
Then mount the usual help dirs (proc, sysfs, /boot), copy a mtab and /dev/sd**into the mounted device, do a chroot and update the initrd as descibed before.

or use, if you can, an older kernel.

[Jimmy Hedman (jimmy-hedman)]

I just tried a fresh Jaunty to Karmic and it worked without modification of /etc/crypttab.