[ATrpms-devel] openafs kmdls failing

[Angel Marin]

Axel Thimm wrote:
> On Fri, Sep 19, 2008 at 08:02:43AM +0200, Angel Marin wrote:
>> Axel Thimm wrote:
>>> On Thu, Sep 18, 2008 at 04:50:36PM +0200, Angel Marin wrote:
>>>> Angel Marin wrote:
>>>>> openafs kmdls do not build on 2.6.26 kernels without extra patches[1]. 
>>>>> Updated src.rpm (only built and tested on F9 x86_64):
>>>>>
>>>>> http://dl.anmar.eu.org/tmp/openafs-1.4.7-29.src.rpm
>>>>>
>>>>> [1]
>>>>> https://lists.openafs.org/pipermail/openafs-devel/2008-September/016166.html
>>>>>
>>>> Something must have gone wrong in build process (F9 x86_64) as 'modprobe 
>>>> libafs' reports:
>>>>
>>>> libafs: Unknown symbol init_pid_ns
>>>>
>>>> While the locally built one for the same kernel works :?
> 
>> Some googling suggests similar errors have happened when .config for the
>> build environment does not match the running kernel.
> 
> That would make sense, as the actual build host is running a different
> kernel. But this is only visible in uname output - headers, symbols
> etc. are all picked up from the target kernel.
> 
> Gary Buhrmaster pointed me to
> 
> http://bugs.gentoo.org/show_bug.cgi?format=multiple&id=232511

That find_task_by_vpid call mentioned there is what 
STABLE14-linux-2626-support-20080608.patch [1] is supposed to ifdef out.

Maybe the configure tests in [1] are wrongly detecting find_task_by_pid 
in your build environment?

I have rebuilt it again just in case, and it continues to work as 
expected with this patch.

[1] 
http://openafs.org/cgi-bin/wdelta/STABLE14-linux-2626-support-20080608?diff&f=u

> and also quoted that maybe more than just one patch is needed for
> 2.6.26 support. But OTOH you did well with only that one patch.
> 
> I'll forward you his mail in PM.

The second patch is STABLE14-linux-proc-removal-20080822 and I didn't 
include it as it worked without it :?

Both patches applied:

http://dl.anmar.eu.org/tmp/openafs-1.4.7-30.fc9.src.rpm

I can test the resulting kmdl before pushing it just to make sure it 
works :) BTW pruning the existing kmdls from the mirrors might make 
sense too.

There's still a couple more patches in 1.4.x branch we could try, but 
don't look like related to current problem. Though without being able to 
reproduce the failing builds locally it's going to be a pain :/

-- 
Angel Marin
http://anmar.eu.org/