Bug#659688: [pkg-cryptsetup-devel] Bug#659688: cryptsetup: LVM on cryptsetup won't boot
retitle 659688 LVM on LUKS won't boot if not all LVs are available initially severity 659688 normal thanks Roland Mas, 2012-02-14 20:18:25 +0100 : Feel free to downgrade it; I only picked critical because the effects were the same as for #659235, but I agree my setup may be a bit more involved than usual. Let's downgrade. 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. It doesn't. I still need to activate the LVs manually from the initramfs shell, with --partial. I just split my VG in two; the obelix_crypt volume that's not available initially is no longer part of the big VG, which means that the VG is fully available and requires no --partial. The system is back to booting normally. I did a casual diff between 2:1.3.0-3.1 and 2:1.4.1-2 and found nothing obviously relevant to LVM partial stuff. I suppose the change occurred in the way the device dependencies are calculated, around lines 150-160 of cryptroot-hook. Roland. -- Roland Mas When I eat a biscuit, it stays eaten! -- Arthur Dent, in So Long, and Thanks for All the Fish (Douglas Adams) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659688: [pkg-cryptsetup-devel] Bug#659688: cryptsetup: LVM on cryptsetup won't boot
Jonas Meurer, 2012-02-14 00:03:37 +0100 : Hey Roland, Hi, 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. Feel free to downgrade it; I only picked critical because the effects were the same as for #659235, but I agree my setup may be a bit more involved than usual. [...] 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. I don't seem to have a trace of any 2:1.3.1-3 version; I am confident it didn't exist with 2:1.3.0-3 or 2:1.3.0-3.1. I've been tracking unstable with this setup for ~6 months. 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. It doesn't. I still need to activate the LVs manually from the initramfs shell, with --partial. 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. Only the following: # update-initramfs -u update-initramfs: Generating /boot/initrd.img-3.2.0-1-686-pae cryptsetup: WARNING: target obelix_crypt uses a key file, skipped cryptsetup: WARNING: target obelix_crypt uses a key file, skipped # Roland. -- Roland Mas 'ALL your base? No!! One tiny base continue bravely to resist.' -- wiggy in #debian-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#659688: cryptsetup: LVM on cryptsetup won't boot
Package: cryptsetup Version: 2:1.4.1-2 Severity: critical 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). 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. For extra reference, my setup looks like this: three physical drives (one smallish SSD, two big rotating disks). Partitions 1 on the SSD and the disks are assembled into /dev/md/boot, which is ext4 and used as /boot. Partitions 2 on the SSD and the disks are assembled into /dev/md/triple_patte, which is encrypted (with a passphrase) and then used as a PV for LVM. Partitions 3 only exist on the disks, are assembled into /dev/md/obelix, which is encrypted (with a keyfile) and used as another PV. Roland. -- Package-specific info: -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.2.0-1-686-pae root=/dev/mapper/vg_mirexpress-root ro modeset=1 quiet -- /etc/crypttab # target name source device key file options raid_crypt /dev/md/main/etc/private/raid_obelix.key luks,size=128,cipher=aes-cbc-essiv:sha256 obelix_crypt/dev/md/obelix /etc/private/raid_obelix.key luks,size=128,cipher=aes-cbc-essiv:sha256 triple-patte_crypt /dev/md/triple-pattenone luks,size=128,cipher=aes-cbc-essiv:sha256 -- /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dump pass /dev/vg_mirexpress/root / ext4defaults 0 1 /dev/md/boot/boot ext4defaults 0 2 /dev/vg_mirexpress/tmp /tmpext4defaults 0 2 /dev/vg_mirexpress/usr /usrext4defaults 0 2 /dev/vg_mirexpress/var /varext4defaults 0 2 /dev/vg_mirexpress/var_cache/var/cache ext4defaults 0 2 /dev/vg_mirexpress/home /home ext4defaults 0 2 /dev/vg_mirexpress/home_roland /home/rolandext4defaults 0 2 /dev/vg_mirexpress/gnurandal/home/roland/gnurandal ext4defaults 0 2 /dev/vg_mirexpress/musique /home/roland/musiqueext4defaults 0 2 /dev/vg_mirexpress/photos /home/roland/photos ext4defaults 0 2 /dev/vg_mirexpress/backups /space/backups ext4defaults 0 2 /dev/vg_mirexpress/srv_maildir /srv/maildirext4defaults 0 2 /dev/vg_mirexpress/cd_dvd /space/cd_dvd ext4defaults 0 2 /dev/vg_mirexpress/pbuilder /srv/pbuilder ext4defaults 0 2 /dev/vg_mirexpress/virtualbox /srv/virtualbox ext4defaults 0 2 /dev/vg_mirexpress/rushes /space/rushes ext4defaults 0 2 /dev/vg_mirexpress/scratch /space/scratch ext4defaults 0 2 /dev/vg_mirexpress/swap noneswapdefaults # sshfs#roland@mirenboite:/srv/musique/rips /home/roland/musique/rips fuse rw,nosuid,nodev,max_read=65536,user=roland,IdentityFile=/home/roland/.ssh/id_dsa,ServerAliveInterval=60,uid=1000,allow_other,gid=1000 /dev/fd0/floppy autodefaults,user,noauto0 0 /dev/cdrom /cdrom iso9660 defaults,ro,user,noauto 0 0 none/selinuxselinuxfs noauto 0 0 -- lsmod Module Size Used by nls_utf8 12416 0 isofs 34672 0 loop 17810 0 usb_storage35183 1 uas13096 0 pci_stub 12397 1 vboxpci18713 0 vboxnetadp 13143 0 vboxnetflt 23231 0 vboxdrv 164892 3 vboxpci,vboxnetadp,vboxnetflt
Bug#659688: [pkg-cryptsetup-devel] Bug#659688: cryptsetup: LVM on cryptsetup won't boot
-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- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
