When partitioning with a RAID0, dm-crypt device on top and a lvm volume
inside the encrypted device, the generated initramfs cannot boot
completely because it does not try to decrypt the encrypted device.

Fix: add the dm-crypt device to /etc/crypttab and regenerate the
initramfs

Additional info: This was done on a laptop with 4 ssd.
Each ssd had a 300MB partition, with the one on sda used for /boot.
The rest of the space on each disk is used for the raid array.
The encrypted device is created inside /dev/md0.
A LVM volume is created inside /dev/md0.
There are 2 partitions inside the volume, one for /, one for the swap.

The laptop is a work laptop, so I cannot try another install. I will
however try to reproduce the issue in a virtual machine using qemu.
If there is anything else I can do, please tell me.
If this is the wrong mailing list, I am sorry, and could you please
tell me which one is the right one.

I think I am seeing the same bug reported in #716978...

I just did an install of wheezy using a d-i daily (updated today
2013-08-05). The root is md raid->crypt->lvm. Upon boot the initramfs
started up the md raid devices properly, but failed to setup the crypto
and dropped to an initramfs shell. When I poke around I see that

/lib/modules/3.2.0-4-amd64/kernel/crypto/

is lacking most of the crypto modules (including the xts/serpant/etc
that my system needed). So I am unable to bring things up by hand
either.

During the install, for the question about how much to include in the
initramfs, I picked the "just what's needed by this system" answer,
although I think that should have been OK.

Thanks,

I doubt we'll ever be able to get it completely right.  That option
should be warned against in general.  It is useful for machines with
limited memory or space for the initramfs (e.g. ARM systems where the
bootloader looks for it in a specific flash partition).  Otherwise it
just saves a fraction of a second of boot time, or fails to boot.

Ben.

Ben Hutchings writes:

I used d-i rescue mode to mount the disks and switch from "dep" to "most"
mode for update-initramfs and that pulled the crypto modules in. But now
the problem is that the LVM tools aren't in the initramfs so it gets stuck
at that point.

That's strange.  The LVM tools are added by
/usr/share/initramfs-tools/hooks/lvm2 which is part of the lvm2 package.
So this implies lvm2 wasn't installed either, though that seems
unlikely.

Ben.

cause I did some refactoring on partman-lvm and partman-crypto
together with new upstream releases of lvm2, crypto, kernel.... there
are plenty of things that could have gone wrong.

Also just recently in ubuntu this upload was made:
https://launchpad.net/ubuntu/+source/lvm2/2.02.98-1ubuntu4

To fix a very nasty:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1206235

Not sure if debian is also affected, and whether it's related at all.

Regards,

Dmitrijs.

Ben Hutchings writes:

I found the LVM problem (and possibly the crypt problem). My preseed setup
was installing a sources.list that pointed to squeeze rather than wheezy
and I think that prevented lvm2 from getting installed. It may have also
caused the initramfs to not get the crypto modules, but I suspect it's more
likely that using the minimal module setting caused that.

Thanks,

I also uploaded a fix, where apt-install lvm2 script was not actually
executable in the partman-lvm, so it was not actually run either. The
affected versions were 84 & 85, fix released in 86. Maybe that was
related as well.....

http://ftp-master.metadata.debian.org/changelogs/main/p/partman-lvm/unstable_changelog

Regards,

Dmitrijs.

Dear Maintainer,

After having used the following image:
	Debian GNU/Linux testing "Jessie" - Official Snapshot amd64 NETINST Binary-1 20140520-00:27
The system could not boot initially, I had to boot the rescue mode, type the encrypted partition password and force-rebuild
the initramfs using : update-initramfs -k all -t -u . The -t switch was needed for a successful initramfs update.

The weird thing was that /etc/crypttab had not one, but two identical lines.

Cheers,

Adrian (And OdyX)

I tried installing Debian 8.1 on "LVM on LUKS" prepared before installation.
Debian Installer first didn't see my encrypted volumes (so that I had to do
anna-install to get cryptsetup, and enable encrypted volumes by hand, then
vgchange to enable LVM volume group). After it Debian Installer could recognize
all my volumes and I have finished the installation, but /etc/crypttab was
empty, so I had to populate it by hand and update initramfs. Without it system
could not boot.