libcrc32c.ko does not declare dependancy on crc32c.ko

Bug #681819 reported by Filofel
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
Tim Gardner
Fix Released
Tim Gardner

Bug Description

As a result, depmod doesn't report the dependancy in modules.dep, and initramfs doesn't pull crc32c.ko when a module declares libcrc32c.ko as a dependency.
I ran into this when I noticed I couldn't remote boot a machine that uses the bnx2x.ko 10Gb BroadCom Enet adapter.
bnx2x.ko depends on libcrc32c.ko another module, and all were properly present in initramfs. But the NIC driver didn't load. When attempting to manually insmod the module from the BusyBox, I realized libcrc32c was not loading, and insmod'ing libcrc32c from a fully booted machine, I realized it actually loaded crc32c.ko -- that didn't exist in the initramfs image.
Running modinfo on libcrc32c.ko shows no dependancy.
Consistently, modules.dep doesn't report any dependancy for libcrc32c.ko

This results in all kind of nasty irritating problems when libcrc32c.ko is needed in initramfs (including a number reported in launchpad), like when people try to use btrfs as their root and end up being unable to boot.

This problem has existed for a while, and has most likely been introduced with this patch:;a=commit;h=69c35efcf1576ab5f00cba83e8ca740923afb6c9

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: linux-image-2.6.35-23-generic 2.6.35-23.40 [modified: lib/modules/2.6.35-23-generic/kernel/drivers/net/bnx2.ko lib/modules/2.6.35-23-generic/kernel/drivers/net/cnic.ko]
Regression: No
Reproducible: Yes
ProcVersionSignature: Ubuntu 2.6.35-23.40-generic
Uname: Linux 2.6.35-23-generic i686
AlsaDevices: Error: command ['ls', '-l', '/dev/snd/'] failed with exit code 2: ls: cannot access /dev/snd/: No such file or directory
AplayDevices: aplay: device_list:235: no soundcards found...
Architecture: i386
ArecordDevices: arecord: device_list:235: no soundcards found...
Date: Fri Nov 26 15:48:34 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
MachineType: HP ProLiant DL380 G6

ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-23-generic root=UUID=727daec2-c6f1-43da-a59b-0831b8769949 ro debug ignore_loglevel radeon.nomodeset kgdb=ttyS0,115200 kgdboc=ttyS0,115200
SourcePackage: linux 10/14/2010
dmi.bios.vendor: HP
dmi.bios.version: P62
dmi.chassis.type: 23
dmi.chassis.vendor: HP
dmi.modalias: dmi:bvnHP:bvrP62:bd10/14/2010:svnHP:pnProLiantDL380G6:pvr:cvnHP:ct23:cvr: ProLiant DL380 G6
dmi.sys.vendor: HP

Revision history for this message
Filofel (filofel) wrote :
Revision history for this message
Tim Gardner (timg-tpi) wrote :

The simplest solution is likely to just set CONFIG_CRYPTO_CRC32C=y in the kernel config since there isn't a symbolic binding between lib/libcrc32c.c and crypto/crc32c.c

Have you tried adding 'crc32c' to /etc/modules ?

Revision history for this message
Filofel (filofel) wrote :


Acutally, once I figured out what was going wrong, I did work around the problem for myself: I just created a hook script in /etc/initramfs-tools with a
manual_add_modules crc32c
in it, and ran an
update-initramfs -u
and that was it. It didn't even require a kernel build.

But the reason I'm reporting it is because googling around, it seems that since that crc32 thing has been spilt in its two libcrc32c and crc32c parts, quite a few people are regularly bitten by this problem when trying to remote boot iSCSI, NFS or whatever other technique, and waste a few hours or more trying to figure out what's going wrong (been there, done that ;-) ).
So it's a nuisance, and it looks to me that it should be addressed.
I did noticed that libcrc32c dynamically loads a registered "crc32c" module, and that this is the reason why libcrc32c doesn't declare a dependency on crc32c, but I still think that the fact that this mechanism breaks depmod and whatever relies on it (like initramfs) is a problem.
Today, libcrc32c seems to pull a single module, crc32c. But even if tomorrow, it might pull any one of several, then the whole set of modules should be considered and made available when libcrc32c is required... instead of none as of today.
This could of course be solved in initramfs-tools by some hard coded exception handling of libcrc32c (in a similar way that an initramfs-tools function currently excludes arcnet, token ring, bnx2 and a few others), but there might be a better, smarter, more generic solution.

Revision history for this message
Tim Gardner (timg-tpi) wrote :


Changed in linux (Ubuntu Natty):
assignee: nobody → Tim Gardner (timg-tpi)
status: New → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 2.6.37-9.22

linux (2.6.37-9.22) natty; urgency=low

  [ Andy Whitcroft ]

  * rebase to v2.6.35-rc5
  * [Config] updateconfigs following rebase to v2.6.37-rc5
  * (no-up) add support for installed header files to ubuntu directory
    - LP: #684666
  * ubuntu: AUFS -- include the aufs_types.h file in linux-libc-headers
    - LP: #684666
  * ubuntu: dm-raid4-5 -- follow changes to bio flags
  * ubuntu: dm-raid4-5 -- re-enable
  * ubuntu: omnibook -- update BOM
  * ubuntu: ndiswrapper -- update BOM to match actual version
  * ubuntu: ndiswrapper -- follow removal of the BKL and locked ioctl
  * ubuntu: ndiswrapper -- re-enable
  * ubuntu: iscsitarget -- re-instate copy_io_context
  * ubuntu: iscsitarget -- follow changes to semaphore initialisation
  * ubuntu: iscsitarget -- convert NIPQUAD to %pI4
  * ubuntu: iscsitarget -- re-enable

  [ Kees Cook ]

  * [Config] update config for CONFIG_DEBUG_SET_MODULE_RONX

  [ Manoj Iyer ]

  * SAUCE: Enable jack sense for Thinkpad Edge 13
    - LP: #685015

  [ Tim Gardner ]

  * [Config] CONFIG_CRYPTO_CRC32C=y
    - LP: #681819
  * [Config] CONFIG_9P_FSCACHE=n
  * [Config] Add nfsd modules to -virtual flavour
    - LP: #688070

  [ Upstream Kernel Changes ]

  * Revert "Staging: zram: work around oops due to startup ordering snafu"
  * NFS: Fix panic after nfs_umount()
    - LP: #683938
  * x86: Add NX protection for kernel data
  * x86: Add RO/NX protection for loadable kernel modules
  * x86: Resume trampoline must be executable
  * x86: RO/NX protection for loadable kernel, jump_table fix

  [ Upstream Kernel Changes ]

  * rebase to v2.6.37-rc5
 -- Andy Whitcroft <email address hidden> Thu, 09 Dec 2010 18:15:35 +0000

Changed in linux (Ubuntu Natty):
status: Fix Committed → Fix Released
Revision history for this message
Filofel (filofel) wrote :

Looks very good to me!
Thanks, Tim!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.