On 21 February 2010 15:53, Jonas Meurer <jonas@xxxxxxxxxxxxxxx> wrote:
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
hey selim,
On 21/02/2010 Selim Levy wrote:
> On 21 February 2010 12:10, Bryan Kadzban <bryan.kadzban@xxxxxxxxx> wrote:
> > Doesn't Debian's initramfs bring up udev and let you use theyon can use "UUID=..." instead of the device path both in /etc/fstab and
> > /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?
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
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
