Apologies for the delay. I was working hard, then away, then working hard again, then battling a nasty flu, then, then, then... all excuses, perhaps... I'm back and will continue to attempt to solve this matter...
On 22 February 2010 18:12, Jonas Meurer <jonas@xxxxxxxxxxxxxxx> wrote:
Agreed.
I added a fair amount of debugging code and things seem ok to me (but I truthfully don't really know what I should be looking for). Both my root and my swap are dealt with in some manner...
Ok.
There is no relevant output at the boot process. If I wait long enough for busybox to appear, then all its info appears...
The only initramfs errors are the ones I mentioned before:
cryptsetup: WARNING: invalid line in /etc/crypttab -
Just on a random whim, and despite my better judgement, I decided to modify my crypttab again. I removed the (original) 'sdb3_crypt' target (which was a name given automatically by Debian upon installation) and renamed it to something that makes more sense to me: 'rescue'. Lo and behold, I now no longer have an error upon updating initramfs. Why or how should simply the target (name) change anything?
Well, at least now I get somewhere. Upon booting, I get the typical:
cryptsetup: source device <device> not found
message.
I changed my <device> (which was originally /dev/sdb3 and later modified by me to be given by UUID) in crypttab a few times, but nothing seems to help. I'm now more and more convinced that when cryptsetup gets called, my /dev/* have not yet been populated. I wanted to add debugging info, say a simple
echo `ls /dev/sd*`
just before the error I quoted above, but can't seem to find a relevant file and cryptsetup is a binary. How could I add debugging info (upon boot) just before that cryptsetup error? In particular, I will want to add debugging info about the devices and about which modules are loaded.
I should mention that if I wait about 5 minutes for the busybox prompt, I can manually luksOpen the drive in question. Could this be some sort of a race condition that gets resolved with enough patience?
Searching around the internet, I found the following thread which seems similar, though it is almost 2 years old:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/213279
Needless to say, they're dealing with an upgrade. I'm dealing with a clean (not even yet complete) install... And a warm reboot makes no difference at all to me.
Sorry. I meant the exact opposite and obviously agree with you. See my previous paragraph, in the same email, above.
Well, that seems to have done something. I've tried renaming the target to random things and don't get errors except with the original sdb3_crypt. Why would that be an issue?!?
Thanks for your continued support and apologies for my delays.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 andok, so the remaining issue is clearly not only about the resume device.
> > > 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...
otherwise your initramfs would ask you for a passphrase to unlock the
root device.
Agreed.
> > if you understand some shell scripting, then take a look athow about playing around with the file? you can easily add debugging
> > /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.
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 ...
I added a fair amount of debugging code and things seem ok to me (but I truthfully don't really know what I should be looking for). Both my root and my swap are dealt with in some manner...
> > is it possible that you have any resume devices? does any of the filesok, that explains why to devices are processed by the cryptroot hook:
> > /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
the root device and the resume device.
Ok.
> > > This made me think that there were initially 2 errors in the crypttab fileyou're right. if you're not even asked for a dm-crypt password, then the
> > > (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...
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?
There is no relevant output at the boot process. If I wait long enough for busybox to appear, then all its info appears...
The only initramfs errors are the ones I mentioned before:
cryptsetup: WARNING: invalid line in /etc/crypttab -
Just on a random whim, and despite my better judgement, I decided to modify my crypttab again. I removed the (original) 'sdb3_crypt' target (which was a name given automatically by Debian upon installation) and renamed it to something that makes more sense to me: 'rescue'. Lo and behold, I now no longer have an error upon updating initramfs. Why or how should simply the target (name) change anything?
Well, at least now I get somewhere. Upon booting, I get the typical:
cryptsetup: source device <device> not found
message.
I changed my <device> (which was originally /dev/sdb3 and later modified by me to be given by UUID) in crypttab a few times, but nothing seems to help. I'm now more and more convinced that when cryptsetup gets called, my /dev/* have not yet been populated. I wanted to add debugging info, say a simple
echo `ls /dev/sd*`
just before the error I quoted above, but can't seem to find a relevant file and cryptsetup is a binary. How could I add debugging info (upon boot) just before that cryptsetup error? In particular, I will want to add debugging info about the devices and about which modules are loaded.
I should mention that if I wait about 5 minutes for the busybox prompt, I can manually luksOpen the drive in question. Could this be some sort of a race condition that gets resolved with enough patience?
Searching around the internet, I found the following thread which seems similar, though it is almost 2 years old:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/213279
Needless to say, they're dealing with an upgrade. I'm dealing with a clean (not even yet complete) install... And a warm reboot makes no difference at all to me.
i don't agree. the initramfs doesn't ask you for a passphrase to unlock
> > 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?
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.
Sorry. I meant the exact opposite and obviously agree with you. See my previous paragraph, in the same email, above.
> (I think that /dev/mapper/sdb3_crypt is a horrible name -- it was chosenfeel free to rename it once you figured out the problem. but at the
> automatically upon installation -- and wouldn't mind having something a
> little clearer. This is far from being a priority, though.)
moment i would refrain from renaming as this only causes more confusion.
Well, that seems to have done something. I've tried renaming the target to random things and don't get errors except with the original sdb3_crypt. Why would that be an issue?!?
Cheers,
Selim
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
