[dm-crypt] configuration files

[dm-crypt] configuration files

[Selim Levy]

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

Hello,

I've looked around but can't seem to find the solution to my seemingly
simple problem.  Anything pointing me in the right direction would be highly
appreciated.

I'm running debian (mostly) lenny on an x86_64.  I have been using dm-crypt
on an LVM volume group containing 2 logical volumes: one for my swap and one
for my root partition.  I'm very happy with it and everything is working
perfectly.  Recently, I wanted to install debian lenny to my external USB
hard drive as a "rescue" disk for my internal hard drive.  I have already
installed linux to my external USB drive before and, following a minor tweak
in my GRUB configuration file, everything worked well.  However, I can't
seem to get dm-crypt to work when booting from the external hard drive.

The cause:
During the CD installation of debian, the debian installer associates the
external hard drive to /dev/sdb.  However, following the installation, when
I boot *from* the external hard drive, the system associates it with
/dev/sda.  So essentially, I'm installing linux (and dm-crypt and everything
else) to /dev/sdb, though it will then be called /dev/sda when I boot from
it.

The question:
I've already made the necessary changes to GRUB and the /boot partition is
booting properly -- I can get a busybox prompt -- but I'm unable to continue
booting into the root partition.  Where are the files on /boot located that
must be changed in order for the boot partition to properly deal with the
dm-crypt encrypted LVM volume group?  I have already found the
conf/conf.d/cryptroot file within my initrd image and have modified both
lines in it.  (One line is for the root partition, the other for swap.)
I've modified the 'target=' and the 'source=' entries (on both llines) to
show 'sda3' as opposed to the original 'sdb3'.  What else must be changed?

Thanks in advance!
S

[-- Attachment #2: Type: text/html, Size: 1978 bytes --]

Re: [dm-crypt] configuration files

[Jonas Meurer]

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

hey sven,

On 17/02/2010 Selim Levy wrote:
> The cause:
> During the CD installation of debian, the debian installer associates the
> external hard drive to /dev/sdb.  However, following the installation, when
> I boot *from* the external hard drive, the system associates it with
> /dev/sda.  So essentially, I'm installing linux (and dm-crypt and everything
> else) to /dev/sdb, though it will then be called /dev/sda when I boot from
> it.
> 
> The question:
> I've already made the necessary changes to GRUB and the /boot partition is
> booting properly -- I can get a busybox prompt -- but I'm unable to continue
> booting into the root partition.  Where are the files on /boot located that
> must be changed in order for the boot partition to properly deal with the
> dm-crypt encrypted LVM volume group?  I have already found the
> conf/conf.d/cryptroot file within my initrd image and have modified both
> lines in it.  (One line is for the root partition, the other for swap.)
> I've modified the 'target=' and the 'source=' entries (on both llines) to
> show 'sda3' as opposed to the original 'sdb3'.  What else must be changed?

you need to change both /etc/crypttab and /etc/fstab on the rescue
system, and maybe even /etc/initramfs-tools/conf.d/resume.
afterwards you'll have to regenerate the initramfs image. the best way
to do so is to:
- unlock and mount the rootfs of your rescue system to /mnt/rescue
- copy /proc/modules, /proc/cmdline and /proc/devices to
  /mnt/rescue/proc
- bind-mount /dev to /mnt/rescue/dev: 'mount -o bind /dev /mnt/rescue/dev'
- chroot into /mnt/rescue/dev
- modify /proc/cmdline, /etc/crypttab and /etc/fstab
- run 'update-initramfs -u'

this is written down from memory, i hope that i didn't forget anything.

greetings,
 jonas

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

Re: [dm-crypt] configuration files

[Selim Levy]

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

Hi,

Thank you very much for your help.  I'm almost there, I think.


On 20 February 2010 03:55, Jonas Meurer <jonas@freesources.org> wrote:

> hey sven,
>
> On 17/02/2010 Selim Levy wrote:
> > The cause:
> > During the CD installation of debian, the debian installer associates the
> > external hard drive to /dev/sdb.  However, following the installation,
> when
> > I boot *from* the external hard drive, the system associates it with
> > /dev/sda.  So essentially, I'm installing linux (and dm-crypt and
> everything
> > else) to /dev/sdb, though it will then be called /dev/sda when I boot
> from
> > it.
> >
> > The question:
> > I've already made the necessary changes to GRUB and the /boot partition
> is
> > booting properly -- I can get a busybox prompt -- but I'm unable to
> continue
> > booting into the root partition.  Where are the files on /boot located
> that
> > must be changed in order for the boot partition to properly deal with the
> > dm-crypt encrypted LVM volume group?  I have already found the
> > conf/conf.d/cryptroot file within my initrd image and have modified both
> > lines in it.  (One line is for the root partition, the other for swap.)
> > I've modified the 'target=' and the 'source=' entries (on both llines) to
> > show 'sda3' as opposed to the original 'sdb3'.  What else must be
> changed?
>
> you need to change both /etc/crypttab and /etc/fstab on the rescue
> system, and maybe even /etc/initramfs-tools/conf.d/resume.
> afterwards you'll have to regenerate the initramfs image. the best way
> to do so is to:
> - unlock and mount the rootfs of your rescue system to /mnt/rescue
> - copy /proc/modules, /proc/cmdline and /proc/devices to
>  /mnt/rescue/proc
> - bind-mount /dev to /mnt/rescue/dev: 'mount -o bind /dev /mnt/rescue/dev'
> - chroot into /mnt/rescue/dev
> - modify /proc/cmdline, /etc/crypttab and /etc/fstab
> - run 'update-initramfs -u'
>


