Hi Everyone,
This is my fault. As Jon noted, I accidentally pushed out the
kernel-module-xfs rpm's for the new kernel. I'm sorry this happened.
I'm about halfway through writting the new scripts that check for this
sort of thing, but the kernels came before it was done.
I have taken the x86_64 kernel-module-xfs-2.6.18-164.15.1.el5 kernel
modules out of the security updates area's. I have also changed the
script enough so that the x86_64 xfs kernel module rpm's don't even get
built, so this shouldn't happen again.
Again, my apologies for pushing this out.
Troy Dawson
Doug Benjamin wrote:
> Hi Jon,
>
> Thank you very much for the tips. There is a collision between the xfs.ko installed from
> the package - kernel-module-xfs-2.6.18-164.15.1.el5.x86_64
> and installed from the kernel itself - kernel-2.6.18-164.15.1.el5.x86_64
>
> [root@ascwrk0 ~]# modinfo xfs
> filename: /lib/modules/2.6.18-164.15.1.el5/kernel/fs/xfs/xfs.ko
> license: GPL
> description: SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
> author: Silicon Graphics, Inc.
> srcversion: EB72D8E7117BE062A7B96A4
> depends:
> vermagic: 2.6.18-164.15.1.el5 SMP mod_unload gcc-4.1
> module_sig: 883e3504ba0dc94626fb156c52e660112225809762cffd6ffbe28ceb9572fdb3f3b51a48bc8a509e311d9de94c5269ad84dcf97db8606cbc4db62477
>
> I am not who is responsible for assembling the kernel-module-xfs package but I believe that there
> is a bug in it.
>
> thanks again for your help.
>
> Cheers,
>
> Doug Benjamin
>
>
> On Mar 21, 2010, at 10:26 AM, Jon Peatfield wrote:
>
>> On Sun, 21 Mar 2010, Doug Benjamin wrote:
>>
>>> Hello,
>>>
>>> Has anyone experienced this failure. xfs file system will not mount after a kernel upgrade.
>>> when SELinux is in permissive mode
>>>
>>> Here are the details:
>>>
>>>
>>> [root@ascwrk0 ~]# uname -a
>>> Linux ascwrk0.hep.anl.gov 2.6.18-164.15.1.el5 #1 SMP Tue Mar 16 18:44:51 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>>
>>> [root@ascwrk0 ~]# modinfo xfs
>>> filename: /lib/modules/2.6.18-164.15.1.el5/kernel/fs/xfs/xfs.ko
>>> license: GPL
>>> description: SGI XFS with ACLs, large block/inode numbers, no debug enabled
>>> author: Silicon Graphics, Inc.
>>> srcversion: CD41E32544B126D01477F5F
>>> depends:
>>> vermagic: 2.6.18-164.15.1.el5 SMP mod_unload gcc-4.1
>>>
>>>
>>> The error is Operation not permitted when trying to mount the existing xfs partition.
>>>
>>> If I role back the kernel to
>>>
>>> [root@ascwrk0 ~]# uname -a
>>> Linux ascwrk0.hep.anl.gov 2.6.18-164.11.1.el5 #1 SMP Wed Jan 20 00:57:09 EST 2010 x86_64 x86_64 x86_64 GNU/Linux
>>>
>>>
>>> and using this kernel module -
>>>
>>> [root@ascwrk0 ~]# modinfo xfs
>>> filename: /lib/modules/2.6.18-164.11.1.el5/kernel/fs/xfs/xfs.ko
>>> license: GPL
>>> description: SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
>>> author: Silicon Graphics, Inc.
>>> srcversion: EB72D8E7117BE062A7B96A4
>>> depends:
>>> vermagic: 2.6.18-164.11.1.el5 SMP mod_unload gcc-4.1
>>> module_sig: 883f3504b569fcd6ae2bfe7d51a34c11236e709d14c133b4bc8a959c91ef6630331b106c64cca97a09e2fed52ea7666ee49627c0342ef2e2e037723869
>>>
>>>
>>> mount is successful.
>>>
>>> When SELinux is set to disabled then the xfs filesystem mounts with the latest kernel. Any suggestions how to fix the problem so that I
>>> can set SELinux back to permissive mode
>> Where is the new xfs.ko comming from? I ask because I note that the latest sl kernels also include an xfs module package even on x86_64 while the recent previous versions have not since upstream include it xfs (on x86_64 at least).
>>
>> In the tree which includes the x86_64 versions of the updates I see:
>>
>> $ rpm -qlvp kernel-2.6.18-164.15.1.el5.x86_64.rpm | grep -i xfs.ko
>> -rwxr--r-- 1 root root 54872 Mar 16 23:53 /lib/modules/2.6.18-164.15.1.el5/kernel/fs/freevxfs/freevxfs.ko
>> -rwxr--r-- 1 root root 694824 Mar 16 23:53 /lib/modules/2.6.18-164.15.1.el5/kernel/fs/xfs/xfs.ko
>> $ rpm -qlvp kernel-module-xfs-2.6.18-164.15.1.el5-0.4-2.sl5.x86_64.rpm | grep -i xfs.ko
>> -rwxr--r-- 1 root root 13023126 Mar 17 19:59 /lib/modules/2.6.18-164.15.1.el5/kernel/fs/xfs/xfs.ko
>>
>> so it seems likely to cause problems for someone if both get pulled in.
>>
>> Because we use xfs on top of md (raid5) we need to apply a patch to all recent TUV/sl kernels - I don't bother to build the external xfs modules - and it seems to work ok for me (in permissive mode), and I get:
>>
>> $ dmesg | grep -i xfs
>> SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts
>> SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts
>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
>> SGI XFS Quota Management subsystem
>> XFS mounting filesystem md0
>> Ending clean XFS mount for filesystem: md0
>> SELinux: initialized (dev md0, type xfs), uses mountpoint labeling
>>
>> and from modinfo
>>
>> $ modinfo xfs
>> filename: /lib/modules/2.6.18-164.15.1.el5.D1/kernel/fs/xfs/xfs.ko
>> license: GPL
>> description: SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
>> author: Silicon Graphics, Inc.
>> srcversion: EB72D8E7117BE062A7B96A4
>> depends:
>> vermagic: 2.6.18-164.15.1.el5.D1 SMP mod_unload gcc-4.1
>> module_sig: 883f3504ba37a86402a1e72447a9a21112721909f70622edfb3f449efcf1edfdbb9caf8a0e89c2c960a08cfd4301f5a4679d1722966ad63a52b6c4d4c4
>>
>> which apart from the .D1 om the release/path looks much more like the output from the versions which work for you...
>>
>> --
>> /--------------------------------------------------------------------\
>> | "Computers are different from telephones. Computers do not ring." |
>> | -- A. Tanenbaum, "Computer Networks", p. 32 |
>> ---------------------------------------------------------------------|
>> | Jon Peatfield, _Computer_ Officer, DAMTP, University of Cambridge |
>> | Mail: [log in to unmask] Web: http://www.damtp.cam.ac.uk/ |
>> \--------------------------------------------------------------------/
>
--
__________________________________________________
Troy Dawson [log in to unmask] (630)840-6468
Fermilab ComputingDivision/LSCS/CSI/USS Group
__________________________________________________
|
