On 11/06/2012 04:19, Celejar wrote:
On Sun, 10 Jun 2012 23:25:02 +0100
Jon Dowland<j...@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
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 ?
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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd772f9.1000...@googlemail.com
