LFS-6.6, Stage2, glibc, nscd.c:442

Ken Moffat zarniwhoop73 at googlemail.com
Sun May 30 16:36:23 PDT 2010

On 30 May 2010 17:45, Paul Rogers <paulgrogers at fastmail.fm> wrote:

> Yes, it does, and I could go from my current 6.1 to 6.3 by installing
> the LiveCD.  Except that also brings along X & xfce, et al.  The way I
> go, cloning with the setup, restore, finish steps, I get a system that's
> the equivalent of going through the book, replacing the compiling with
> the VERY much faster restoring the compiled code from a tarball made
> immediately after compiling.  My clone script lets me stop there and
> have a book-version, Spartan, Linux, before adding my choices from BLFS.
> And even when I add those, at those points when it is necessary to
> customize something, e.g. fstab, my finish steps ask for the necessary
> information.  As opposed to just tarballing my finished build, as jhalfs
> would produce, the installer doesn't have to find every such file and
> change it.  IMO, it's simpler, and more like doing a book-install,
> cloning new systems my way.
 What you are overlooking is that "doing it my way" comes with "when it
breaks, I get to keep all the pieces".  I too use my own scripts, and from
time to time I've been a long way from current LFS (variously working
on BLFS using an old version, or using clfs when x86_64 was not in LFS,
or doing other things), and sometimes I've been tearing my hair out.

 However, in my case I've always used a *fairly-recent* toolchain to build
new systems, and in general I build the "target" kernel and then use
something like '--enable-kernel=current' in glibc because I want to have
some confidence that the kernel version and .config will work for me
*before* I build a new system (take it from me, trying to work out what
broke if the new system fails to boot *and* uses a newer kernel is  *not*
a problem anyone wants).

 In general, building from the previous release (or newer) is usually tested
by the time we have a release, because that's what editors and other
people using the development book are typically using.  Using the release
before the previous release might work, particularly if you have updated
the kernel version since you built it.  The 6.3 release (on i686) probably
works because a lot of people still use the Live CD.  For anything else,
you're on your own.

 But as to what versions are *required*, we have no data!

 I'm also worried by your phrase "Except that also brings along X & xfce,
et al." - those are outside the host system, do you think that building
from an xterm somehow leads to a different result than building from a
tty ?  If that is indeed the case, you are probably better building under
xorg, because that is the more common case.

  I am dubious about your old version of gcc (because it has difficulties
correctly compiling a current kernel on x86 - see comments on lkml in
the past week ) but your biggest difference from a "sane host" has to be
your kernel version.  If you can update to latest 2.6.27 (which still has a
long-term-stable version), you might be in with a chance - if that
doesn't help, your old version of gcc is  almost certainly the problem.

 Let's look at this another way - most people who try the development
book are either using a very-recent LFS, or a recent distro (recent kernel,
recent toolchain).  After it becomes a release, we might get a few users
with slightly older LFS hosts.  If you have unusual problems, and you are
following the correct procedures, the most likely cause is that your host
system is inadequate.

 By the way, you _do_ need to remove toolchain source directories after
each stage.  Something you wrote made me question whether you had
been doing that throughout your build.

 I wish you good luck, but if you can build from a Live CD, that appears
to be a more productive use of your time than identifying exactly *what*
needs to be upgraded beyond the minimum requirements listed in the
book.  Of course, definitive information that a particular version of a
package is now needed is good for the book, but ascertaining the exact
version will usually be painful (plus, I doubt we would revise a release for
that information).

 I'm also slightly worried by the implication in your post that "any random
version of what is in BLFS will do".  Maybe you didn't mean that, but *many*
packages have vulnerabilities which become known.  Not all of these
matter to everyone (e.g. some are only for systems with more than one live
user), but BLFS is unfortunately not at the cutting edge of tracking


More information about the lfs-support mailing list