hey, On 22/02/2010 Selim Levy wrote: > On 21 February 2010 15:53, Jonas Meurer <jonas@xxxxxxxxxxxxxxx> wrote: > > yon can use "UUID=..." instead of the device path both in /etc/fstab and > > in /etc/crypttab. for example: > > > > /etc/fstab: > > UUID=9385bada-5c09-a303-ee31-4fd23452af29 / ext3 errors=remount-ro 0 1 > > > > /etc/crypttab: > > sdb3_crypt UUID=35bc3457-127a-4344-80bf-6cdfff232339 none luks > > > > /proc/cmdline: > > BOOT_IMAGE=/vmlinuz-2.6.26-1-amd64 root=/dev/mapper/rescue-rooto ro > > > > you need to substitute the UUID in /etc/fstab with the UUID of > > /dev/mapper/rescue-rooto, and the UUID in /etc/crypttab with the one of > > /dev/sdb3. > > > > This yielded interesting results. > > So I got the necessary UUIDs and placed them into fstab and crypttab and > then updated my initramfs. (I also made the change to cmdline, but I'm now > convinced that the problem isn't there.) This time I only got the error > once (and not twice as before): > > # chroot /mnt/RootRescue/ /usr/sbin/update-initramfs -u > update-initramfs: Generating /boot/initrd.img-2.6.26-2-amd64 > cryptsetup: WARNING: invalid line in /etc/crypttab - did you give that initramfs a try? the error you get indicated that the initramfs cryptroot hook tries to process a device that it doesn't find - or that is configured wrong - in /etc/crypttab. if you understand some shell scripting, then take a look at /usr/share/initramfs-tools/hooks/cryptroot. that's the script in question. it tries to determine root and resume devices and configures the initramfs to unlock them. is it possible that you have any resume devices? does any of the files /etc/uswsusp.conf, /etc/suspend.conf or /etc/initramfs-tools/conf.d/resume exist? if yes, what do they contain? > This made me think that there were initially 2 errors in the crypttab file > (and not just 2 error outputs) and that I had fixed one by being explict > about the UUID in the file: i gues that the explicit UUID finally caused the initramfs cryptroot hook to determine the root device correctly. maybe the remaining warning is about a resume device from one of the files i listed above. > # cat crypttab > sdb3_crypt UUID=dd1bf80b-904f-4a9f-97a3-39fd13fec034 none luks > > I figure something's strange with the "sdb3_crypt" designation and grepped > around for it. (As per the manpage, I'll call this the "target".) I found > it /etc/lvm/cache/.cache and deleted the file. (It'll either be re-created > or I'll restore my backup of it.) And re-updated initramfs. No change. > I've looked around in /etc and /proc and a few other places for "sdb3_crypt" > but am coming up empty. > > Who makes use of the target? I know that it gets used by cryptsetup to > populate my /dev/mapper/*, but when still in busybox, the 'mapper/'s haven't > been created yet. Is it referred to/by in any other location? sdb3_crypt is the target that cryptsetup creates as unlocked device. i guess that you do have a lvm volume group on top of the LUKS device. in that case lvm uses /dev/mapper/sdb3_crypt as physical volume for its volume group. i don't think that there's anything wrong with sdb3_crypt. theoretically you could give it any name. only lvm needs to find it when it makes the volume group available with vgchange. the disk partition from your external harddrive, sometimes known as /dev/sdb3, with UUID dd1bf80b-904f-4a9f-97a3-39fd13fec034 is the LUKS source device. when cryptsetup unlocks it, the target device /dev/mapper/sdb3_crypt is created. afterwards vgchange from lvm makes the volume group 'rescue' available to the kernel. now you have /dev/mapper/rescue-rooto, which holds the root filesystem of your rescue system. greetings, jonas
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
