Updated buildscripts (v2.2.8)

Bill's LFS Login lfsbill at wlmcs.com
Sun Apr 20 17:51:09 PDT 2003


On Sun, 20 Apr 2003, Bill's LFS Login wrote:

> On Sun, 20 Apr 2003, Erik-Jan wrote:
>
> > Bill's LFS Login wrote:
> ><snip>

> > Can you try the manual test again in src, with su and/or /stage1/bin/su?
>
> Yep. I was in tests/rm looking at scripts and forgot to cd. Will do the
> tests again. Away for a few hours - be late tonight (your time) before
> I can do it again. I suspect the su part will act the same though.

Before manual test, did the code from the script (upack fresh tarball et
al) and let it run through the test to get a baseline. This includes
your changes.

   Checking tarball install directory... coreutils-5.0
   Unpacking /mnt/archives/Globbed_Sources/coreutils-5.0.tar.bz2
    o coreutils-5.0 unpacked successfully
   ### Coreutils initial - (shared) - Sun Apr 20 19:10:19 EDT 2003 ###
    o Configure OK
    o Build OK
   XXXXXX Root Tests NOT OK - CHECK LOGS
   (/mnt/lfs/testlogs/coreutils-init.log-20030418) XXXXXX
   XXXXXX User Tests NOT OK - CHECK LOGS
   (/mnt/lfs/testlogs/coreutils-init.log-20030418) XXXXXX

The last few lines of the ${LOGFILE} for root test are

   cd rm    && make check TESTS=fail-2eperm
   make[2]: Entering directory `/mnt/lfs/usr/src/coreutils-5.0/tests/rm'
   make  check-TESTS
   make[3]: Entering directory `/mnt/lfs/usr/src/coreutils-5.0/tests/rm'
   bash: /root/.bashrc: Permission denied
   out exp differ: char 1, line 1
   1d0
   < bash: /root/.bashrc: Permission denied
   FAIL: fail-2eperm
   ======================================
   1 of 1 tests failed
   Please report to bug-coreutils at gnu.org
   ======================================

So, that part is as original problem I experienced.

Cd'd into coreutils-5.0/src and manually did

   useradd -M -s /bin/sh plfstest
   groupadd plfstest
   groupadd plfstest2
   mkdir a;chmod 1777 a;touch a/b

Then did   su --shell=/bin/sh -c 'rm -rf a' username  which gave

  /bin/bash: --shell=/bin/sh: unrecognized option
  Usage:  /bin/bash [GNU long opt ...

as expected. Then did

   /stage1/bin/su --shell=/bin/sh -c 'rm -rf a' lfsbill

which gave what should have been there

  ./rm: cannot remove `a': Permission denied

So the question of the day: why does the wrong su get picked when an
echo $PATH shows

  /stage1/bin:/stage1/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:
  /root/bin:/usr/X11R6/bin:/usr/src/qt-x11-free-3.0.5/bin

and ls -l /stage1/bin/su shows

  -r-sr-xr-x    1 root     root        15248 Apr 20 02:49 /stage1/bin/su

Methinks there is a secret link somewhere laddie! Maybe Greg or Ryan or
someone knows the cause of this? After all, the whole point of the new
PATH setting was to cause /stage1 stuff to be automatically found before
the stuff from the host system.

Now, a find /stage1 \( -name sh -o -name bash \) -ls show zip, so we
can presume that the new instance of the shell (spawned to exec su) came
from the host in /bin ("whereis" shows it there). Bash --version shows

   GNU bash, version 2.05a.0(1)-release (i686-pc-linux-gnu)
   Copyright 2001 Free Software Foundation, Inc.

Man su says, in part "The current environment is passed to the new
shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or
/sbin:/bin:/usr/sbin:/usr/bin for the super user. This may be changed
with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.

CAVEATS
       This version of su has many compilation options, only some of
       which may be in use at any particular site.".

/etc/login.defs has the ENV_SUPATH and ENV_PATH settings for su defined
as stated in the su man page.

I think there is a clue in here somewhere, but I can't put my finger on
it just yet. Shell forks, exec's su which either forks/execs or just
execs and the path is reset. But the first fork/exec of bash should
inherit the PATH of the parent, and therefore execing the /stage1/bin/su.
But it seems to *not* be doing this. LFS compilation options for bash or
su causing something wierd? Dunno. bash-2.05a bug? Dunno.

Anyway, I'm going to mod the script so that it acts as if your patch put
/stage1/bin ahead of the two su calls. Looks like that might be a good
thing, generally, because we can't tell what abberrations may be
encountered.

The user test also failed. Haven't looked at it yet to see what is going
on there. I suspect a similar 'su' problem.

The last few lines of the ${LOGFILE} for user test are (wrapped)

   User Tests
   ------------
   Making check in lib
   make[1]: Entering directory `/mnt/lfs/usr/src/coreutils-5.0/lib'
   make  check-am
   make[2]: Entering directory `/mnt/lfs/usr/src/coreutils-5.0/lib'
   make[2]: Nothing to be done for `check-am'.
   make[2]: Leaving directory `/mnt/lfs/usr/src/coreutils-5.0/lib'
   make[1]: Leaving directory `/mnt/lfs/usr/src/coreutils-5.0/lib'
   Making check in src
   make[1]: Entering directory `/mnt/lfs/usr/src/coreutils-5.0/src'
   rm -rf progs-readme progs-makefile
   echo chgrp chown chmod cp dd dircolors du ginstall link ln dir vdir ls
   mkdir mkfifo mknod mv readlink rm rmdir shred stat sync touch unlink
   cat cksum comm csplit cut expand fmt fold head join md5sum nl od paste
   pr ptx sha1sum sort split sum tac tail tr tsort unexpand uniq wc
   basename date dirname echo env expr factor false hostname id kill
   logname pathchk printenv printf pwd seq sleep tee test true tty whoami
   yes  uname chroot hostid nice pinky users who uptime stty df groups
   nohup chroot df hostid nice pinky stty su uname uptime users who nohup
   \
     | tr -s ' ' '\n' | sort -u > progs-makefile
     /bin/sh: progs-makefile: Permission denied
     make[1]: *** [check-README] Error 1
     make[1]: Leaving directory `/mnt/lfs/usr/src/coreutils-5.0/src'
     make: *** [check-recursive] Error 1

> > Erik-Jan

Holler if you need/discover something more!

Be safe.

-- 
Bill Maltby
lfsbill at wlmcs.com





-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list