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 12:52:52 +0100	[thread overview]
Message-ID: <20100308115251.GA4756@resivo.wgnet.de> (raw)
In-Reply-To: <6294c32a1003051136r2518f983t18afdb057f7dd081@mail.gmail.com>

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

hey,

On 05/03/2010 Selim Levy wrote:
> On 22 February 2010 18:12, Jonas Meurer <jonas@freesources.org> wrote:
> > 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 <device> not found
> message.

this message does not exist. please paste the _exact_ error 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.

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'.

> 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.

greetings,
 jonas

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

  reply	other threads:[~2010-03-08 11:52 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 [this message]
2010-03-08 21:35                       ` Selim Levy
2010-03-08 22:27                         ` Selim Levy
2010-03-08 22:37                         ` Jonas Meurer

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=20100308115251.GA4756@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.