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
[r...@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:
[r...@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
[r...@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
[r...@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 -
[r...@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: [email protected] Web: http://www.damtp.cam.ac.uk/ |
\--------------------------------------------------------------------/
--
__________________________________________________
Troy Dawson [email protected] (630)840-6468
Fermilab ComputingDivision/LSCS/CSI/USS Group
__________________________________________________
