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