Just in case I had screwed things up myself prior to your reply and my new
attempts, I reinstalled Debian lenny onto the external USB drive (which I
call "rescue" or "external").

I booted back into my internal drive and attempted all of your
recommendations on the external drive:

<output for following omitted because no errors>
# cryptsetup luksOpen /dev/sdc3 rescue
# vgchange -a y rescue
# mount /dev/rescue/rooto /mnt/RootRescue/
# mount /dev/sdc2 /mnt/RootRescue/boot/
# mount -o bind /dev /mnt/RootRescue/dev


However, when I get to updating my initramfs, I get the following error:

# 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 -
cryptsetup: WARNING: invalid line in /etc/crypttab -

The contents of the rescue's /etc/crypttab, for which I've tried various
things is:
# cat crypttab
sdb3_crypt /dev/sdb3 none luks


I wonder whether my problem is related to which drive gets /dev/sdx
designation based upon which one booted.  When booted on my usual/internal
drive and with /dev still bind-mounted (above), I have
/mnt/RootRescue/dev/sda and ..../sdc well populated.  Nothing about sdb.
When I try to boot from the external drive, I get lots of sdb output
(particularly if I boot into "rescue" mode).  Don't know if that helps
any...

Thanks in advance for your assistance.

Cheers,
S

[-- Attachment #2: Type: text/html, Size: 4004 bytes --]

Re: [dm-crypt] configuration files

[Jonas Meurer]

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

hey selim,

first, which version of cryptsetup do you have installed?

On 20/02/2010 Selim Levy wrote:
> On 20 February 2010 03:55, Jonas Meurer <jonas@freesources.org> wrote:
> > On 17/02/2010 Selim Levy wrote:
> > > The cause:
> > > During the CD installation of debian, the debian installer associates the
> > > external hard drive to /dev/sdb.  However, following the installation,
> > > when I boot *from* the external hard drive, the system associates
> > > it with /dev/sda.  So essentially, I'm installing linux (and
> > > dm-crypt and everything else) to /dev/sdb, though it will then be
> > > called /dev/sda when I boot from it.
> > >
> > > The question:
> > > I've already made the necessary changes to GRUB and the /boot
> > > partition is booting properly -- I can get a busybox prompt -- but
> > > I'm unable to continue booting into the root partition.  Where are
> > > the files on /boot located that must be changed in order for the
> > > boot partition to properly deal with the dm-crypt encrypted LVM
> > > volume group?  I have already found the conf/conf.d/cryptroot file
> > > within my initrd image and have modified both lines in it.  (One
> > > line is for the root partition, the other for swap.) 
> > > I've modified the 'target=' and the 'source=' entries (on both llines) to
> > > show 'sda3' as opposed to the original 'sdb3'.  What else must be
> > > changed?
> >
> > you need to change both /etc/crypttab and /etc/fstab on the rescue
> > system, and maybe even /etc/initramfs-tools/conf.d/resume.
> > afterwards you'll have to regenerate the initramfs image. the best way
> > to do so is to:
> > - unlock and mount the rootfs of your rescue system to /mnt/rescue
> > - copy /proc/modules, /proc/cmdline and /proc/devices to
> >  /mnt/rescue/proc
> > - bind-mount /dev to /mnt/rescue/dev: 'mount -o bind /dev /mnt/rescue/dev'
> > - chroot into /mnt/rescue/dev
> > - modify /proc/cmdline, /etc/crypttab and /etc/fstab
> > - run 'update-initramfs -u'
> >
> 
> 
> Just in case I had screwed things up myself prior to your reply and my new
> attempts, I reinstalled Debian lenny onto the external USB drive (which I
> call "rescue" or "external").
> 
> I booted back into my internal drive and attempted all of your
> recommendations on the external drive:
> 
> <output for following omitted because no errors>
> # cryptsetup luksOpen /dev/sdc3 rescue
> # vgchange -a y rescue
> # mount /dev/rescue/rooto /mnt/RootRescue/
> # mount /dev/sdc2 /mnt/RootRescue/boot/
> # mount -o bind /dev /mnt/RootRescue/dev
> 
> 
> However, when I get to updating my initramfs, I get the following error:
> 
> # 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 -
> cryptsetup: WARNING: invalid line in /etc/crypttab -

i guess that means that the cryptroot initramfs hook doesn't find the
root device in /etc/crypttab. this is why you need to modify some files
in the chroot before actually creating the initramfs. the cryptroot
initramfs hook tries to determine the root device from /etc/fstab. i
guess that you don't have set the root device in /etc/fstab to
/dev/mapper/sdb3_crypt.

additionally you need to copy /proc/modules, /proc/cmdline and
/proc/devices from your working system into /proc at the chroot. these
files are uses by mkinitramfs. now chroot into the rescue system, and
modify /proc/cmdline and /etc/fstab acordingly.

> The contents of the rescue's /etc/crypttab, for which I've tried various
> things is:
> # cat crypttab
> sdb3_crypt /dev/sdb3 none luks

