Top posting because it is a long post, and the TL;DR is:
Use:
su nobody -s /bin/bash << EOF
command
EOF
instead of:
su nobody -s /bin/bash -c "command"
Now is the story with bottom posting...
On Sun, 2020-05-24 at 22:21 +0100, Ken Moffat via lfs-dev wrote:
> On Sun, May 24, 2020 at 10:16:34PM +0100, Ken Moffat wrote:
> > On Sun, May 24, 2020 at 07:35:10PM +0200, Pierre Labastie via lfs-
> > dev wrote:
> > > On Sun, 2020-05-24 at 16:44 +0200, Pierre Labastie via lfs-dev
> > > wrote:
> > > > Hi,
> > > > Here are test results from a jhalfs run:
> > > > [...
> > >
> > > about vim test
> > > > ===================================
> > > > [...]
> > > > -------------------
> > > > vim: stops at test1:
> > > > test1 FAILED - terminal size must be 80x24 or larger
> > > > Executed: 0 Tests
> > > > Skipped: 0 Tests
> > > > Failed: 0 Tests
> > >
> > > For some reason, my gnome terminal had 80 columns and 23 lines.
> > > Vim tests do not run if the number of lines is less than 24!
> > > and the number of columns is less than 80.
> > >
> > > Note that the in chroot the command "tty" returns "Not a tty",
> > > and that
> > > may explains some test failures, specially with bash tests
> > >
> > > Pierre
> > >
> > Hi Pierre,
> >
> > thanks for looking at this.
> >
> > One of the reasons why my build has taken so long is that I'm
> > trying
> > to look at every failign testsuite, to see if there is a way around
> > it. For some things (e.g. iproute) we just say it doesn't work -
> > at
> > the moment I don't know if it can work (needs libmna, and then it
> > wants sudo for rmmod), but in chroot I'm going to suggest it SHOULD
> > NOT be run and therefore its missing deps can be ignored.
> >
> > And in particular, I had not realised that tty fails like that. It
> > does indeed explain apparent failures in the bash tests. I wonder
> > if, instead of mounting dev/pts we should bind it ?
>
> Or, better - because we bind /mnt/lfs/dev to /dev, perhaps NOT mount
> /dev/pts in chroot ? In theory, that should give us what is on the
> host in /dev/pts, but then the group may be wrong if the host uses a
> different group from LFS.
Tried both:
- not mounting /dev/pts at all: /dev/pts is empty, so I guess it is
unusable
- binding /dev/pts: works, and "tty" returns /dev/fd/0 (progress)
Unfortunately, bash tests still fail because of:
/dev/tty: No such device or address
Now, tried the following (this is what is performed by one of the
tests:
-----
(lfs chroot)...# test -t 0 </dev/tty
(lfs chroot)...# echo $?
0
-----
But:
-----
(lfs chroot)...# su nobody -s /bin/bash \
-c "PATH=$PATH HOME=/home test -t 0 </dev/tty"
bash: /dev/tty: No such device or address
-----
So /dev/tty is not accessible to user "nobody". Note that it exists:
-----
(lfs chroot)...# su nobody -s /bin/bash \
-c "PATH=$PATH HOME=/home ls -l /dev/tty"
crw-rw-rw- 1 root tty 5, 0 May 25 09:28 /dev/tty
-----
At this point, I was lucky enough to find (by chance) tty(4):
"""
The file /dev/tty is a character file with major number 5 and minor
number 0, usually with mode 0666 and ownership root:tty. It is a syn‐
onym for the controlling terminal of a process, if any.
"""
And we have to understand where the "controlling terminal" is lost...
Ah, here we go: su(1) states, about the "-c" option:
"""
-c, --command COMMAND
Specify a command that will be invoked by the shell using its -c.
The executed command will have no controlling terminal. This option
cannot be used to execute interactive programs which need a
controlling TTY.
"""
Let's try (No quote on EOF: we need $PATH to be expanded):
su nobody -s /bin/bash << EOF
PATH=$PATH HOME=/home make tests
EOF
No more /dev/tty error. Still there are two errors, which were present
before too.
Now this has been done with /dev/pts bind mounted. Let's try with
/dev/pts mounted normally...
Same, that is: no /dev/tty error...
Pierre
--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
