On 8 March 2010 06:52, Jonas Meurer <jonas@xxxxxxxxxxxxxxx> wrote:
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.
Ok. I added a printout of the /dev/sd* devices (and also the /dev/hd* just in case that was the issue) just after
Following my above comments and looking into this file, I agree with you.
Thanks for your continued and unfaltering support!
Cheers,hey,
On 05/03/2010 Selim Levy wrote:
> On 22 February 2010 18:12, Jonas Meurer <jonas@xxxxxxxxxxxxxxx> wrote:
> > you're right. if you're not even asked for a dm-crypt password, then thethis message does not exist. please paste the _exact_ error message.
> > 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 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 bysimply modify the initramfs cryptroot script at
> 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.
/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?
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, Iit could be possible, but the cryptroot script already contains loops in
> can manually luksOpen the drive in question. Could this be some sort of a
> race condition that gets resolved with enough patience?
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!
Selim
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
