Building without chroot'ing

J_Man jutley3 at
Wed Jan 1 00:59:27 PST 2003

On Wed, 01 Jan 2003 02:18:53 +0000, Eric Miller wrote:

> My apologies if this has been addressed in the past (I think it has, but the
> search engine is down for the LFS list archive).
> It is my understanding that in the LFS build process, we chroot:
> - To ensure the finished system is built by a known quantity, e.g. the tools
> installed in Ch5 that become the static environment.
> - To protect the host system.
> However, when building from a CD LFS host, can we not skip Ch5 and get
> directly to the LFS proper in CH6?  The packages are the same as what we build
> in Ch5, and there is no danger of damaging the host (read only).
> If so, are there any precautions needed to be taken (permissions, chmods,
> chowns) before beginning?  I am still newb enough to be paranoid that I could
> build the whole system, and then not be able to use it becuase of a stupid
> permission or ownership problem.  I beleive I can modify the LFS book commands
> to fit this scenario, but I want to make sure it will work before spend any
> time on it.

I'm honestly surprised noone's responded to this one yet.  That is part of
the reason for the chroot.  However, there is more to it than just that. 
The other part is, many packages will hard code paths into their binaries
according to the --prefix they are compiled with.  So, for example, say we
compile bash with --prefix=/mnt/lfs.  When we try to boot into the new
LFS, then bash will be looking for it's /etc/profile as
/mnt/lfs/etc/profile, which, of course, won't exist on the new LFS system.
This is another reason for the use of the static builds and the chroot -
the static builds are to give enough of a development base to start
compiling things, once $LFS becomes our root, and the new things that are
compiled in Chap 6 have the correct paths in the binaries.

However, this is NOT to say that once your static builds aren't complete,
you can't preserve them as a tarball for later use - many of us actually
do do that.

Hope this explanation was clear enough - it's not 100% accurate, because I
don't think Bash itself would do what I am suggesting, but many other
packages would suffer from this type of situation.

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

More information about the lfs-support mailing list