[pkg-cryptsetup-devel] Bug#507721: cryptsetup: Sometimes initrd ends up missing conf/conf.d/cryptroot file in it

[Christian Jaeger]

Yves-Alexis Perez wrote:
> On mer, 2008-12-03 at 22:34 +0100, Christian Jaeger wrote:
>   
>> Sometimes update-initramfs -v -k $kernelversion works and creates a
>> file 'conf/conf.d/cryptroot' in it, as can be seen by unpacking it
>> using gunzip and cpio; and in those cases, I can boot my laptop, which
>> has its root fs on /dev/mapper/main-root which is a logical volume on
>> a volume group consisting of a luks encrypted partition.
>>     
>
> Again, I never reproduced such an issue on any system I run cryptsetup
> on, nor any person I know (which means at least a dozen of systems).
>   

So this means something is different between those dozen of systems and 
mine.

Note that I cannot reproduce it at will either, as we've seen in the 
discussion of the bugreport on your package. But it seems always to be 
the case that with a newer kernel the problem either always happens, or 
never happens. It would be strange to blame that on the kernel version, 
I wouldn't expect this to be the trigger (but who knows). I'm always 
doing things the same way:

$ git remote update
$ git tag -v $tag_of_release_I_want
$ git reset --hard $tag_of_release_I_want
$ make oldconfig
$ make
# make install
# make modules_install
^- those two commands could be issued in the reverse order, dunno if I'm 
consistent here, "could this be the problem?"
# update-initramfs -v -k $kernelversion
^- normally by using my linux-initrd-createinstall script, exactly to be 
consistent and not have to remember the invocation of the 
update-initramfs too, but as shown this time (after having run into the 
problem again) I've explicitely *not* made use of my wrapper script, but 
directly issued "nohup update-initramfs -u -v -k 2.6.27.7".

Yesterday I've wondered whether it was because I had plugged in a number 
of usb sticks in a raid-0 array, since it might have confused the mdadm 
stuff during setup. But then after it didn't boot, I booted into the old 
kernel+initrd, removed my usb sticks, and ran the update-initramfs, and 
it still didn't create one that booted.

I notice that unblugging the sticks doesn't remove the raid entry from 
/proc/mdstat though, so maybe that program was still confused? (But then 
anyway, this is a new acquisition, at the time of my older bug report I 
didn't have those sticks, and I didn't have my new external usb disk 
either--the only thing I had was a single older usb stick that I usually 
only mounted for short times as it has my gpg key on it. So I didn't use 
raid back then so it can't be (only) raid related.)

I've moved parts of my root partition to a separate partition at some 
point in time, by using a symlink:

lrwxrwxrwx 1 root root 19 2008-09-06 03:22 /usr -> /mnt/rootextend/usr

This is from before my first bug report. Could this be the reason? (But 
then, why does the problem only happen sometimes, it needs a second 
influence still.)

> Could you attach the verbose log of a faulty initrd generation?
>   

I've shown the head and tail already. I'm attaching the full output now.

Christian.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: nohup.out
Url: http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20081204/d01381a9/attachment.txt