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, 619...@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" > <vschle...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
