On 02/09/2018 10:59 PM, Ken Moffat wrote:
On Fri, Feb 09, 2018 at 03:28:47PM -0600, Bruce Dubbs wrote:
Ken Moffat wrote:
On Fri, Feb 09, 2018 at 12:04:11PM -0600, Bruce Dubbs wrote:
Ken Moffat wrote:
UNSUPPORTED: misc/tst-ttyname

This is what I got on my system (i7-5820K, Haswell E):

FAIL: misc/tst-ttyname

Summary of test results:
        1 FAIL

I do not know why misc/tst-ttyname fails on my system and is unsupported on
yours.  I am doing a jhalfs build.

I've now rerun this on the host system (LFS as at 20171231).
This is as my normal user.

Looking at scripts/evaluate-test.sh reports unsupported if the test
returns 77, pass for 0, fail for any other value.

misc/tst-ttyname.out says -

warning: could not become root outside namespace (Operation not permitted)
info:  entering chroot 1
info:    testcase: basic smoketest
info:      ttyname: PASS {name="/dev/pts/5", errno=0}
info:      ttyname_r: PASS {name="/dev/pts/5", ret=0, errno=0}
warning: unshare (CLONE_NEWNS) failed: Operation not permitted
error: ../sysdeps/unix/sysv/linux/tst-ttyname.c:280: could not enter new mount 
namespace

and therefore misc/tst-ttyname.test-result says -

UNSUPPORTED: misc/tst-ttyname
original exit status 77

Google has various links for the unshare failing, most of which seem
to be talking about problems with containers.  But
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808915i#10 gave a
clue:

"It turns out that the Debian kernel is set up to disable
unprivileged users from unsharing the user namespace by default."

That was done by a patch, a sysctl to allow it perhaps went
upstream later, not sure.  (I found that out from
https://lwn.net/Articles/673597/ ).  Anyway, in _my_ config I avoid
extra namespaces like the plague ;-)

# CONFIG_CGROUPS is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set

I think that CONFIG_NAMESPACES is turned on by MULTIUSER, but all
the other namespaces are optional.

In particular, CONFIG_USER_NS is for containers.

Since you usually start from defconfig, I guess most of these are
turned on in your config.  If that is the case, I think you will
have to take time out to build and test glibc in a completed system
to see why it fails :-(

I have:
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set

I wondeer if the problem with misc/tst-ttyname is due to building in chroot
as the root user.


Well, that might be involved - but my initial results were from
building as root, but because all the result files were thrown away
I retried as a user on the host system.  And it turns out that
neither of use have CONFIG_USERNS.
I suppose I would need to hack jhalfs to not remove the extracted directory
after the instructions complete.

In any case, I have no problems saying the test may fail and moving on. One
failure out of almost 6000 should not be a big deal.

   -- Bruce

Also we probably need to clean up the glibc section on possible test
failures.  Most have not been seen for several years.


True, but they only turn up when we release and people start
building on older hardware.


I've now finished my fresh lfs build (based on lfs svn from 5. February or so) and start with the main build. I'll let you know asap what my test results will be.

I build in a qemu vm with currently 2GB of RAM, but can increase that when needed.

Bye
Tim

--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to