From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail01.freesources.org (mail01.freesources.org [80.237.252.149]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 8 Mar 2010 12:52:55 +0100 (CET) Received: from dslb-094-219-181-130.pools.arcor-ip.net ([94.219.181.130] helo=resivo.wgnet.de) by mail01.freesources.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NobW1-00020m-KF for dm-crypt@saout.de; Mon, 08 Mar 2010 11:52:54 +0000 Received: from resivo by resivo.wgnet.de with local (Exim 4.71) (envelope-from ) id 1NobW0-0000ua-6h for dm-crypt@saout.de; Mon, 08 Mar 2010 12:52:52 +0100 Date: Mon, 8 Mar 2010 12:52:52 +0100 From: Jonas Meurer Message-ID: <20100308115251.GA4756@resivo.wgnet.de> References: <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> <6294c32a1003051136r2518f983t18afdb057f7dd081@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <6294c32a1003051136r2518f983t18afdb057f7dd081@mail.gmail.com> Subject: Re: [dm-crypt] configuration files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hey, On 05/03/2010 Selim Levy wrote: > On 22 February 2010 18:12, Jonas Meurer 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? > > >=20 >=20 > There is no relevant output at the boot process. If I wait long enough f= or > busybox to appear, then all its info appears... >=20 > The only initramfs errors are the ones I mentioned before: > cryptsetup: WARNING: invalid line in /etc/crypttab - >=20 > Just on a random whim, and despite my better judgement, I decided to modi= fy > my crypttab again. I removed the (original) 'sdb3_crypt' target (which w= as > 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 t= he > target (name) change anything? >=20 > Well, at least now I get somewhere. Upon booting, I get the typical: >=20 > cryptsetup: source device not found > message. this message does not exist. please paste the _exact_ error 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 hel= p. > 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 f= ile > and cryptsetup is a binary. How could I add debugging info (upon boot) j= ust > 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 --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJLlOUNAAoJEHUY1PcOVR4zcWYIAKiaLExKY07KOxOHipwFeOYy 2NyYaFE7LS+JIQpHDxG8r0aoU4qnlR0C79hqinQxokpfRp6u7wD45sPKiPkQUldv kTzJ1OJJgUoUscJlGgcF9a7naezrJkOn3qZqkQWQWNU/v3EY6tURGEFewCTK5Vl6 b9xBOUi40+Nj10ZMfdLw0Doo/gNfsfrT0q6Z9rYIaoG+XKR/KOh96mZoqDe8Xvll iYRhHCXZihRopJXd90+U4VBJhg7QmLlvVLwmQ6Q7Q1UxX7gF5MpTMNWo20ZTjo/K vJ/5qayAPNy43+mBatG1+i67Nw370rQcZXD/vFrWVIbwwDSnPLtGdOOQZvknt/Y= =85dB -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO--