From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ew0-f219.google.com (mail-ew0-f219.google.com [209.85.219.219]) by mail.saout.de (Postfix) with ESMTP for ; Fri, 5 Mar 2010 20:36:52 +0100 (CET) Received: by ewy19 with SMTP id 19so547082ewy.22 for ; Fri, 05 Mar 2010 11:36:51 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20100222231224.GB15780@resivo.wgnet.de> References: <6294c32a1002171625m77251de0pd665b2cf0c4983ac@mail.gmail.com> <20100220085539.GA4809@resivo.wgnet.de> <6294c32a1002202042i7640ebbrd9899c5bfb33b49c@mail.gmail.com> <4B81691C.9020500@gmail.com> <6294c32a1002211218t25c774fft28e990bf9e2237f0@mail.gmail.com> <20100221205328.GA19030@resivo.wgnet.de> <6294c32a1002212259q8641692g6355b4418177897a@mail.gmail.com> <20100222111353.GA4661@resivo.wgnet.de> <6294c32a1002221340x7b538bf8g73c866b540328dd2@mail.gmail.com> <20100222231224.GB15780@resivo.wgnet.de> Date: Fri, 5 Mar 2010 14:36:51 -0500 Message-ID: <6294c32a1003051136r2518f983t18afdb057f7dd081@mail.gmail.com> From: Selim Levy Content-Type: multipart/alternative; boundary=000e0ce0d6604f02d8048112d68c Subject: Re: [dm-crypt] configuration files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --000e0ce0d6604f02d8048112d68c Content-Type: text/plain; charset=ISO-8859-1 Hi, 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 wrote: > let's see ... > > On 22/02/2010 Selim Levy wrote: > > On 22 February 2010 06:13, Jonas Meurer 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. > Agreed. > > > 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 ... > 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 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. > Ok. > > > > 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? > 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 not found message. I changed my (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. > > > 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. > > 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 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. > > 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. Cheers, Selim --000e0ce0d6604f02d8048112d68c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Apologies for the delay.=A0 I was working hard, then away, then = working hard again, then battling a nasty flu, then, then, then... all excu= ses, perhaps...=A0 I'm back and will continue to attempt to solve this = matter...


On 22 February 2010 18:12, Jonas Meurer = <jonas@freesources.org> wrote:
let's see ...=

On 22/02/2010 Selim Levy wrote:
> On 22 February 2010 06:13, Jonas Meurer <jonas@freesources.org> w= rote:
> > 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. =A0(I also made the change to cmd= line, but I'm
> > > now convinced that the problem isn't there.) =A0This tim= e 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 th= at the
> > initramfs cryptroot hook tries to process a device that it doesn&= #39;t find
> > - or that is configured wrong - in /etc/crypttab.
>
> Yes. =A0Despite the errors that I got, I did attempt to use (i.e. boot= ) the
> initramfs every single time. =A0I'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 devic= e.
otherwise your initramfs would ask you for a passphrase to unlock the
root device.

Agreed.
=A0
> > 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 confi= gures
> > the initramfs to unlock them.
> >
>
> Ok. =A0I'm far from being a shell script guru, but I can understan= d it quite
> well. =A0I looked at that file and see where you got the list of the f= ollowing
> files. =A0I 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 inte= rest
> but I turned up empty.

how about playing around with the file? you can easily add debugging<= br> 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 ...


<= br>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).=A0 Both my = root and my swap are dealt with in some manner...


=A0
> > 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 co= ntain?
> >
>
> Yes, I do have a resume device: it is my swap. =A0Of the files you men= tion
> (and that are in ...../hooks/cryptroot), I only have the last:
>
> # cat /mnt/RootRescue/etc/initramfs-tools/conf.d/resume
> RESUME=3D/dev/mapper/rescue-swapo

ok, that explains why to devices are processed by the cryptroot hook:=
the root device and the resume device.


Ok.
=

=A0
> > > 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 b= eing explict
> > > about the UUID in the file:
> >
> > i gues that the explicit UUID finally caused the initramfs cryptr= oot hook
> > to determine the root device correctly. maybe the remaining warni= ng is
> > about a resume device from one of the files i listed above.
> >
>
> Ok. =A0But given that /etc/crypttab only deals with the physical encry= pted
> device (as opposed to its logical volumes -- rooto and swapo), I'm= tempted
> to (perhaps naively) think that the problem is with opening the contai= ner --
> the LVM2 volume group. =A0When updating my initramfs, I'm getting = the
> cryptsetup error I mentioned before. =A0Upon booting, I never get aske= d for my
> dm-crypt password... =A0All of these things taken together lead me to = think
> that the problem doesn't lie with the swap/resume partition. =A0Bu= t I could
> very easily be wrong...

you're right. if you're not even asked for a dm-crypt passwor= d, 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?


There= is no relevant output at the boot process.=A0 If I wait long enough for bu= sybox to appear, then all its info appears...

The only initramfs err= ors 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 mo= dify my crypttab again.=A0 I removed the (original) 'sdb3_crypt' ta= rget (which was a name given automatically by Debian upon installation) and= renamed it to something that makes more sense to me: 'rescue'.=A0 = Lo and behold, I now no longer have an error upon updating initramfs.=A0 Wh= y or how should simply the target (name) change anything?
=A0
Well, at least now I get somewhere.=A0 Upon booting, I get the typic= al:

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 s= eems to help.=A0 I'm now more and more convinced that when cryptsetup g= ets called, my /dev/* have not yet been populated.=A0 I wanted to add debug= ging info, say a simple
echo `ls /dev/sd*`
just before the error I quoted above, but can't s= eem to find a relevant file and cryptsetup is a binary.=A0 How could I add = debugging info (upon boot) just before that cryptsetup error?=A0 In particu= lar, I will want to add debugging info about the devices and about which mo= dules are loaded.

I should mention that if I wait about 5 minutes for the busybox prompt,= I can manually luksOpen the drive in question.=A0 Could this be some sort = of a race condition that gets resolved with enough patience?

Searchi= ng around the internet, I found the following thread which seems similar, t= hough it is almost 2 years old:
htt= ps://bugs.launchpad.net/ubuntu/+source/linux/+bug/213279
Needless to say, they're dealing with an upgrade.=A0 I'm dealing wi= th a clean (not even yet complete) install...=A0 And a warm reboot makes no= difference at all to me.



> > sdb3_crypt is the target that cryptsetup creates as unlocked devi= ce. i
> > guess that you do have a lvm volume group on top of the LUKS devi= ce. 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 mak= es 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_cr= ypt is
> > created.
> > afterwards vgchange from lvm makes the volume group 'rescue&#= 39; available
> > to the kernel.
> > now you have /dev/mapper/rescue-rooto, which holds the root files= ystem
> > of your rescue system.
> >
>
> All of this makes sense and was already known to me. =A0And this is ye= t one
> more thing that makes me think that I'm having an LVM2 problem (as= opposed
> to a dm-crypt problem). =A0Opinions?

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.



Sorry.=A0 I meant the exact opposi= te and obviously agree with you.=A0 See my previous paragraph, in the same = email, above.


=A0
> (I think that /dev/mapper/sdb3_crypt is a horrible name -- it was chos= en
> automatically upon installation -- and wouldn't mind having someth= ing a
> little clearer. =A0This 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.


Well, that seems to have done something.=A0 I= 've tried renaming the target to random things and don't get errors= except with the original sdb3_crypt.=A0 Why would that be an issue?!?

Thanks for your continued support and apologies for my delays.<= br>
Cheers,
Selim
--000e0ce0d6604f02d8048112d68c--