All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonas Meurer <jonas@freesources.org>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] configuration files
Date: Mon, 8 Mar 2010 23:37:49 +0100	[thread overview]
Message-ID: <20100308223749.GA26748@resivo.wgnet.de> (raw)
In-Reply-To: <6294c32a1003081335n47c1b72cn93a2270afddea78c@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5722 bytes --]

hey selim,

in short: you're correct, this is a race condition. the usb device is
not available at the point cryptsetup tries to open it. this has been
fixed in subsequent cryptsetup package releases. read below for further
information.

On 08/03/2010 Selim Levy wrote:
> On 8 March 2010 06:52, Jonas Meurer <jonas@freesources.org> wrote:
> > On 05/03/2010 Selim Levy wrote:
> > > 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.
> >
> > this message does not exist. please paste the _exact_ error message.
> 
> This message does exist, because that is what I am getting.  In fact, thanks
> to your reply, below, I found it in
> /usr/share/initramfs-tools/scripts/local-top/cryptroot at line 199.  I
> cannot copy and paste it as it occurs after the grub boot selection but
> before the actual booting process.

ah, now i get the picture. you're using the cryptsetup package from
lenny/stable, right? the initramfs cryptroot scripts have evolved since
then. among others, the error message is replaced by a new one. but more
importantly, the script now has code to wait for usb devices to appear
in case that they don't exist. i suggest that you either upgrade the
cryptsetup package to a version from testing/unstable, or at least copy
the initramfs cryptroot script from a newer package to your system.

you can find the most recent version of scripts/local-top/cryptroot at
http://svn.debian.org/wsvn/pkg-cryptsetup/cryptsetup/trunk/debian/initramfs/cryptroot-script

> The error I get is:
> cryptsetup: source device <the_device_in_crypttab> not found
> 
> I could attach a low-res photo taken from a cell phone, if you wish.

not necessary any more.

> > simply modify the initramfs cryptroot script at
> > /usr/share/initramfs-tools/scripts/local-top/cryptroot. the code which
> > invokes cryptsetup begins at line 280. after modifying the script, don't
> > forget to update the initramfs with 'update-initramfs -u'.
> >
> 
> 
> Ok. I added a printout of the /dev/sd* devices (and also the /dev/hd* just
> in case that was the issue) just after
>     message "cryptsetup: source device $cryptsource not found"
> on line 199 and before the
>     return 1
> of line 200.  The only /dev/sd* devices found at that point are my /dev/sda*
> partitions, which are my internal harddrive partitions (and there are no
> /dev/hd*).  The devices relevant to my external hard drive (the /dev/sdb*)
> haven't been populated yet; however, I'm clearly accessing one of those
> partitions at that point (as my boot partition is on /dev/sdb2).

yes, some usb devices aren't available immediately. therefore, recent
versions of the initramfs cryptroot script loop up to 3 minutes before
they fail to setup the encrypted device.

> So now I'm thinking that this could be a USB module problem...  Looking at
> my working/internal hd's /proc/modules with my external hd mounted, I notice
> that I have various modules which don't appear in my external/rescue hd's
> /proc/modules.  Some of the ones that jump out at me are: hid, usbhid and
> usb_storage.  So I recopied my /proc/modules to the external drive's
> /proc/modules and compared the two files again.  It seems as though many of
> the /proc/modules aren't copied to the new location.  What the hell?!?  So I
> copied it by doing a `cat /proc/modules > [the external
> harddrive]/proc/modules`.  Finally the files compare equal.  I reboot and...
> nothing.  Same error as above indicating that the source device isn't found.

you already mentioned, that unlocking the device with cryptsetup
manually once you're in the busybox emergency shell works without any
problems. that clearly indicates that your initramfs doesn't miss any
drivers. you discovered a race condition.

> I know very little about initramfs and inserting modules into it, but I
> think that that is the next thing for me to research.  Comments or
> suggestions?

copy the initramfs cryptroot script from the svn url above to
/usr/share/initramfs-tools/scripts/local-top/cryptroot, update the
initramfs with 'update-initramfs -u', and hopefully your rescue system
finally works.

>  > 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?
> >
> > it could be possible, but the cryptroot script already contains loops in
> > order to wait for the source device to become available. see the
> > beginning of setup_mapping() in the script.
> >
> 
> Following my above comments and looking into this file, I agree with you.
> 
> 
> Thanks for your continued and unfaltering support!

sometimes it's hard to spot a simple problem. but at least both of us
should have learned from it ;-)

greetings,
 jonas

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

      parent reply	other threads:[~2010-03-08 22:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-18  0:25 [dm-crypt] configuration files Selim Levy
2010-02-20  8:55 ` Jonas Meurer
2010-02-21  4:42   ` Selim Levy
2010-02-21 11:27     ` Jonas Meurer
2010-02-21 19:46       ` Selim Levy
2010-02-21 20:40         ` Selim Levy
2010-02-21 17:10     ` Bryan Kadzban
2010-02-21 20:18       ` Selim Levy
2010-02-21 20:53         ` Jonas Meurer
2010-02-22  6:59           ` Selim Levy
2010-02-22 11:13             ` Jonas Meurer
2010-02-22 21:40               ` Selim Levy
2010-02-22 23:12                 ` Jonas Meurer
2010-03-05 19:36                   ` Selim Levy
2010-03-08 11:52                     ` Jonas Meurer
2010-03-08 21:35                       ` Selim Levy
2010-03-08 22:27                         ` Selim Levy
2010-03-08 22:37                         ` Jonas Meurer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100308223749.GA26748@resivo.wgnet.de \
    --to=jonas@freesources.org \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.