this looks correct. but how does /etc/fstab and /proc/cmdline look in
the rescue system?

> I wonder whether my problem is related to which drive gets /dev/sdx
> designation based upon which one booted.  When booted on my usual/internal
> drive and with /dev still bind-mounted (above), I have
> /mnt/RootRescue/dev/sda and ..../sdc well populated.  Nothing about sdb.
> When I try to boot from the external drive, I get lots of sdb output
> (particularly if I boot into "rescue" mode).  Don't know if that helps
> any...

yes, that is part of the problem. if you're sure that booting the rescue
system populates the external drive as sdb, then do the following
changes in the rescue chroot before running 'update-initramfs -u':
- set /dev/mapper/sdb3_crypt as rootfs in /etc/fstab
- set /proc/cmdline to "BOOT_IMAGE=/vmlinuz-2.6.26-2-amd64 root=/dev/mapper/sdb3_crypt ro"

greetings,
 jonas

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

Re: [dm-crypt] configuration files

[Selim Levy]

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

Hi Jonas,

Thank you for your continued help and input.

On 21 February 2010 06:27, Jonas Meurer <jonas@freesources.org> wrote:

> hey selim,
>
> first, which version of cryptsetup do you have installed?
>


I'm running Debian lenny and have installed everything through Debian's
package management system:

$ aptitude show cryptsetup
<.....>
Version: 2:1.0.6-7
<.....>

# cryptsetup --version
cryptsetup 1.0.6



>  On 20/02/2010 Selim Levy wrote:
> > On 20 February 2010 03:55, Jonas Meurer <jonas@freesources.org> wrote:
> > > On 17/02/2010 Selim Levy wrote:
> > > > The cause:
> > > > During the CD installation of debian, the debian installer associates
> the
> > > > external hard drive to /dev/sdb.  However, following the
> installation,
> > > > when I boot *from* the external hard drive, the system associates
> > > > it with /dev/sda.  So essentially, I'm installing linux (and
> > > > dm-crypt and everything else) to /dev/sdb, though it will then be
> > > > called /dev/sda when I boot from it.
> > > >
> > > > The question:
> > > > I've already made the necessary changes to GRUB and the /boot
> > > > partition is booting properly -- I can get a busybox prompt -- but
> > > > I'm unable to continue booting into the root partition.  Where are
> > > > the files on /boot located that must be changed in order for the
> > > > boot partition to properly deal with the dm-crypt encrypted LVM
> > > > volume group?  I have already found the conf/conf.d/cryptroot file
> > > > within my initrd image and have modified both lines in it.  (One
> > > > line is for the root partition, the other for swap.)
> > > > I've modified the 'target=' and the 'source=' entries (on both
> llines) to
> > > > show 'sda3' as opposed to the original 'sdb3'.  What else must be
> > > > changed?
> > >
> > > you need to change both /etc/crypttab and /etc/fstab on the rescue
> > > system, and maybe even /etc/initramfs-tools/conf.d/resume.
> > > afterwards you'll have to regenerate the initramfs image. the best way
> > > to do so is to:
> > > - unlock and mount the rootfs of your rescue system to /mnt/rescue
> > > - copy /proc/modules, /proc/cmdline and /proc/devices to
> > >  /mnt/rescue/proc
> > > - bind-mount /dev to /mnt/rescue/dev: 'mount -o bind /dev
> /mnt/rescue/dev'
> > > - chroot into /mnt/rescue/dev
> > > - modify /proc/cmdline, /etc/crypttab and /etc/fstab
> > > - run 'update-initramfs -u'
> > >
> >
> >
> > Just in case I had screwed things up myself prior to your reply and my
> new
> > attempts, I reinstalled Debian lenny onto the external USB drive (which I
> > call "rescue" or "external").
> >
> > I booted back into my internal drive and attempted all of your
> > recommendations on the external drive:
> >
> > <output for following omitted because no errors>
> > # cryptsetup luksOpen /dev/sdc3 rescue
> > # vgchange -a y rescue
> > # mount /dev/rescue/rooto /mnt/RootRescue/
> > # mount /dev/sdc2 /mnt/RootRescue/boot/
> > # mount -o bind /dev /mnt/RootRescue/dev
> >
> >
> > However, when I get to updating my initramfs, I get the following error:
> >
> > # 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 -
> > cryptsetup: WARNING: invalid line in /etc/crypttab -
>
> i guess that means that the cryptroot initramfs hook doesn't find the
> root device in /etc/crypttab. this is why you need to modify some files
> in the chroot before actually creating the initramfs. the cryptroot
> initramfs hook tries to determine the root device from /etc/fstab. i
> guess that you don't have set the root device in /etc/fstab to
> /dev/mapper/sdb3_crypt.
>

I've mounted my external root as /mnt/RootRescue.

I made all the modifications you suggested prior to updating my initramfs
image.  You are right that my /etc/fstab doesn't indicate
/dev/mapper/sdb3_crypt, though it does give the name associated with the
encrypted partition:

# cat /mnt/RootRescue/etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/rescue-rooto /               ext3    errors=remount-ro 0       1
/dev/sda2       /boot           ext3    defaults        0       2
/dev/mapper/rescue-swapo none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

