[pkg-cryptsetup-devel] Bug#659688: Bug#659688: cryptsetup: LVM on cryptsetup won't boot

[Jonas Meurer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Roland,

Am 13.02.2012 09:35, schrieb Roland Mas:
> Package: cryptsetup Version: 2:1.4.1-2 Severity: critical

To be honest I don't agree with you on the severity of this bug. I
understand that the changes in LVM handling of cryptroot initramfs
script that I introduced in package version 2:1.4.1-1 may have brokeen
your setup. But on the other hand your setup is very special and
custom and I actually wasn't aware that it had been supported before.

> Note that although this bug was introduced at version 2:1.4.1-1,
> it is different from #659235: my PVs and LVs and VGs don't have
> dashes in their name.
> 
> The current sequence: grub loads the kernel and the initramfs; the
>  kernel boots; the initramfs looks for the root filesystem but 
> cannot find it because it's not available yet; cryptsetup asks for 
> a passphrase, which I type; "cryptsetup: lvm fs found but no lvm 
> configured".  After some time I get dropped into a shell.  In that
>  shell, I can see the LVs as inactive, and I enable them with "lvm
>  lvchange -P -a y vg_mirexpress/root" (and ditto for 
> vg_mirexpress/swap), then ^D and the boot sequence starts again 
> normally (it reloads my hibernated system).

Are you confident that the bug didn't exist in 2:1.3.1-3 yet? Actually
the only change in activating LVM volume groups from 2:1.3.1-3 to
2:1.4.1-1 was, that the option --sysinit is given to vgchange now.

Please remove --sysinit option from line 156 of
/usr/share/initramfs-tools/scripts/local-top/cryptroot, update your
initramfs with 'update-initramfs -u' and see whether the problem
disappears.

2:1.4.1-1 introduced much more changes in the initramfs cryptroot hook
than in the initramfs cryptroot script. Maybe these changes introduced
the bug you reported. Any messages given by 'update-initramfs -u'
would be helpful to identify possible problems here.

> It's possible that the problem comes from the need for -P 
> (--partial) in the commands I quote: as may be found in the 
> configuration snippets below, the LUKS key to one of the PVs used 
> in LVM is stored on the filesystem on another LV of the same VG; 
> this means that the first activation of the VG needs to be done 
> with the -P/--partial flag, so the available LVs (including root) 
> are activated and the boot sequence may proceed.

Regards,
 jonas

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPOZa9AAoJEFJi5/9JEEn+nWsQAI5M2V6A4tJPxuanMfedggZq
ZE6dvN6SBFUsQbCUKjHzVo4bGnPk4mhwYhsfdCOXzjBEvhfxfIYdwC62W92lm5fM
FJnFypnFKbQE6HnRHruDsKt5+is2KqYEcdIkeFpiuA+TXdEw9TE59oOgrSfOt3d2
SugWL7EleUvM+Ez0Sd9zLr8YyXAonh5v2hkDOPaLRMVra8rjtBzyT6sYbioGH4S6
VZX8buhWp7PiP6ziEkmAMgDp504Is1sK4semHfRtcHblu5Tgdv6sQmBzPUMqFcvL
tTlKBf08qzEVjunWX2RsCkyDMx1px6j32qgOezj1/vS3Pk/8bcp2dUbdrrkUjyYp
WITrsKLDtff1XIRXZ5ysQLl3f3SOqIMUPRORoa3a9N1dDdO5wOwYdK7PTsVQw9XG
LNLsECWftL6k9tTM7ruZZ3gp69dQXJQkoLdIlpROc4gUkHnCx7QawUUOwkH2JME4
hOY53YbNQP/z/iUihqT/YNnd+L/3NXDg+tNQNz94nH0irmMDfyq7KhEc0C4Jlfbe
FBQ8dmuBZ/pPBAxRsefrBKZkv2H/njqbLGrb6vn12ZVijz0x8RH8oO9ddIdF2CH7
hfK+U0F8X3gChz0yj7cOqhe62xjXRR6zJ0wsrSI8VZSKXnLGlaRg7eNBTW7JiLxV
WEAiZ+IflQtz+XnNA8hl
=dzpd
-----END PGP SIGNATURE-----