PLFS coreutils checks (was Re: Updated buildscripts (v2.2.8))

Bill's LFS Login lfsbill at
Tue Apr 22 06:11:47 PDT 2003

On Tue, 22 Apr 2003 Ryan.Oliver at wrote:

> Bill Maltby wrote:
> > Although set +h has no nasty effect if we run the script
> > <snip>

> Yeah, I'm wondering where this went now :-/ Mind you I don't have any
> scripts in front of me today...
> > Anyway, I've added set +h into my local copy so if I do this again, I
> > won't get shafted by this.
> It **SHOULD** go into the init script...
> > The question now is how much of what I've done is valid, how much is
> > waste and how much of everybody's time has been wasted by my screw-up?
> There's only one way to find out ;-)

OK. I've attached a patch that reflects what I've been testing on my
system. It tested good for both the coreutils and fileutils install
*except* for a fail-2eperm test in User tests, which should not be run

Unfortunately, this isn't *exactly* what I run because I have all
symlinks with -f added, cp's have -a (to preserve timestamps) and I
change all make check/test commands to have 0k. So I also break the
conditional execution to let things keep running even if a test fails.
But I have tried to remove those sorts of changes from the patch. IOW,
it is as close as I can get to your original with only changes related
to things that seem needed. More on that later.


> Firstly the new scripts (which BTW will be 2.3.0, version info is being
> split from the init script) create a temporary plfstest user (group users,
> also added to temporary group plfstest) with no home directory ( -M in
> useradd, same as erik's, but so far has no check to see if the user already
> exists or not )


> The reason why I haven't had any issues so far is no shell is specified for
> my hosts nobody user (a glaring oversight on my behalf, at least it ain't
> net connected) so that user could happily run tests.
> Ch6 was a different story (shell being /bin/true)

I haven't gone to chapter 6 yet. But I think I'm good to go when I
complete the part of Ch 5 after coreutils.


> What it seems we need to rectify is (for everybody)
> a) the permissions issue for non-root user running tests.
>    I haven't had an issue but it seems you and erik have, so it needs
> fixing.
>    a chmod -R o+wx tests would do it... (IIRC that had to be done anyway
>    on earlier versions of coreutils)


> b) proper evaluation of the non-root user having a valid shell during the
>    make check-root fail-2eperms test (maybe check the shell against a list
> of
>    valid shells, and we can't assume there is an /etc/shells file )
>    Don't know if I like the whoami fix, bashcentric stuff don't cut it for
>    patches upstream...

I think this is included - I have all the changes from Erik, you and my
local adjustments to fix the apparent issues.

> c) we have to take into account that not all people split up their /tmp
> /var
>    directories onto separate partitions (avoids fragging up normal
> partitions)
>    The CANDIDATE_TMP_DIRS export can do this but would have to be set by
> the
>    user running the script.

Included. But mine is right in chapter 5 and it belongs in build-init as
Erik mentioned.

>    This gets hairier inside the chroot chapter 6 if the LFS build directory
>    resides only on one partition, as /etc/mtab will show the mounts seen
>    OUTSIDE the chroot, so the tests see (in my case) /tmp as a separate
>    partition and use it. Tests fail because inside the chroot it ISN'T a
>    separate partition.
>    The only way around I can see is to mount another partition before
>    chrooting onto the $LFS tree as the same as the CANDIDATE_TMP_DIR
> chosen.
>    Smells hackey to me, and might not be an option for some folk.

For systems that have the mount --bind ability, they can mount any old
dir from another partition. That's what I do. Normally I would have
several parts for var, maybe usr and so forth. But on a system that is
constantly being rebuilt, I forego that security and have my /home and
other such things separate. So I mount --bind a sub-dir from one of

> Anyway, discussion is open on this one, ideas people?

I'll postpone discussing until I start a fresh run from scratch and
confirm the minimum set of changes needed when set +h is active. I've had
a run that looked good with user nobody (IIRC, not sure now) and just
chmod on dirs (IIRC). maybe a couple others. Following is just comments on
the patch.

First, I *think* I have all changes posted by everyone to-date included
*except* things which seemed to not cure my problems (remember that I
had no set +h active, so I could have been mislead). Because of the
various confusions and the time involved, I'm not sure I have it all and
I'm not sure I needed to do what I have done. *sigh*

Patch includes a re-symlink of /stage1 because I swapped partitions and
mount points for this run to preserve what I had already working. That
pointed out the need for a symlink (at least here).

Changed the test for gawk version slightly to allow multiple 3.1
versions to work without change. Of course, this needs adjustment if
there is no patch for the version being used.

Has the add of plfstest user/group.

Has the CANDIDATE_TMP_DIRS - needs changing/relocation to init.

Has coreutils test stuff conditionally executed for 5.0/not-5.0 to make
sure I didn't get stuff needed only for 5.0 into other versions.

Around the set permissions, I added a find/chmod of dirs. Either the
permissions or the find stuff can probably be eliminated? A matching
remove of the mods on dirs follows later in the script.

Includes the removal of the new user/group.

Has the expect 1.3 STTY_READS_STDOUT 1 fix included.

The build-ch6-toolchain has set +h added.

Build-init includes versions for the finish of chap 6 - ignore that for
now. I've tested a prior version (using Ryan's base stuff he provided)
but not tested the latest stuff through boot of system.

But I included it so that the versions of the other stuff can be seen.
Also includes the missing ';;' in the new case.

Again, I don't recall offhand which stuff came from who now (I could
pull up the mail and see) but I think I've got all except Erik's newly
discovered BASH_ENV thing. Haven't been able to test it yet.


> Regards
> Ryan

Bill Maltby
lfsbill at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bills-2.2.8.patch.bz2
Type: application/octet-stream
Size: 3432 bytes
URL: <>

More information about the lfs-dev mailing list