For completeness, here's crypttab:
# cat /mnt/RootRescue/etc/crypttab
sdb3_crypt /dev/sdb3 none luks

The name of the encrypted drive is 'rescue'; it contains 2 LVM logical
volumes: 'rooto' and 'swapo'.

Looking at my main system (which runs great), I notice that the
/dev/mapper/XXX line within its /etc/fstab does not match its /etc/crypttab
and the differences between the 2 files are analogous to the ones above.
Here's what I mean (from my main system):

# cat /etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/crypto-rooto /               ext3    errors=remount-ro 0       1
/dev/sda6       /boot           ext3    defaults        0       2
/dev/sda5       /music          ext3    defaults        0       2
/dev/mapper/crypto-swapo none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

# cat /etc/crypttab
sda7_crypt /dev/sda7 none luks

Maybe I misunderstood you...?


additionally you need to copy /proc/modules, /proc/cmdline and
> /proc/devices from your working system into /proc at the chroot. these
> files are uses by mkinitramfs. now chroot into the rescue system, and
> modify /proc/cmdline and /etc/fstab acordingly.
>


I did all of these things prior to my last email.  I'm confirming that all
of that stuff is populated as you suggested.



> > The contents of the rescue's /etc/crypttab, for which I've tried various
> > things is:
> > # cat crypttab
> > sdb3_crypt /dev/sdb3 none luks
>
> this looks correct. but how does /etc/fstab and /proc/cmdline look in
> the rescue system?
>

The contents of /etc/fstab are above.  Here's my /proc/cmdline:

# cat /mnt/RootRescue/proc/cmdline
root=/dev/mapper/rescue-rooto ro quiet



> > I wonder whether my problem is related to which drive gets /dev/sdx
> > designation based upon which one booted.  When booted on my
> usual/internal
> > drive and with /dev still bind-mounted (above), I have
> > /mnt/RootRescue/dev/sda and ..../sdc well populated.  Nothing about sdb.
> > When I try to boot from the external drive, I get lots of sdb output
> > (particularly if I boot into "rescue" mode).  Don't know if that helps
> > any...
>
> yes, that is part of the problem. if you're sure that booting the rescue
> system populates the external drive as sdb, then do the following
> changes in the rescue chroot before running 'update-initramfs -u':
> - set /dev/mapper/sdb3_crypt as rootfs in /etc/fstab
> - set /proc/cmdline to "BOOT_IMAGE=/vmlinuz-2.6.26-2-amd64
> root=/dev/mapper/sdb3_crypt ro"
>

Pardon my ignorance, but wouldn't /dev/mapper/sdb3_crypt be the entire
encrypted physical partition?  I'm really just wanting to have my root set
to ..../sdb3_crypt's logical volume named 'rooto' (as opposed to 'swapo').
No?  Besides, this gives me a number of errors when I update my initramfs
image:

# chroot /mnt/RootRescue/ /usr/sbin/update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.26-2-amd64
device-mapper: table ioctl failed: No such device or address
Command failed
cryptsetup: WARNING: failed to determine cipher modules to load for
sdb3_crypt
cryptsetup: WARNING: invalid line in /etc/crypttab -

I've changed my /etc/fstab and /proc/cmdline back to what they were...

Thanks for your ongoing help.  It is very much appreciated!

Cheers,
Selim

