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