On 11/06/2012 04:19, Celejar wrote:
Hi, I run LUKS on top of raid (mdadm) on some systems and lvm on LUKS on others, with locally compiled 3.4.x on testing (amd64), so it's probably not something related to 3.4 kernels proper, maybe the problem is stable + 3.4, but more likely the kernel or initramfs-tools config. What mechanism do you use to unlock the luks container (passphrase, key-file...) ? Did you try to rebuild initramfs in verbose mode, or unpack it to check that needed modules are indeed there ? Did you grep your kernel config for needed modules and compare output with a config known to work ?On Sun, 10 Jun 2012 23:25:02 +0100 Jon Dowland<jmtd@debian.org> wrote:On Sun, Jun 10, 2012 at 08:28:10AM -0400, Celejar wrote:Hi, I have my rootfs on lvm on top of a luks (cryptsetup) encrypted volume. System has been working fine since installation with stock Debian, as well as self-built kernels (2.6.x - 3.3.8, grub2), using a ram disk (initramfs) with cryptsetup included to unlock the luks volume on boot. With recent 3.4.x kernels (stable branch, 3.4.1 / 3.4.2), th system fails to unlock the luks volume, reporting: cryptsetup: evms_activate not available [or something like that - typing from memory] Running amd64 stable, with some backports stuff, on a Lenovo Thinkpad t61. Any idea what this is?Are the failing kernels hand built or are they packaged?Hand built from vanilla upstream sources. Celejar
Maybe going through 3.4 kernel main changes [1] can ring a bell, I don't remember anything specific to this but maybe I already forgot.
[1] http://kernelnewbies.org/LinuxChanges