On 30 May 2010 17:45, Paul Rogers <[email protected]> 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 vulnerabilities. ĸen -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
