bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: coreutils 6.12 test-suite failure


From: Jarod Wilson
Subject: Re: coreutils 6.12 test-suite failure
Date: Wed, 18 Jun 2008 14:42:20 -0400
User-agent: KMail/1.9.9

On Friday 13 June 2008 04:29:17 pm Jim Meyering wrote:
> Jarod Wilson <address@hidden> wrote:
> > Hey there,
> >
> > Trying to reproduce a problem we (Red Hat) are seeing when building
> > coreutils 6.12 in our build system[*], and I ran into a slightly
> > different (and 100% reproduceable so far) test-suite failure. Log file
> > attached. Build is done on a system with a 2.6.18-based kernel (RHEL5.2),
> > building against 2.6.26-ish bits in a chrooted environment.
> >
> > [*] https://bugzilla.redhat.com/show_bug.cgi?id=442352
>
> Hi Jarod,
>
> Thanks for reporting that.
> First off, those failures are all in root-only tests.

Finally got around to running a new build with your follow-up patch.


> FAIL: misc/runcon-no-reorder.log (exit: 1)
> ==========================================
> + runcon root:system_r:unconfined_t:s0-s0:c0.c1023 true -j
> + diff -u out exp
> ...
> -runcon: invalid context: root:system_r:unconfined_t:s0-s0:c0.c1023: No
> such file or directory +runcon: runcon may be used only on a SELinux kernel
>
> While I know the low-level cause (an strace from Ondrej Vasik
> showed that /selinux/context doesn't exist in the chroot),
> up to now, I hadn't worried about this failure, because I
> thought it was specific to an (end-of-life) FC6 system.

As expected, this one still triggers.


> FAIL: cp/cp-a-selinux.log (exit: 1)
> ===================================
> ...
> + mkdir mnt
> + mkfs -t ext2 -F blob
> mkfs.ext2: No such file or directory
> + framework_failure
> + error_ 'failure in testing framework'
>
> I have already prepared the tiny patch that will make this
> failure skip the test rather than fail.

This one is indeed skipped.


> FAIL: cp/preserve-gid.log (exit: 1)
> ===================================
> ...
> + chown +0:+0 a0
> + create b0 1000 1000
> + echo b0
> + chown +1000:+1000 b0
> + create b1 1000 1001
> + echo b1
> + chown +1000:+1001 b1
> + create c0 0 1000
> + echo c0
> + chown +0:+1000 c0
> + create c1 0 1001
> + echo c1
> + chown +0:+1001 c1
> + t0 a0 0 0 cp
> + f=a0
> + shift
> + u=0
> + shift
> + g=0
> + shift
> + rm -f b
> + cp a0 b
> ++ stat -c '%u %g' b
> + s='0 103'
> + test 'x0 103' '!=' 'x0 0'
> + test 'x0 103' = 'x0 0'
> + echo './cp/preserve-gid: cp a0 b: 0 0 != 0 103'
> ./cp/preserve-gid: cp a0 b: 0 0 != 0 103
> + exit 1
>
> This one was trickier.  I think it must be the case that
> root's primary group is 103.  The test requires that it be 0.
> Can you confirm?  (i.e., run id -g -- or better, id -a to get all of them)
> I'll either adapt the test or make it skip in that case.

Ah, here we go... In this case, I'm doing a build in a mock chroot, as the 
user 'mockbuild', who (within the chroot) has a uid of 0, gid of 101:

mockbuild::0:101::/builddir:/bin/bash

Nb: for this run, the log actually says:
...
++ stat -c '%u %g' b
+ s='0 101'
+ test 'x0 101' '!=' 'x0 0'
+ test 'x0 101' = 'x0 0'
+ echo './cp/preserve-gid: cp a0 b: 0 0 != 0 101'
./cp/preserve-gid: cp a0 b: 0 0 != 0 101
+ exit 1


> FAIL: rm/fail-2eperm.log (exit: 1)
> ==================================
> ...
> ++ setuidgid nobody env
> PATH=/builddir/build/BUILD/coreutils-6.12/src:/usr/lib64/ccache:/usr/kerber
>os/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbi
>n:/usr/bin:/root/bin rm --version ++ sed -n '1s/.* //p'
> + rm_version=6.10
> + case $rm_version in
> + echo './rm/fail-2eperm: cannot access just-built rm as user nobody'
> ./rm/fail-2eperm: cannot access just-built rm as user nobody
> + fail=1
>
> FYI, this failure would have been avoided if the test had
> been run as suggested in README
[...]
> Nonetheless, reports like this are common enough that I'll
> make it so this test is skipped too, when this happens.

The tests are run in an entirely automated fashion as part of the rpm build 
process, never looked at the README... :)

But yeah, this one doesn't trigger anymore.

> Patch for two of those coming right up.
> I'll wait to hear back from you before addressing preserve-gid,
> and I'm not yet sure what to do about runcon-no-reorder.

HTH,

-- 
Jarod Wilson
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]