[pkg-cryptsetup-devel] Bug#619010: FW: Re: Bug#619010: (no subject)

[Volker Schlecht]

Hi Jonas,

your assumptions about my setup are spot-on.
As you correctly guessed, a regenerated initramfs breaks in the same manner. 
Diffing the two initrds yielded a significant difference in cryptroot - the working version refers to /dev/sda2
instead of the uuid (I guess my old initrds were generated with /etc/crypttab.old ... d'oh!)

What's interesting is that on a booted system I get 
 
# blkid /dev/sda2 
/dev/sda2: UUID="013dabec-dd64-4fe0-8842-cd2f92f3348e" SEC_TYPE="ext2" TYPE="ext3" 

Whereas in the rescue console /dev/sda2 has a different UUID. There's "more robust" for ya...

I guess I'll manually switch /etc/crypttab back then. Might still be interesting, how come the UUID is different between two boots...

regards,
Volker

> ----- Ursprüngliche Nachricht -----
> Von: jonas
> Gesendet: 13.04.11 23:24 Uhr
> An: Volker Schlecht, 619010 at bugs.debian.org
> Betreff: Re: FW: Re: [pkg-cryptsetup-devel] Bug#619010: (no subject)
> 
> On Tue, 12 Apr 2011 21:54:58 +0200, "Volker Schlecht"
> <vschlecht at gmx.net> wrote:
> > Hi,
> > 
> > booting 2.6.38, I get:
> > 
> > Reading all physical volumes. This may take a while.
> > No volume groups found.
> > No volume groups found.
> > 
> > Plus the evms warning. Then the boot hangs until it drops me into the
> > initrd rescue console.
> 
> hey volker,
> 
> unfortunately i'm rather busy at the moment.
> 
> > Playing around with lvm at the initrd rescue prompt kinda narrows it down to a problem with LVM for me: both vgscan and pvscan yielded 
> > no results at all...
> 
> from your fstab and crypttab, i assume that your encrypted devices are
> physical devices (sda2 and sda3), not lvm devices. sda2 holds your
> encrypted rootfs, and sda3 contains a encrypted lvm volume (cryptVG),
> which itself contains /home, /usr and /var, right?
> in that case, no lvm volume can be found at all, as the device that
> contains the lvm volume isn't unlocked yet.
> 
> please do the following steps in order to further debug the issue:
> 
> - at the initramfs emergency console, check uuid and availability of
> your root device:
>  'blkid /dev/sda2' and 'ls
> /dev/disk/by-uuid/013dabec-dd64-4fe0-8842-cd2f92f3348e'
> 
> - if the root device is available and the uuid is correct, try to
> unlock the rootfs manually:
>  'cryptsetup luksOpen
> /dev/disk/by-uuid/013dabec-dd64-4fe0-8842-cd2f92f3348e cryptRoot'
> 
> in order to track down the source of problem, please also regenerate
> the initramfs for your 2.6.37 kernel and see whether that one still
> boots. first, backup your working 2.6.37 initramfs: 'cp
> /boot/initrd.img-2.6.37-2-686-bigmem
> /boot/initrd.img-2.6.37-2-686-bigmem.works', afterwards regenerate with
> 'update-initramfs -u -k 2.6.37-2-686-bigmem', then reboot the 2.6.37
> kernel.
> 
> if the 2.6.37 kernel still reboots without issues, the problem for sure
> is connected to the 2.6.38 kernel. if it doesn't boot anymore, you can
> change the bootloader to use the .works backup initramfs manually. in
> that case the problem is not related to the kernel, but rather to the
> initramfs.
> 
> greetings,
>  jonas