[Bugs] [Bug 1672480] Bugs Test Module tests failing on s390x

bugzilla at redhat.com bugzilla at redhat.com
Thu Mar 7 09:43:11 UTC 2019


--- Comment #58 from abhays <abhaysingh1722 at yahoo.in> ---
(In reply to Nithya Balachandran from comment #56)
> (In reply to abhays from comment #53)
> > (In reply to Nithya Balachandran from comment #51)
> > > > 
> > > > 
> > > > I don't think so. I would recommend that you debug the tests on your systems
> > > > and post patches which will work on both.
> > > 
> > > Please note what I am referring to is for you to look at the .t files and
> > > modify file names or remove hardcoding as required.
> > 
> > Yes @Nithya, We understood that you want us to continue debugging the tests
> > and provide patches if fix is found.
> > While doing the same, we were able to fix the ./tests/bugs/nfs/bug-847622.t
> > with the following patch:-
> > 
> > diff --git a/tests/bugs/nfs/bug-847622.t b/tests/bugs/nfs/bug-847622.t
> > index 3b836745a..f21884972 100755
> > --- a/tests/bugs/nfs/bug-847622.t
> > +++ b/tests/bugs/nfs/bug-847622.t
> > @@ -28,7 +32,7 @@ cd $N0
> > 
> >  # simple getfacl setfacl commands
> >  TEST touch testfile
> > -TEST setfacl -m u:14:r testfile
> > +TEST setfacl -m u:14:r $B0/brick0/testfile
> >  TEST getfacl testfile
> > 
> > Please check, if the above patch can be merged.
> > 
> > 
> This fix is incorrect. The patch changes the test to modify the brick
> directly while the test is to check that these operations succeed on the
> mount. You need to see why it fails and then we can figure out the fix.

Okay, thanks for the clarification. Below are some of the observations I made
for this test case:-
When brick is not changed and kept the way it is in the test case, then the
below happens on s390x:
getfacl /d/backends/brick0/testfile
getfacl: Removing leading '/' from absolute path names
# file: d/backends/brick0/testfile
# owner: root
# group: root

Whereas, on x86,
getfacl /d/backends/brick0/testfile
getfacl: Removing leading '/' from absolute path names
# file: d/backends/brick0/testfile
# owner: root
# group: root

Since the setfacl command fails,the above behavior is seen. When I checked the
On s390x, this is shown:-
D [MSGID: 0] [client-rpc-fops_v2.c:887:client4_0_getxattr_cbk]
0-patchy-client-0: remote operation failed: No data available. Path: /testfile
(fa921dc9-41a3-4fad-9fab-2c0933e54e38). Key: system.posix_acl_access
On x86, this is shown:-
D [MSGID: 0] [nfs3-helpers.c:1660:nfs3_log_fh_entry_call] 0-nfs-nfsv3: XID:
a2d2141c, LOOKUP: args: FH: exportid d7f43849-b25a-49d2-8084-aefb8d7797f2, gfid
00000000-0000-0000-0000-000000000001, mountid
8d32c8d1-0000-0000-0000-000000000000, name: libacl.so.1

Therefore, I tried remounting acl in the test case and even tried adding acl in
/etc/fstab in the following ways:-
In the test case-------> mount -o remount,acl /
In /etc/fstab----------> /dev     /boot/zipl  ext2  defaults,acl        0  2

However, the test case still fails. So, can you please provide us with some
details as to what happens when the commands;
EXPECT_WITHIN $NFS_EXPORT_TIMEOUT "1" is_nfs_export_available;
TEST mount_nfs $H0:/$V0 $N0 nolock
are run in the test case.

You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.

More information about the Bugs mailing list