Bug#591626: [pkg-cryptsetup-devel] Bug#591626: Unable to boot from encrypted Luks volume after upgrade

2010-08-16 Thread Jiri Kanicky

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

2010-08-16 Thread Jonas Meurer
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

2010-08-16 Thread Jiri Kanicky

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.
#
# file system mount point type options dump pass
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
# target name source device key file options
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

2010-08-15 Thread Jonas Meurer
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