[-- Attachment #2: Type: text/html, Size: 10241 bytes --]

Re: [dm-crypt] configuration files

[Selim Levy]

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

Oops... Sorry!  One small mistake in my post as I was playing around with
the fstab file.  The only difference is /dev/sdb2 (as opposed to /dev/sda2
that I said before) for rescue's /boot.

Here's is the proper output:

# cat /mnt/RootRescue/etc/fstab
# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/rescue-rooto /               ext3    errors=remount-ro 0       1
/dev/sdb2       /boot           ext3    defaults        0       2
/dev/mapper/rescue-swapo none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0

Regardless, that isn't the root of my problem.  (no pun intended)

Oops!
S


On 21 February 2010 14:46, Selim Levy <sjtlevy@gmail.com> wrote:

> Hi Jonas,
>
> Thank you for your continued help and input.
>
> On 21 February 2010 06:27, Jonas Meurer <jonas@freesources.org> wrote:
>
>> hey selim,
>>
>> first, which version of cryptsetup do you have installed?
>>
>
>
> I'm running Debian lenny and have installed everything through Debian's
> package management system:
>
> $ aptitude show cryptsetup
> <.....>
> Version: 2:1.0.6-7
> <.....>
>
> # cryptsetup --version
> cryptsetup 1.0.6
>
>
>
>>  On 20/02/2010 Selim Levy wrote:
>> > On 20 February 2010 03:55, Jonas Meurer <jonas@freesources.org> wrote:
>> > > On 17/02/2010 Selim Levy wrote:
>> > > > The cause:
>> > > > During the CD installation of debian, the debian installer
>> associates the
>> > > > external hard drive to /dev/sdb.  However, following the
>> installation,
>> > > > when I boot *from* the external hard drive, the system associates
>> > > > it with /dev/sda.  So essentially, I'm installing linux (and
>> > > > dm-crypt and everything else) to /dev/sdb, though it will then be
>> > > > called /dev/sda when I boot from it.
>> > > >
>> > > > The question:
>> > > > I've already made the necessary changes to GRUB and the /boot
>> > > > partition is booting properly -- I can get a busybox prompt -- but
>> > > > I'm unable to continue booting into the root partition.  Where are
>> > > > the files on /boot located that must be changed in order for the
>> > > > boot partition to properly deal with the dm-crypt encrypted LVM
>> > > > volume group?  I have already found the conf/conf.d/cryptroot file
>> > > > within my initrd image and have modified both lines in it.  (One
>> > > > line is for the root partition, the other for swap.)
>> > > > I've modified the 'target=' and the 'source=' entries (on both
>> llines) to
>> > > > show 'sda3' as opposed to the original 'sdb3'.  What else must be
>> > > > changed?
>> > >
>> > > you need to change both /etc/crypttab and /etc/fstab on the rescue
>> > > system, and maybe even /etc/initramfs-tools/conf.d/resume.
>> > > afterwards you'll have to regenerate the initramfs image. the best way
>> > > to do so is to:
>> > > - unlock and mount the rootfs of your rescue system to /mnt/rescue
>> > > - copy /proc/modules, /proc/cmdline and /proc/devices to
>> > >  /mnt/rescue/proc
>> > > - bind-mount /dev to /mnt/rescue/dev: 'mount -o bind /dev
>> /mnt/rescue/dev'
>> > > - chroot into /mnt/rescue/dev
>> > > - modify /proc/cmdline, /etc/crypttab and /etc/fstab
>> > > - run 'update-initramfs -u'
>> > >
>> >
>> >
>> > Just in case I had screwed things up myself prior to your reply and my
>> new
>> > attempts, I reinstalled Debian lenny onto the external USB drive (which
>> I
>> > call "rescue" or "external").
>> >
>> > I booted back into my internal drive and attempted all of your
>> > recommendations on the external drive:
>> >
>> > <output for following omitted because no errors>
>> > # cryptsetup luksOpen /dev/sdc3 rescue
>> > # vgchange -a y rescue
>> > # mount /dev/rescue/rooto /mnt/RootRescue/
>> > # mount /dev/sdc2 /mnt/RootRescue/boot/
>> > # mount -o bind /dev /mnt/RootRescue/dev
>> >
>> >
>> > However, when I get to updating my initramfs, I get the following error:
>> >
>> > # 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 -
>> > cryptsetup: WARNING: invalid line in /etc/crypttab -
>>
>> i guess that means that the cryptroot initramfs hook doesn't find the
>> root device in /etc/crypttab. this is why you need to modify some files
>> in the chroot before actually creating the initramfs. the cryptroot
>> initramfs hook tries to determine the root device from /etc/fstab. i
>> guess that you don't have set the root device in /etc/fstab to
>> /dev/mapper/sdb3_crypt.
>>
>
> I've mounted my external root as /mnt/RootRescue.
>
> I made all the modifications you suggested prior to updating my initramfs
> image.  You are right that my /etc/fstab doesn't indicate
> /dev/mapper/sdb3_crypt, though it does give the name associated with the
> encrypted partition:
>
> # cat /mnt/RootRescue/etc/fstab
> # /etc/fstab: static file system information.
> #
> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
> proc            /proc           proc    defaults        0       0
> /dev/mapper/rescue-rooto /               ext3    errors=remount-ro 0
> 1
> /dev/sda2       /boot           ext3    defaults        0       2
> /dev/mapper/rescue-swapo none            swap    sw              0       0
> /dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
>
> For completeness, here's crypttab:
> # cat /mnt/RootRescue/etc/crypttab
>
> sdb3_crypt /dev/sdb3 none luks
>
> The name of the encrypted drive is 'rescue'; it contains 2 LVM logical
> volumes: 'rooto' and 'swapo'.
>
> Looking at my main system (which runs great), I notice that the
> /dev/mapper/XXX line within its /etc/fstab does not match its /etc/crypttab
> and the differences between the 2 files are analogous to the ones above.
> Here's what I mean (from my main system):
>
> # cat /etc/fstab
> # /etc/fstab: static file system information.
> #
> # <file system> <mount point>   <type>  <options>       <dump>  <pass>
> proc            /proc           proc    defaults        0       0
> /dev/mapper/crypto-rooto /               ext3    errors=remount-ro 0
> 1
> /dev/sda6       /boot           ext3    defaults        0       2
> /dev/sda5       /music          ext3    defaults        0       2
> /dev/mapper/crypto-swapo none            swap    sw              0       0
> /dev/scd0       /media/cdrom0   udf,iso9660 user,noauto     0       0
>
> # cat /etc/crypttab
> sda7_crypt /dev/sda7 none luks
>
> Maybe I misunderstood you...?
>
>
> additionally you need to copy /proc/modules, /proc/cmdline and
>> /proc/devices from your working system into /proc at the chroot. these
>> files are uses by mkinitramfs. now chroot into the rescue system, and
>> modify /proc/cmdline and /etc/fstab acordingly.
>>
>
>
> I did all of these things prior to my last email.  I'm confirming that all
> of that stuff is populated as you suggested.
>
>
>
>> > The contents of the rescue's /etc/crypttab, for which I've tried various
>> > things is:
>> > # cat crypttab
>> > sdb3_crypt /dev/sdb3 none luks
>>
>> this looks correct. but how does /etc/fstab and /proc/cmdline look in
>> the rescue system?
>>
>
> The contents of /etc/fstab are above.  Here's my /proc/cmdline:
>
> # cat /mnt/RootRescue/proc/cmdline
> root=/dev/mapper/rescue-rooto ro quiet
>
>
>
>> > I wonder whether my problem is related to which drive gets /dev/sdx
>> > designation based upon which one booted.  When booted on my
>> usual/internal
>> > drive and with /dev still bind-mounted (above), I have
>> > /mnt/RootRescue/dev/sda and ..../sdc well populated.  Nothing about sdb.
>> > When I try to boot from the external drive, I get lots of sdb output
>> > (particularly if I boot into "rescue" mode).  Don't know if that helps
>> > any...
>>
>> yes, that is part of the problem. if you're sure that booting the rescue
>> system populates the external drive as sdb, then do the following
>> changes in the rescue chroot before running 'update-initramfs -u':
>> - set /dev/mapper/sdb3_crypt as rootfs in /etc/fstab
>> - set /proc/cmdline to "BOOT_IMAGE=/vmlinuz-2.6.26-2-amd64
>> root=/dev/mapper/sdb3_crypt ro"
>>
>
> Pardon my ignorance, but wouldn't /dev/mapper/sdb3_crypt be the entire
> encrypted physical partition?  I'm really just wanting to have my root set
> to ..../sdb3_crypt's logical volume named 'rooto' (as opposed to 'swapo').
> No?  Besides, this gives me a number of errors when I update my initramfs
> image:
>
>
> # chroot /mnt/RootRescue/ /usr/sbin/update-initramfs -u
> update-initramfs: Generating /boot/initrd.img-2.6.26-2-amd64
> device-mapper: table ioctl failed: No such device or address
> Command failed
> cryptsetup: WARNING: failed to determine cipher modules to load for
> sdb3_crypt
>
> cryptsetup: WARNING: invalid line in /etc/crypttab -
>
> I've changed my /etc/fstab and /proc/cmdline back to what they were...
>
> Thanks for your ongoing help.  It is very much appreciated!
>
> Cheers,
> Selim
>

