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.
ĸen
--
Truth, in front of her huge walk-in wardrobe, selected black leather
boots with stiletto heels for such a barefaced truth.
- Unseen Academicals
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
