From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ew0-f221.google.com (mail-ew0-f221.google.com [209.85.219.221]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 22 Feb 2010 07:59:57 +0100 (CET) Received: by ewy21 with SMTP id 21so794637ewy.22 for ; Sun, 21 Feb 2010 22:59:57 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20100221205328.GA19030@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> Date: Mon, 22 Feb 2010 01:59:57 -0500 Message-ID: <6294c32a1002212259q8641692g6355b4418177897a@mail.gmail.com> From: Selim Levy Content-Type: multipart/alternative; boundary=000e0cdfd85e27209504802afb37 Subject: Re: [dm-crypt] configuration files List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de --000e0cdfd85e27209504802afb37 Content-Type: text/plain; charset=ISO-8859-1 That help was invaluable. Thanks a ton. On 21 February 2010 15:53, Jonas Meurer wrote: > hey selim, > > On 21/02/2010 Selim Levy wrote: > > On 21 February 2010 12:10, Bryan Kadzban > wrote: > > > Doesn't Debian's initramfs bring up udev and let you use the > > > /dev/disk/by-*/ symlinks in crypttab? That's a *LOT* better way to > find > > > this drive (in your case, by-id might work, and by-uuid will almost > > > definitely work, assuming a new-enough udev that can find the UUID of a > > > LUKS volume). Maybe poke around in /dev/disk when you're at the > busybox > > > prompt, and see what you can find. > > > (If it doesn't bring up udev and let you use those symlinks, then ... > > > why not? :-P Not a question for you obviously, but more for the > Debian > > > maintainers.) > > > > > > Anyway, then you don't care which sd* name is given to this device, > > > since you're using an explicitly-guaranteed-stable name for it. > > > > > > > Hmmmm.... that's really interesting. I played around at the busybox > prompt > > and took down all the info in the /dev/disk/by-* directories (which do > get > > created). I redirected output of 'ls -alF' commands from those > directories > > to file and have the info available to me. > > > > So here's what I've now confirmed: > > When I boot into my main/internal hd, /dev/sda, sdb and sdc are the > > following: internal hd, cardreader, external hd (respectively). > > When I boot into my rescue/external system, they are the following: > internal > > hd, external hd, cardreader. > > > > How do I go about using the /dev/disk/by-* devices with dm-crypt? Does > it > > only require modifying, as before, /etc/fstab and /proc/cmdline? Or is > > there something else I should play around with? > > yon can use "UUID=..." instead of the device path both in /etc/fstab and > in /etc/crypttab. for example: > > /etc/fstab: > UUID=9385bada-5c09-a303-ee31-4fd23452af29 / ext3 errors=remount-ro 0 1 > > /etc/crypttab: > sdb3_crypt UUID=35bc3457-127a-4344-80bf-6cdfff232339 none luks > > /proc/cmdline: > BOOT_IMAGE=/vmlinuz-2.6.26-1-amd64 root=/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. > This yielded interesting results. 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 - 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: # cat crypttab sdb3_crypt UUID=dd1bf80b-904f-4a9f-97a3-39fd13fec034 none luks 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 found it /etc/lvm/cache/.cache and deleted the file. (It'll either be re-created 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_crypt" but am coming up empty. 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 haven't been created yet. Is it referred to/by in any other location? I really appreciate the on-going assistance. Cheers, Selim --000e0cdfd85e27209504802afb37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That help was invaluable.=A0 Thanks a ton.



On 21 February 2010 15:53, Jonas Meurer <jonas@freesources.o= rg> wrote:
hey selim,

On 21/02/2010 Selim Levy wrote:
> On 21 February 2010 12:10, Bryan Kadzban <bryan.kadzban@gmail.com> wrote:<= br>
> > Doesn't Debian's initramfs bring up udev and l= et you use the
> > /dev/disk/by-*/ symlinks in crypttab? =A0That's a *LOT* bette= r way to find
> > this drive (in your case, by-id might work, and by-uuid will almo= st
> > definitely work, assuming a new-enough udev that can find the UUI= D of a
> > LUKS volume). =A0Maybe poke around in /dev/disk when you're a= t the busybox
> > prompt, and see what you can find.
> > (If it doesn't bring up udev and let you use those symlinks, = then ...
> > why not? =A0:-P =A0Not a question for you obviously, but more for= the Debian
> > maintainers.)
> >
> > Anyway, then you don't care which sd* name is given to this d= evice,
> > since you're using an explicitly-guaranteed-stable name for i= t.
> >
>
> Hmmmm.... that's really interesting. =A0I played around at the bus= ybox prompt
> and took down all the info in the /dev/disk/by-* directories (which do= get
> created). =A0I redirected output of 'ls -alF' commands from th= ose directories
> to file and have the info available to me.
>
> So here's what I've now confirmed:
> When I boot into my main/internal hd, /dev/sda, sdb and sdc are the > following: internal hd, cardreader, external hd (respectively).
> When I boot into my rescue/external system, they are the following: in= ternal
> hd, external hd, cardreader.
>
> How do I go about using the /dev/disk/by-* devices with dm-crypt? =A0D= oes it
> only require modifying, as before, /etc/fstab and /proc/cmdline? =A0Or= is
> there something else I should play around with?

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<= br>
/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.

This yielded interesting results.
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 cmdline, but I'= ;m now convinced that the problem isn't there.)=A0 This time I only got= the error once (and not twice as before):

# chroot /mnt/RootRescue/ /usr/sbin/update-initramfs -u
update-initr= amfs: Generating /boot/initrd.img-2.6.26-2-amd64
cryptsetup: WARNING: in= valid line in /etc/crypttab -

This made me think that there were ini= tially 2 errors in the crypttab file (and not just 2 error outputs) and tha= t I had fixed one by being explict about the UUID in the file:

# cat crypttab
sdb3_crypt UUID=3Ddd1bf80b-904f-4a9f-97a3-39fd13fec03= 4 none luks

I figure something's strange with the "sdb3_cry= pt" designation and grepped around for it.=A0 (As per the manpage, I&#= 39;ll call this the "target".)=A0 I found it /etc/lvm/cache/.cach= e and deleted the file.=A0 (It'll either be re-created or I'll rest= ore my backup of it.)=A0 And re-updated initramfs.=A0 No change.=A0 I'v= e looked around in /etc and /proc and a few other places for "sdb3_cry= pt" but am coming up empty.

Who makes use of the target?=A0 I know that it gets used by cryptsetup = to populate my /dev/mapper/*, but when still in busybox, the 'mapper/&#= 39;s haven't been created yet.=A0 Is it referred to/by in any other loc= ation?

I really appreciate the on-going assistance.

Cheers,
Selim
--000e0cdfd85e27209504802afb37--