Re: Kernel tainted - no version for "loop_unregister_transfer"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



While answering your questions, I notice that modules.dep has  worked out that the already-loaded loop.ko is in initrd (that still exists in this distro and is not done away with):

/lib/modules/2.6.18.1/extra/loop_blowfish.ko: /lib/modules/2.6.18.1/initrd/loop.ko
/lib/modules/2.6.18.1/extra/loop_serpent.ko: /lib/modules/2.6.18.1/initrd/loop.ko
/lib/modules/2.6.18.1/extra/loop_twofish.ko: /lib/modules/2.6.18.1/initrd/loop.ko

The loop.ko in initrd is compiled from the standalone loopaes sources (currently); cipher modules in extra is compiled from the combined loop+cipher sources.

I know you said these loop.ko should have the same code - but could there be a difference that would do this?

The serpent module compiled from the standalone cipher sources inserted and appeared to work, while tainting the kernel.   But this serpent module from the combined sources won't insert at all.

====================

Answers to questions:

1 "Are you sure that /mnt/sda1/SOURCES/linux-2.6.18.1 kernel configuration is
exactly same as in the kernel you are booting?"

Yes.  I rebuilt the cd, the kernel running from the livecd was built by those sources.

There's no lilo or grub  - this is a livecd.  There's only that initrd.gz, and only the loop.ko driver needs to get loaded early in the boot along with usb and ide modules etc.  All of these were rebuilt for this kernel.  The only module that was built against the same kernel except with loop support enabled, that I haven't replaced, is unionfs, but that seems to be working without problems.

But Ithe loop.ko in initrd.gz was built from standalone loop-aes sources against the same kernel, which is why I was looking at md5sums - but you said the code for these should be identical and it was compiled against exactly the same kernel from the standalone loop-aes sources and worked.  Other modules in initrd.gz were also replaced with those compiled against this kernel.  The other ciphers are in /lib/modules/2.6.18.1/extra.

Is there any chance the preexisting stuff in /usr/src is confusing things with the combined loop+ciphers compile but not with the standalone sources?  My kernel sources are not in there, but there's other junk.





Pinpoint customers who are looking for what you sell.

[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux