On 22 February 2010 06:13, Jonas Meurer <jonas@xxxxxxxxxxxxxxx> wrote:
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. 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.
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. 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...
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 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.)
Thanks for the ongoing support!
Cheers,
Selim
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 anddid you give that initramfs a try? the error you get indicated that the
> > 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 -
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...
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.
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
> This made me think that there were initially 2 errors in the crypttab filei gues that the explicit UUID finally caused the initramfs cryptroot hook
> (and not just 2 error outputs) and that I had fixed one by being explict
> about the UUID in the file:
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...
> # cat crypttabsdb3_crypt is the target that cryptsetup creates as unlocked device. i
> 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?
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 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.)
Thanks for the ongoing support!
Cheers,
Selim
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
