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/ |
\--------------------------------------------------------------------/

Reply via email to