Bug#591626: [pkg-cryptsetup-devel] Bug#591626: Unable to boot from encrypted Luks volume after upgrade
On 16/08/10 21:09, Jonas Meurer wrote: Hey Jiri, On 16/08/2010 Jiri Kanicky wrote: Hi. I attached picture with the boot message. I was digging into the problem more today and found the following: - looks like LVM does not activate the /dev/data_vg/knightrider-sec volume on the boot and therefore cryptsetup cannot see the volume. It only activates one LV; knightrider-root. - in the (initramfs) mode on the picture I typed "lvm" which took me to (lvm) mode. I activated all volumes in the data_vg group "vgchange -ya" and exited all. This brought the cryptsetup enter passphrase line. I entered the passphrase and the system booted. - The interesting bit is that executing "update-initramfs" right after "apt-get update; apt-get upgrade" will not output line with "cryptsetup" (bellow). However, entering it after the faulty boot, it will find the encrypted LV and note it in the cryptsetup line. update-initramfs: Generating /boot/initrd.img-2.6.34-1-686 cryptsetup: NOTE: using /dev/mapper/data_vg-knightrider--sec instead of /dev/data_vg/knightrider-sec for knightrider-sec Any idea where can be the problem? ok, now i've an idea where the problem is located. in order to reproduce the situation, i need more detailed information. please send me contents of your /etc/fstab, /etc/crypttab. additionally i need the debug ouput of mkinitramfs, both righty after 'apt-get upgrade' and after the faulty boot. to produce debug output, you need to change the first line of /usr/share/initramfs-tools/hooks/cryptroot to '#!/bin/sh -x', and run the following command: 'sh -x mkinitramfs -o /tmp/initramfs.debug 2>/tmp/mkinitramfs.log' /tmp/mkinitramfs.log contains the required debug log. you can revert the changes in /usr/share/initramfs-tools/hooks/cryptroot afterwards. greetings, jonas For starters knightrider:~$ cat /etc/fstab # /etc/fstab: static file system information. # # proc/proc procdefaults0 0 /dev/mapper/knightrider-sec / ext3 defaults,noatime,errors=remount-ro 0 1 # /dev/sda3 /boot ext3defaults,noatime0 2 UUID=4fa73ded-e329-4b6d-a81c-a04e74b381c8 /boot ext3 defaults,noatime0 2 /dev/mapper/data_vg-knightrider--swap noneswap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 knightrider:~$ cat /etc/crypttab # knightrider-sec/dev/data_vg/knightrider-secnoneluks I think that I have to wait for another upgrade which will break it again. I am not sure which package and subsequently debconf breaks it. As I do not have any packages to update now, update-initramfs outputs cryptsetup line and everything is OK. Jiri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591626: [pkg-cryptsetup-devel] Bug#591626: Unable to boot from encrypted Luks volume after upgrade
Hey Jiri, On 16/08/2010 Jiri Kanicky wrote: > Hi. > > I attached picture with the boot message. > > I was digging into the problem more today and found the following: > > - looks like LVM does not activate the /dev/data_vg/knightrider-sec > volume on the boot and therefore cryptsetup cannot see the volume. > It only activates one LV; knightrider-root. > > - in the (initramfs) mode on the picture I typed "lvm" which took me > to (lvm) mode. I activated all volumes in the data_vg group > "vgchange -ya" and exited all. This brought the cryptsetup enter > passphrase line. I entered the passphrase and the system booted. > > - The interesting bit is that executing "update-initramfs" right > after "apt-get update; apt-get upgrade" will not output line with > "cryptsetup" (bellow). However, entering it after the faulty boot, > it will find the encrypted LV and note it in the cryptsetup line. > > update-initramfs: Generating /boot/initrd.img-2.6.34-1-686 > cryptsetup: NOTE: using /dev/mapper/data_vg-knightrider--sec instead > of /dev/data_vg/knightrider-sec for knightrider-sec > > Any idea where can be the problem? ok, now i've an idea where the problem is located. in order to reproduce the situation, i need more detailed information. please send me contents of your /etc/fstab, /etc/crypttab. additionally i need the debug ouput of mkinitramfs, both righty after 'apt-get upgrade' and after the faulty boot. to produce debug output, you need to change the first line of /usr/share/initramfs-tools/hooks/cryptroot to '#!/bin/sh -x', and run the following command: 'sh -x mkinitramfs -o /tmp/initramfs.debug 2>/tmp/mkinitramfs.log' /tmp/mkinitramfs.log contains the required debug log. you can revert the changes in /usr/share/initramfs-tools/hooks/cryptroot afterwards. greetings, jonas signature.asc Description: Digital signature
Bug#591626: [pkg-cryptsetup-devel] Bug#591626: Unable to boot from encrypted Luks volume after upgrade
On 16/08/10 20:03, Jiri Kanicky wrote: On 16/08/10 00:08, Jonas Meurer wrote: Hey Jiri, On 04/08/2010 Jiri Kanicky wrote: Here is full apt log: according to your apt log, cryptsetup was not upgraded. instead, other packages where upgraded, which triggered update-initramfs, and thus updated the initramfs for linux kernel 2.6.34-1-686. you wrote the following at the initial bugreport: On Wed, Aug 04, 2010 at 08:03:35PM +1000, Jiri Kanicky wrote: I am not able to boot from my encrypted LUKS volume everytime after I upgrade (apt-get upgrade). I have to boot from rescue cd and regenerate initrd (update-initramfs) to fix the issue as I wrote here: http://ganomi.com/wiki/index.php/Rescue_an_encrypted_LUKS_LVM_volume It started a month ago. please give more information: - which version of cryptsetup and initramfs-tools do you have installed? (output of 'dpkg -l cryptsetup initramfs-tools') - which error message do you get at boot when the boot process fails? - which linux kernel version do you boot? (output of 'uname -r') - which initramfs version do you update with manual initramfs regeneration inside a chroot? (output of 'update-initramfs -u') - is the bug reproducible by invoking 'update-initramfs -u' at the running system? does this break the boot process again? in order to find the real bug here, we need more detailed information from you. so far, you're the only one who reported this problem, thousands of cryptsetup users didn't discover it while using the same version as you. greetings, jonas Hi. I attached picture with the boot message. I was digging into the problem more today and found the following: - looks like LVM does not activate the /dev/data_vg/knightrider-sec volume on the boot and therefore cryptsetup cannot see the volume. It only activates one LV; knightrider-root. - in the (initramfs) mode on the picture I typed "lvm" which took me to (lvm) mode. I activated all volumes in the data_vg group "vgchange -ya" and exited all. This brought the cryptsetup enter passphrase line. I entered the passphrase and the system booted. - The interesting bit is that executing "update-initramfs" right after "apt-get update; apt-get upgrade" will not output line with "cryptsetup" (bellow). However, entering it after the faulty boot, it will find the encrypted LV and note it in the cryptsetup line. update-initramfs: Generating /boot/initrd.img-2.6.34-1-686 cryptsetup: NOTE: using /dev/mapper/data_vg-knightrider--sec instead of /dev/data_vg/knightrider-sec for knightrider-sec Any idea where can be the problem? Jiri In addition: ||/ NameVersion Description +++-===-===-== ii cryptsetup 2:1.1.3-3 configures encrypted block devices ii initramfs-tools 0.98 tools for generating an initramfs 2.6.34-1-686 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#591626: [pkg-cryptsetup-devel] Bug#591626: Unable to boot from encrypted Luks volume after upgrade
Hey Jiri, On 04/08/2010 Jiri Kanicky wrote: > Here is full apt log: according to your apt log, cryptsetup was not upgraded. instead, other packages where upgraded, which triggered update-initramfs, and thus updated the initramfs for linux kernel 2.6.34-1-686. you wrote the following at the initial bugreport: On Wed, Aug 04, 2010 at 08:03:35PM +1000, Jiri Kanicky wrote: > I am not able to boot from my encrypted LUKS volume everytime after I > upgrade (apt-get upgrade). > > I have to boot from rescue cd and regenerate initrd (update-initramfs) > to fix the issue as I wrote here: > http://ganomi.com/wiki/index.php/Rescue_an_encrypted_LUKS_LVM_volume > > It started a month ago. please give more information: - which version of cryptsetup and initramfs-tools do you have installed? (output of 'dpkg -l cryptsetup initramfs-tools') - which error message do you get at boot when the boot process fails? - which linux kernel version do you boot? (output of 'uname -r') - which initramfs version do you update with manual initramfs regeneration inside a chroot? (output of 'update-initramfs -u') - is the bug reproducible by invoking 'update-initramfs -u' at the running system? does this break the boot process again? in order to find the real bug here, we need more detailed information from you. so far, you're the only one who reported this problem, thousands of cryptsetup users didn't discover it while using the same version as you. greetings, jonas signature.asc Description: Digital signature