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, 22 Feb 2010 12:14:01 +0100 (CET) Received: from dslb-088-068-043-055.pools.arcor-ip.net ([88.68.43.55] helo=resivo.wgnet.de) by mail01.freesources.org with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NjWEe-0008LM-0Y for dm-crypt@saout.de; Mon, 22 Feb 2010 11:13:57 +0000 Received: from resivo by resivo.wgnet.de with local (Exim 4.71) (envelope-from ) id 1NjWEc-0003Ur-5D for dm-crypt@saout.de; Mon, 22 Feb 2010 12:13:54 +0100 Date: Mon, 22 Feb 2010 12:13:54 +0100 From: Jonas Meurer Message-ID: <20100222111353.GA4661@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline In-Reply-To: <6294c32a1002212259q8641692g6355b4418177897a@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 --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hey, On 22/02/2010 Selim Levy wrote: > On 21 February 2010 15:53, Jonas Meurer wrote: > > yon can use "UUID=3D..." instead of the device path both in /etc/fstab = and > > in /etc/crypttab. for example: > > > > /etc/fstab: > > UUID=3D9385bada-5c09-a303-ee31-4fd23452af29 / ext3 errors=3Dremount-ro = 0 1 > > > > /etc/crypttab: > > sdb3_crypt UUID=3D35bc3457-127a-4344-80bf-6cdfff232339 none luks > > > > /proc/cmdline: > > BOOT_IMAGE=3D/vmlinuz-2.6.26-1-amd64 root=3D/dev/mapper/rescue-rooto ro > > > > you need to substitute the UUID in /etc/fstab with the UUID of > > /dev/mapper/rescue-rooto, and the UUID in /etc/crypttab with the one of > > /dev/sdb3. > > >=20 > This yielded interesting results. >=20 > 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 n= ow > convinced that the problem isn't there.) This time I only got the error > once (and not twice as before): >=20 > # 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. 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. 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? > 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. > # cat crypttab > sdb3_crypt UUID=3Ddd1bf80b-904f-4a9f-97a3-39fd13fec034 none luks >=20 > I figure something's strange with the "sdb3_crypt" designation and grepped > around for it. (As per the manpage, I'll call this the "target".) I fou= nd > it /etc/lvm/cache/.cache and deleted the file. (It'll either be re-creat= ed > or I'll restore my backup of it.) And re-updated initramfs. No change. > I've looked around in /etc and /proc and a few other places for "sdb3_cry= pt" > but am coming up empty. >=20 > Who makes use of the target? I know that it gets used by cryptsetup to > populate my /dev/mapper/*, but when still in busybox, the 'mapper/'s have= n't > been created yet. Is it referred to/by in any other location? 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. greetings, jonas --6TrnltStXW4iwmi0 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) iQEcBAEBCAAGBQJLgmboAAoJEHUY1PcOVR4zNdsH/24jCZkzRAyv6vsvXQxwq8my UNxqH74wFTc2ktJldrZY4QRVLGcM51BysW5yqboRUGBVcbJg5Cb/W4ZkzRztG/XE T4hdRcctpUSSDX+3hCx+I28J38R3PBos5jDFlwjOLRj7izc70A3BzveCoFbie9oY Bn0SLsTNIwuSuiaxTWhazHvfFNuyM2xk7hx8/C1RUPfE825KyY/aOmmfJM5A4PsQ wtqZoI1H9G/Je2AIgOEVEgaOHi/gf9T+HMb/6yR1Ibbwvhvur68L4iTkOJ+zea3B JCsKQV+m+RQIPl+JHdJMjCGkMgcEzICq3p1+dlCFyzD0Ak3dCX5CvX6rgFNOlvU= =gQDh -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0--