Updated buildscripts (v2.2.8)

Ryan.Oliver at pha.com.au Ryan.Oliver at pha.com.au
Mon Apr 21 16:54:30 PDT 2003


Bill Maltby wrote:
> Hola Ryan!
Hey Bill :-)

> I've got the bit in my teeth here, so "perfection is acceptable". :)

> For the chapter 5 coreutils, "make -k check-root" I've managed to get
> all to pass when running as root. I'm running the 5.0 coreutils, but it
> appears to be the same as the previous version in this area.

I'm not doing a patch here because I'm in the middle of testing a step
at a time and don't want to patch until I've something near final. But I
thought I would pass these on.

> First, added the CANDIDATE_TMP_DIRS line and the symlinks for
> true/false.

True/false symlinks not required, see below...

> The first allows a test that was being skipped to run and
> the symlinks eliminate some aggravating messages in the log. The
> CANDID... needed only if the usual places are not separate partitions
> (/tmp, /var/tmp and /usr/tmp *IIRC*).

Yep, but you do run /var and /tmp as seperate partitions on the host don't
you :-)

There are other issues with this inside the chroot ch6. Have got around
this by mounting a new partition as lfs/tmp chapter 5 (only because I have
/tmp as a seperate partition on my host and mtab shows this in chroot. VERY
hackey as of course the mtab points to the REAL /tmp partition but we have
fooled the system into using our newly mounted one)

This isn't going to be easy to script to take into account all possible
host builds :-/

> Second, the fail-2eperm tests were *not* fixed by the EJ changes when
> running make -k check-root in chapter 5. The following fixes this so all
> tests pass now. Patch would be better, IMHO. I've added 3 leading spaces
> for readability here - remove 'em if you decide to use this.

Funnily enough I never have had an issue ch5 with coreutils make
check-root.
Only in chapter 6.

Easier fix is to add a non-root user with a valid shell early in the
password file :-) The fail-2eperm test requires a non-root user with a
valid shell, but it basically grabs the first non-root user it can find in
the password file and checks if what is listed as a the shell executes.
Unfortunately this means it thinks stuff like /bin/true is a valid shell :
-/. Damn hard doing a delete using /bin/true ;-)

Coreutils doesn't need true/false symlinks, that was showing up as I had
/bin/true as nobody's shell.
I've just added a user "plfstest" with group 100 (users)...

<SNIP patch>
Your patch kinda invalidates the fail-2eperm test, its meant to run as a
user, not root.

Hope this helps you out a bit with the coreutils crusade ;-)

Better get through the rest of my mail
Best Regards
Ryan


-- 
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