So I'm trying to build LFS 12.1 and recently ran into an issue where I must have messed up an install on Chapter 6. Initially when I was in the chroot shell I kept getting command not found for 'sed'. I must have messed up this install or accidentally skipped it. I only resolved this by reverting to a snapshot I had before this. Now that is resolved, I am currently on 8.5.1. Installation of Glibc and getting the same thing with the 'patch' command running 'patch -Np1 -i ../glibc-2.39-fhs-1.patch'. I resolved this by manually installing patch within the chroot shell. What is the proper way to reinstall this if it happens again and then reload the shell so it picks up the new installation? I am somewhat new to LFS but not sure how to go about properly resolving this.

Complicated fixes like manual installs out of sequence may work in the short term but you invariably run into the sand further down the line. I don't think there is any future in this particular build. In your place, I would clear the partition, except for /sources, and start again from Chapter 5.

Don't be downhearted; we've all had to do that sometimes and it's especially common on a first LFS build.

Initially when I was in the chroot shell I kept getting command not found for 'sed'.

-------------------------
need more information. but sed(1) is either not in PATH= or not installed in the chroot OR ..

glibc is "dorked" and fails to do library loading in which case bash tells you incorrectly "it wasn't found" when actually it was but wasn't loaded. now library loaded is part of binutils but also part of libc. so that's a little complicated

now, if your files seem to be all there? try checking existence of files and symlinks in /lib /usr/lib and run "ldconfig"

sometimes you can run ldconfig even if things can't be found (strange huh?)

HERE'S WHAT YOU CAN'T DO: install new libc without logging out of chroot and expect nothing will go wrong. you'll still be running libraries from old chroot after you alter it and invoking new libc with a different LD. ouch.

in "Totally Built Linux" http://totally-built-linux-distro.s3...com/index.html (smaller than LFS not updated as much but supposedly 100% build automated), libc and ld updates are done with root not running inside chroot. also old ldconfig .cache are deleted before first login attempt. /etc/ of course must be correct

actually i forget what TBL has to do with it, but anyway - i'm saying probably there are some things you were told to do earlier in book, not repeated, that are more important than you think and you forgot to do those things. that's only my guess.

in TBL the were many fixable probles causing "sed(1) not found" (now automated). the MOST FREQUENT ONE was a failed update of libc usually from a failed build (warnings in build can be fatal - just because libc builds doesn't mean it will work - you have to use all the right build options some are non-optional). either corrupted libc or lack of installation (say, symlinks in /lib not complete or pointing wrong) was, simple things aside, the problem.

this can also be binutils mismatch - since binutils gcc libc are intertwined to some effect (LD, the symbol loader) (the effect is libc will build 'ok' but with wrong version of binutils the result never works and chroot fails). but for LFS that should never occur since your building from a known good versions list of versions that match i assume.

i forgot to comment. you said "sed(1) not found" but your post says bash not found. i answered as if bash and everything (possibly excluding ld) was not found. (ld is not loaded by ld so that's different)

however! if your running make(2) (3.80 v. 3.82 or what), sometimes grep and sed aren't found. this can be due to improper compile environment. the reason this can happen is: "make has no bash environment inheritance" (stated in the GNU manual proper). this means any hack Makefile which relies on "POSIXLY_CORRECT" being off might not find sed(1) when it's on, for example sed quits says "non-posix option" and guess what that may not stop the build or given an error. there are other environment things that can cause it and you don't get a "missing sed" message is more likely

anyway - makefiles made quickly by hand tend to need "allot of regularity perhaps even likeness of the linux OS they came from" when they aren't written by "old school wizards" who know better than to ask make to inherit bash environment (and who know to write script that is posix not to use non-posix options - not to use python where awk or C will work fine, and so on)

often if your having this "awk sed sometimes quit" problem you may not even know (since makefile are so difficult to debug). you will get make parts of build skipped or wrong answers and not even know it happened

NEVER TAKE GOING OUT OF SEQUENCE NOT SERIOUSLY. while yes some things can be done out of order when you do that you may effect library slots (the old slots are changed because compiling was out of order, and what comes next will not work or even worse seem to work and fail much later). so even though you didn't change any version numbers the results can silently be much different.

i've rebuilt a whole OS due to a single option change needing a single library to rebuild: more than once. depends where in the build chain it is.