Comment 3 for bug 681819

Tim,

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.