d-i installs that select encrypted LVM autopartitioning fail to set up encryption and LVM at all.

[Joel Ebel]

Binary package hint: partman-auto-crypto

attached partman log from an install.

When you select encrypted LVM in a d-i install, you go through the whole partman procedure, being asked to confirm writing out to the disk, etc. and get kicked back into the main partitioning menu. Inspecting the disk shows that it was partitioned, but there is no LUKS header on any partition, no PV's set up, and no filesystem on /dev/sda1. /sda5 is formatted ext2 as the /boot partition. (The fact that it still puts /boot in an extended partition at the end of the drive seems like a bug to me, but that's unrelated.)

[Joel Ebel (jbebel)]

This might be more appropriately moved to partman-crypto, or maybe base, as I can't set up crypto partitions manually either.

[Joel Ebel (jbebel)]

I'm going to move this to partman-base solely because this started happening right around the release of partman-base 139ubvuntu2, which involved padding the end of disks unless they are device-mapper devices. This seems plausibly responsible for being unable to set up encrypted devices.

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-base - 139ubuntu3

---------------
partman-base (139ubuntu3) lucid; urgency=low

  * parted 2.1 changed the semantics of ped_disk_clobber: it now zeroes out
    the first few and last few sectors of the disk, regardless of whether
    there appears to be a valid partition table on it. Unfortunately, this
    means that creating a filesystem on a whole disk device and then calling
    ped_disk_commit_to_dev zeroes the filesystem header we just created. To
    avoid this, call ped_disk_commit_to_dev only if the partition doesn't
    start at sector zero (LP: #539324, #549260).
 -- Colin Watson <email address hidden> Mon, 29 Mar 2010 21:55:02 +0100