[Pkg-cryptsetup-devel] Bug#464673: Bug#464673: cryptsetup seems to try to load some padlock modules

[Jonas Meurer]

On 08/02/2008 Joachim Breitner wrote:
> Hi,

Hey,

> No, the module is present, but refused to load. I think the error
> message is identical to this one:
> 
> $ sudo modprobe padlock-aes
> FATAL: Error inserting padlock_aes (/lib/modules/2.6.24-1-686/kernel/drivers/crypto/padlock-aes.ko): No such device
> 
> This is from dmesg, from the kernel boot:
> 
> padlock: VIA PadLock not detected.
> padlock: VIA PadLock Hash Engine not detected.

ok. i can imagine that the issue here is about padlock-* modules being
built for debian linux 2.6.24 kernel per default, while they weren't
built for previous kernels.
now some initramfs magic tries to load them because they're available,
and this fails due to missing hardware (padlock modules seem to be for
hardware hash generators, which you obviously don't have).

> > > I also observed:
> > > $ strings /sbin/cryptsetup |grep -i padlock
> > > padlock-rng
> > > padlock-aes
> > > padlock-sha
> > 
> > the strings in /sbin/cryptsetup actually come from static linking
> > against libgcrypt:
> > 
> > $ strings /usr/lib/libgcrypt.a |grep -i padlock
> > padlock-rng
> > padlock-aes
> > padlock-sha
> 
> Ah, I see. But running gdb during initrd to find out which function by
> gcrypt caused this will be hard. And I just tried to cryptsetup open a
> loopback-file, without such an error.

The errors are obviously not produced by cryptsetup itself, but rather
by some initramfs magic. that's the reason why they only appear at boot
process, and not at invoking cryptdisks/cryptsetup manually.

the errors are harmless by the way, they just tell you that the required
hardware (a hardware hash generator) is missing.

> > Ok, so i believe that this is rather an issue with the debian linux 2.6.24
> > kernel, not with cryptsetup.
> 
> Should I reassign this bug then to the kernel package? Or gcrypt?

neither cryptsetup nor gcrypt seem to cause the issue. and the kernel
team should not be blamed for adding some new modules to be shipped
with the kernel image.
in my eyes the real problem is whatever initramfs script tries to load
the modules per default. maybe you should contact maximilian attems
<maks at debian.org> or the kernel team as maintainers of initramfs-tools,
they're usually quite responsive.

I've cc'ed debian-kernel at lists.debian.org in this mail.

greetings,
 jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20080208/73119e2c/attachment.pgp