PLFS coreutils checks (was Re: Updated buildscripts (v2.2.8))
Ryan.Oliver at pha.com.au
Ryan.Oliver at pha.com.au
Mon Apr 21 20:40:59 PDT 2003
Bill Maltby wrote:
> Although set +h has no nasty effect if we run the script
> start-to-finish, I found out the hard way that when I worked at the CLI,
> the set +h had gone away from the scripts sometime in the past and I had
> not noticed.
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 ;-)
> And, should I start afresh and forget all that I *thought* I had
> accomplished? ARRRGGGGHHHH!
> I think I'll sleep on it.
> > With that in mind I cant comment really on which way to go here,
> > testing the proposed changes by bill and erik won't prove anything...
> Apparently, me testing anything I've proposed won't prove anything
I wouldn't say that... you've brought up some issues someone else will
eventually run into, just because I cant test it (my host is sooo non
standard, its a work of art built over the aeons from RH6.2) doesn't mean
it isn't a problem...
> Well, at least I didn't wipe out my partition (... yet?).
> > Thoughts on how to resolve this one? Who has the lowest specced host
> > (in terms of package version numbers)?
> Easiest solution is to tell me to take a vacation.
Nope, thats the easy way out...
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)
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
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
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
c) we have to take into account that not all people split up their /tmp
directories onto separate partitions (avoids fragging up normal
The CANDIDATE_TMP_DIRS export can do this but would have to be set by
user running the script.
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
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
Smells hackey to me, and might not be an option for some folk.
Anyway, discussion is open on this one, ideas people?
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