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@debian.org> or the kernel team as maintainers of initramfs-tools, they're usually quite responsive. I've cc'ed debian-kernel@lists.debian.org in this mail. greetings, jonas
Attachment:
signature.asc
Description: Digital signature