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