Re: [dm-crypt] configuration files

[Selim Levy <sjtlevy@gmail.com>]

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