[pkg-cryptsetup-devel] Bug#562427: Bug#562427: Fwd: Bug#562427: cryptsetup: Cannot enter luks pass phrase with USB keyboard during boot

[John Martin]

On Sun, Feb 21, 2010 at 7:43 PM, Jonas Meurer <jonas at freesources.org> wrote:
> [[...]] where does this driver-policy file come from? it sets
> MODULES=dep, and thus overwrites MODULES=most from
> initramfs.conf. maybe that's the problem?

Indeed, the problem is with /etc/initramfs-tools/conf.d/driver-policy.
Where did it come from?

1) Mod date corresponds to the time initial system install.

2) Logs indicate that a few minutes later initramfs-tools 0.92o was
replaced by initramfs-tools 0.920.

3) I find no sign of a driver-policy file in either of the
initramfs-tools .deb files.

4) I did not compose the driver-policy file and I did not directly
place it in /etc/initramfs-tools/conf.d.  It can be there only as a
side effect of something else.

I would welcome suggestions where else to look.  As much effort as has
gone into this problem I would be willing to spend some more to nail
this down, but I have no idea at the moment where to look.

> why did you add the modules in the first place? did you already try
> to remove them from the file again?

Yes, to no avail.

I added those four modules, usbhid, hid, usbcore, and nls_base,
because it appeared to me that those modules were not there during
boot to support the USB keyboard for the luks pass phrase.

> [[...]] unfortunately i'm busy with other things at the moment, and
> only have limited time to help you with debugging an issue that's
> not even related to the cryptsetup package at all. but let's see ...

Thank you.  Your help and patience has been very much appreciated.

What now?  This is now clearly not a bug in cryptsetup.  Should this
bug be held open _somewhere_ pending a witch hunt for the origin of
the driver-policy file and maybe why it remained in place?  I dunno
when I might have a chance to try to reproduce the install on a the
same or a similar box.  In any event, unless it would be pointless, I
should perhaps try to look for other packages that may have been
involved with initramfs-tools during or immediately after initial
installation.  I would welcome a list of plausible suspects.  Recall
this was/is a devastating bug for someone with only a USB keyboard
booting an encrypted system.  It might inhabit only amd64 boxen?

Should this bug be closed now with the intent to open a new bug when a
plausible source of the driver-policy file is isolated?