[-- Attachment #2: Type: text/html, Size: 11728 bytes --]

Re: [dm-crypt] configuration files

[Bryan Kadzban]

Selim Levy wrote:
> The contents of the rescue's /etc/crypttab, for which I've tried various
> things is:
> # cat crypttab
> sdb3_crypt /dev/sdb3 none luks

So, from 1000 miles away...

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.

Re: [dm-crypt] configuration files

[Selim Levy]

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

Hi Brian,

Thanks for your input.

On 21 February 2010 12:10, Bryan Kadzban <bryan.kadzban@gmail.com> wrote:

> Selim Levy wrote:
> > The contents of the rescue's /etc/crypttab, for which I've tried various
> > things is:
> > # cat crypttab
> > sdb3_crypt /dev/sdb3 none luks
>
> So, from 1000 miles away...
>

That's fine.  I'm even further away! ;)


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

I'm definitely getting closer!  Thanks for your help!

Cheers,
Selim

[-- Attachment #2: Type: text/html, Size: 2503 bytes --]

Re: [dm-crypt] configuration files

[Jonas Meurer]

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

hey selim,

On 21/02/2010 Selim Levy wrote:
> On 21 February 2010 12:10, Bryan Kadzban <bryan.kadzban@gmail.com> 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.

greetings,
 jonas

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

Re: [dm-crypt] configuration files

[Selim Levy]

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

That help was invaluable.  Thanks a ton.



On 21 February 2010 15:53, Jonas Meurer <jonas@freesources.org> wrote:

> hey selim,
>
> On 21/02/2010 Selim Levy wrote:
> > On 21 February 2010 12:10, Bryan Kadzban <bryan.kadzban@gmail.com>
> 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

[-- Attachment #2: Type: text/html, Size: 4569 bytes --]

Re: [dm-crypt] configuration files

[Jonas Meurer]

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

hey,

On 22/02/2010 Selim Levy wrote:
> On 21 February 2010 15:53, Jonas Meurer <jonas@freesources.org> wrote:
> > 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 -

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=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?

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

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

Re: [dm-crypt] configuration files

[Selim Levy]

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

Hey,

On 22 February 2010 06:13, Jonas Meurer <jonas@freesources.org> wrote:

> hey,
>
> On 22/02/2010 Selim Levy wrote:
> > On 21 February 2010 15:53, Jonas Meurer <jonas@freesources.org> wrote:
> > > 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 -
>
> 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.
>

Yes.  Despite the errors that I got, I did attempt to use (i.e. boot) the
initramfs every single time.  I've rebooted my machine at least 30 times in
the past few days...


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

Ok.  I'm far from being a shell script guru, but I can understand it quite
well.  I looked at that file and see where you got the list of the following
files.  I didn't read through the whole file -- it is about 500 lines long
--, though I did grep around for various things that should be of interest
but I turned up empty.


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

Yes, I do have a resume device: it is my swap.  Of the files you mention
(and that are in ...../hooks/cryptroot), I only have the last:

# cat /mnt/RootRescue/etc/initramfs-tools/conf.d/resume
RESUME=/dev/mapper/rescue-swapo










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

Ok.  But given that /etc/crypttab only deals with the physical encrypted
device (as opposed to its logical volumes -- rooto and swapo), I'm tempted
to (perhaps naively) think that the problem is with opening the container --
the LVM2 volume group.  When updating my initramfs, I'm getting the
cryptsetup error I mentioned before.  Upon booting, I never get asked for my
dm-crypt password...  All of these things taken together lead me to think
that the problem doesn't lie with the swap/resume partition.  But I could
very easily be wrong...


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

All of this makes sense and was already known to me.  And this is yet one
more thing that makes me think that I'm having an LVM2 problem (as opposed
to a dm-crypt problem).  Opinions?

(I think that /dev/mapper/sdb3_crypt is a horrible name -- it was chosen
automatically upon installation -- and wouldn't mind having something a
little clearer.  This is far from being a priority, though.)

Thanks for the ongoing support!

Cheers,
Selim

[-- Attachment #2: Type: text/html, Size: 7353 bytes --]

Re: [dm-crypt] configuration files

[Jonas Meurer]

let's see ...

On 22/02/2010 Selim Levy wrote:
> On 22 February 2010 06:13, Jonas Meurer <jonas@freesources.org> wrote:
> > On 22/02/2010 Selim Levy wrote:
> > > 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 -
> >
> > 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.
> 
> Yes.  Despite the errors that I got, I did attempt to use (i.e. boot) the
> initramfs every single time.  I've rebooted my machine at least 30 times in
> the past few days...

ok, so the remaining issue is clearly not only about the resume device.
otherwise your initramfs would ask you for a passphrase to unlock the
root device.

> > 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.
> >
> 
> Ok.  I'm far from being a shell script guru, but I can understand it quite
> well.  I looked at that file and see where you got the list of the following
> files.  I didn't read through the whole file -- it is about 500 lines long
> --, though I did grep around for various things that should be of interest
> but I turned up empty.

how about playing around with the file? you can easily add debugging
code to it. printing some variables to stdout will help you to get a
better picture of the problem. for example let the script print every
device that is processed in the for-loop at the end of the script. check
the value of $nodes on line 358 after canonical_device() was invoked.
and check what exactly get_lvm_deps does ...

> > 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?
> >
> 
> Yes, I do have a resume device: it is my swap.  Of the files you mention
> (and that are in ...../hooks/cryptroot), I only have the last:
> 
> # cat /mnt/RootRescue/etc/initramfs-tools/conf.d/resume
> RESUME=/dev/mapper/rescue-swapo

ok, that explains why to devices are processed by the cryptroot hook:
the root device and the resume device.

> > > 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.
> >
> 
> Ok.  But given that /etc/crypttab only deals with the physical encrypted
> device (as opposed to its logical volumes -- rooto and swapo), I'm tempted
> to (perhaps naively) think that the problem is with opening the container --
> the LVM2 volume group.  When updating my initramfs, I'm getting the
> cryptsetup error I mentioned before.  Upon booting, I never get asked for my
> dm-crypt password...  All of these things taken together lead me to think
> that the problem doesn't lie with the swap/resume partition.  But I could
> very easily be wrong...

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?

> > 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.
> >
> 
> All of this makes sense and was already known to me.  And this is yet one
> more thing that makes me think that I'm having an LVM2 problem (as opposed
> to a dm-crypt problem).  Opinions?

i don't agree. the initramfs doesn't ask you for a passphrase to unlock
the LUKS device. and the LVM physical volume is on top of the LUKS
device. the LVM stuff cannot work as long as the underlying LUKS device
isn't unlocked.

> (I think that /dev/mapper/sdb3_crypt is a horrible name -- it was chosen
> automatically upon installation -- and wouldn't mind having something a
> little clearer.  This is far from being a priority, though.)

feel free to rename it once you figured out the problem. but at the
moment i would refrain from renaming as this only causes more confusion.

greetings,
 jonas

Re: [dm-crypt] configuration files

[Selim Levy]

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

Hi,

Apologies for the delay.  I was working hard, then away, then working hard
again, then battling a nasty flu, then, then, then... all excuses,
perhaps...  I'm back and will continue to attempt to solve this matter...


On 22 February 2010 18:12, Jonas Meurer <jonas@freesources.org> wrote:

> let's see ...
>
> On 22/02/2010 Selim Levy wrote:
> > On 22 February 2010 06:13, Jonas Meurer <jonas@freesources.org> wrote:
> > > On 22/02/2010 Selim Levy wrote:
> > > > 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 -
> > >
> > > 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.
> >
> > Yes.  Despite the errors that I got, I did attempt to use (i.e. boot) the
> > initramfs every single time.  I've rebooted my machine at least 30 times
> in
> > the past few days...
>
> ok, so the remaining issue is clearly not only about the resume device.
> otherwise your initramfs would ask you for a passphrase to unlock the
> root device.
>

Agreed.


> > > 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.
> > >
> >
> > Ok.  I'm far from being a shell script guru, but I can understand it
> quite
> > well.  I looked at that file and see where you got the list of the
> following
> > files.  I didn't read through the whole file -- it is about 500 lines
> long
> > --, though I did grep around for various things that should be of
> interest
> > but I turned up empty.
>
> how about playing around with the file? you can easily add debugging
> code to it. printing some variables to stdout will help you to get a
> better picture of the problem. for example let the script print every
> device that is processed in the for-loop at the end of the script. check
> the value of $nodes on line 358 after canonical_device() was invoked.
> and check what exactly get_lvm_deps does ...
>



I added a fair amount of debugging code and things seem ok to me (but I
truthfully don't really know what I should be looking for).  Both my root
and my swap are dealt with in some manner...




> > > 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?
> > >
> >
> > Yes, I do have a resume device: it is my swap.  Of the files you mention
> > (and that are in ...../hooks/cryptroot), I only have the last:
> >
> > # cat /mnt/RootRescue/etc/initramfs-tools/conf.d/resume
> > RESUME=/dev/mapper/rescue-swapo
>
> ok, that explains why to devices are processed by the cryptroot hook:
> the root device and the resume device.
>


Ok.



>  > > > 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.
> > >
> >
> > Ok.  But given that /etc/crypttab only deals with the physical encrypted
> > device (as opposed to its logical volumes -- rooto and swapo), I'm
> tempted
> > to (perhaps naively) think that the problem is with opening the container
> --
> > the LVM2 volume group.  When updating my initramfs, I'm getting the
> > cryptsetup error I mentioned before.  Upon booting, I never get asked for
> my
> > dm-crypt password...  All of these things taken together lead me to think
> > that the problem doesn't lie with the swap/resume partition.  But I could
> > very easily be wrong...
>
> 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.

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.

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?

Searching around the internet, I found the following thread which seems
similar, though it is almost 2 years old:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/213279
Needless to say, they're dealing with an upgrade.  I'm dealing with a clean
(not even yet complete) install...  And a warm reboot makes no difference at
all to me.



> > > 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.
> > >
> >
> > All of this makes sense and was already known to me.  And this is yet one
> > more thing that makes me think that I'm having an LVM2 problem (as
> opposed
> > to a dm-crypt problem).  Opinions?
>
> i don't agree. the initramfs doesn't ask you for a passphrase to unlock
> the LUKS device. and the LVM physical volume is on top of the LUKS
> device. the LVM stuff cannot work as long as the underlying LUKS device
> isn't unlocked.
>
>

Sorry.  I meant the exact opposite and obviously agree with you.  See my
previous paragraph, in the same email, above.




>  > (I think that /dev/mapper/sdb3_crypt is a horrible name -- it was chosen
> > automatically upon installation -- and wouldn't mind having something a
> > little clearer.  This is far from being a priority, though.)
>
> feel free to rename it once you figured out the problem. but at the
> moment i would refrain from renaming as this only causes more confusion.
>
>

Well, that seems to have done something.  I've tried renaming the target to
random things and don't get errors except with the original sdb3_crypt.  Why
would that be an issue?!?

Thanks for your continued support and apologies for my delays.

Cheers,
Selim

[-- Attachment #2: Type: text/html, Size: 11102 bytes --]

Re: [dm-crypt] configuration files

[Jonas Meurer]

[-- 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 --]

Re: [dm-crypt] configuration files

[Selim Levy]

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

Hello,


On 8 March 2010 06:52, Jonas Meurer <jonas@freesources.org> wrote:

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


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.

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.



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


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

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.

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?


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

Cheers,
Selim

[-- Attachment #2: Type: text/html, Size: 5994 bytes --]

Re: [dm-crypt] configuration files

[Selim Levy]

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

Hello again,

I just resolved my issue!

As soon as I discovered that /dev/sd* hadn't been populated yet but that
upon boot into busybox it *had* been populated, I figured I had some sort of
a USB problem.  The problem was not related to modules (which I didn't see
how it could be given that GRUB and the boot partitions were loaded fine).
The problem wasn't even related to dm-crypt in any way!  Apologies for the
crazy and wild goose chase.

The problem was that the kernel was attempting to mount the root filesystem
*before* the usb-storage driver was fully initialized.  (Why the initramfs
file on the boot partition was seen, as well as GRUB is completely beyong
me.  Strangely enough, when booting from the same external harddrive using a
non-encrypted filesystem, I don't have the same problem.)  The solution to
my problem was therefore, despite the runaround, quite trivial: I simply
added a rootdelay=10 as an option to the kernel line in GRUB's menu.lst.  I
can't believe that the problem was so trivial and that I was getting carried
away with everything else!  This doesn't explain, however, all the errors I
was getting when updating my initramfs.  Although I kept a meticulous diary
of all modifications I made (and I could likely therefore revert all my
changes), I think I will reinstall the OS and only make this change to GRUB
and see if it works...

Apologies for assuming that dm-crypt was the culprit (despite many things
pointing to this being the case).  A great big thanks for your continued
support Jonas and also to Bryan.

Woohoo!

Selim


On 8 March 2010 16:35, Selim Levy <sjtlevy@gmail.com> wrote:

> Hello,
>
>
> On 8 March 2010 06:52, Jonas Meurer <jonas@freesources.org> wrote:
>
>> 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.
>>
>
>
> 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.
>
> 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.
>
>
>
>>  > 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'.
>>
>
>
> 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).
>
> 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.
>
> 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?
>
>
>  > 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!
>
> Cheers,
> Selim
>

[-- Attachment #2: Type: text/html, Size: 8066 bytes --]

Re: [dm-crypt] configuration files

[Jonas Meurer]

[-- 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 --]