let's see ... On 22/02/2010 Selim Levy wrote: > On 22 February 2010 06:13, Jonas Meurer <jonas@xxxxxxxxxxxxxxx> wrote: > > On 22/02/2010 Selim Levy wrote: > > > 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. > > Yes. Despite the errors that I got, I did attempt to use (i.e. boot) the > initramfs every single time. I've rebooted my machine at least 30 times in > the past few days... ok, so the remaining issue is clearly not only about the resume device. otherwise your initramfs would ask you for a passphrase to unlock the root device. > > 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. > > > > Ok. I'm far from being a shell script guru, but I can understand it quite > well. I looked at that file and see where you got the list of the following > files. I didn't read through the whole file -- it is about 500 lines long > --, though I did grep around for various things that should be of interest > but I turned up empty. how about playing around with the file? you can easily add debugging code to it. printing some variables to stdout will help you to get a better picture of the problem. for example let the script print every device that is processed in the for-loop at the end of the script. check the value of $nodes on line 358 after canonical_device() was invoked. and check what exactly get_lvm_deps does ... > > 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? > > > > Yes, I do have a resume device: it is my swap. Of the files you mention > (and that are in ...../hooks/cryptroot), I only have the last: > > # cat /mnt/RootRescue/etc/initramfs-tools/conf.d/resume > RESUME=/dev/mapper/rescue-swapo ok, that explains why to devices are processed by the cryptroot hook: the root device and the resume device. > > > 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. > > > > Ok. But given that /etc/crypttab only deals with the physical encrypted > device (as opposed to its logical volumes -- rooto and swapo), I'm tempted > to (perhaps naively) think that the problem is with opening the container -- > the LVM2 volume group. When updating my initramfs, I'm getting the > cryptsetup error I mentioned before. Upon booting, I never get asked for my > dm-crypt password... All of these things taken together lead me to think > that the problem doesn't lie with the swap/resume partition. But I could > very easily be wrong... you're right. if you're not even asked for a dm-crypt password, then the initramfs doesn't even know about the propper root device to unlock. what exactly is the output you see at the boot process? does the initramfs output any warnings or errors? > > 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. > > > > All of this makes sense and was already known to me. And this is yet one > more thing that makes me think that I'm having an LVM2 problem (as opposed > to a dm-crypt problem). Opinions? i don't agree. the initramfs doesn't ask you for a passphrase to unlock the LUKS device. and the LVM physical volume is on top of the LUKS device. the LVM stuff cannot work as long as the underlying LUKS device isn't unlocked. > (I think that /dev/mapper/sdb3_crypt is a horrible name -- it was chosen > automatically upon installation -- and wouldn't mind having something a > little clearer. This is far from being a priority, though.) feel free to rename it once you figured out the problem. but at the moment i would refrain from renaming as this only causes more confusion. greetings, jonas _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
