Re: Race condition in module load causing undefined symbols

[Steve Lord <lord@xfs.org>]

Thanks Prarit,

I updated mkinitrd from 4.1.18 to 4.2.15 and udev from 039 to 058.
This appears to have cured it on my work machine, I will try the
other box later.

Looking at Documentation/Changes, which appears to still be the
official repository for required tool versions, it seems somewhat
dated, and makes no mention of mkinitrd version requirements.

Steve

Prarit Bhargava wrote:
> Colleagues,
> 
> (Copied and edited from a post I made on linux-hotplug-devel last month.)
> 
> I've privately emailed Steve with a quick-and-dirty solution for the 
> problems he was experiencing with the system boot.  I wasn't sure if he 
> was having the same problems I've had with 2.6.12 and old packages but 
> it looks like he was.
> 
> I'm surprised we haven't had more people on this list wondering about 
> the strange behaviour of their initrd/initramfs :) .
> 
> When I looked at the original output Steve had posted I noticed that it 
> looked like drivers were attempting to load at the same time and because 
> of this he eventually hit an oops.  I (and an engineer from another 
> company working on another arch) have hit the same problem due to the 
> requirements of our current work.
> 
> (Unfortunately, I'm more familiar with RedHat/Fedora than I am with 
> other distro's -- please bear with me.)
> 
> The issue is that David Howells posted a patch that changed the 
> behaviour of kallsyms/insmod/rmmod sometime ago.  The patch *is correct* 
> in what it does, however, the patch requires that /sbin/sh must be aware 
> of pid returns by wait().
> 
>     http://lkml.org/lkml/2005/1/17/132
> 
> There are two fixes that I'm aware of, and depending on what you're 
> doing they are both "correct" (although in the case of developing in 
> 2.6.12, IMO, you
> _must_ do the latter).
> 
> The first fix is for the situation where you're developing for a 
> specific distribution.  If this is the case, then you should back out 
> the patch above and continue moving forward.
> 
> The second fix, and again you must do this if you're developing 2.6.12, 
> is to *update the mkinitrd package* which has a new version of /bin/sh.
> 
> P.
>