Revised chroot command in lfs-cvs

Neven Has haski at sezampro.yu
Sun Apr 27 11:56:40 PDT 2003

On Sat, Apr 26, 2003 at 12:29:52PM -0600, Gerard Beekmans wrote:
> On April 26, 2003 06:50 am, Neven Has wrote:
> > No, nothing is hardcoded, it's simply not used.  Only the root
> > directory is changed, using chroot(2).
> Maybe an idea to allow a tag to specify which command to run when going into 
> chroot? There's not much use for that probably, but every now and then I 
> enter chroot using 'strace /bin/bash' to see what's going on (it's a handy 
> debugging feature). It can be done of course by making $LFS/bin/sh a symlink 
> to strace, and call /bin/bash inside chroot then, but that's a lot of work. 
> It'd be simpler to specify this in the <stageinfo> block.

Yes, I agree.

However, this wouldn't be a "chroot's feature", as it's with chroot(3)
(so to speak).  It could be an element that will change the command
used when executing other commands (again, not directly related with
chroot, it would be possible to use it anytime).

In the case of chroot, something like:

<stage name="Chapter 6">


			<variable name="PATH">
			<variable name="HOME">


although I'm not sure about "shell" ?

> > So the right thing should happen, as /static/bin is not used in
> > revised chroot.  Haven't tried it myself yet though...
> So to make this work reliable, when Glibc is installed for the
> second time in Chapter 6 we should wrap the remaining profiles in a
> new stageinfo that doens't include /static/bin? We just don't want
> /static/bin to appear in the PATH (simply because it feels better).
> Here, let me demonstrate with some code (code means more than a
> thousand words afterall);
> Again there's not real technical reason for this since as long as
> /bin and /usr/bin appear in $PATH first, all is well (manually
> installing uses a chroot'ed shell which will fail if the old chroot
> command it used, but should not be an issue with nALFS).

Right, but I would agree it's ugly to rely on PATH this much, so that
<shell> (or whatever we name it) that you suggest does look like a
nice solution.


Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list