On 09/25/2011 10:44 PM, Ken Moffat wrote: [putolin]
> > I'm lost here (probably because it is late) - you've used the same > host to build LFS twice, first on the old disk, and then on the new > disk ? Yes that is correct. The scripts produced a LFS system that booted and worked on the old hard drive so I thought is was good. The only difference is an increase in size of the hard drive 120GB to a 500GB. >> I used the same host system and the same partition system on both hard >> drives. >> I also scripted the first system and copied it to a usb thumb drive to >> use again. >> After setting up the new drive I used the scripts following the build >> sequence to install on the newer/larger drive. >> I have to manually do each step following the book. I built the scripts >> by cutting and pasting each chapter into a script and adding a section >> to untarball the source package and cd to the now source directory >> Each script resides into a subdirectory. >> >> The script when run unpacks the tarball cd to the unpacked directoty >> and runs the pasted commands. > The above sounds sensible, but the reality is that scripting makes > it very easy to miss errors. OTOH, if you are manually running each > step, any errors ought to be apparent to you. Well that is why I scripted it. This old fart has a problem reading off the nook which has the LFS-6.8 pdf and typing the correct thing into the system under build. I use this at the top of the script #!/bin/bash -e set +h shopt -s -o pipefail pkgname=automake pkgver=1.11.1 startdir=$(pwd) then do the cut and paste line with |& tee "$startdir/build.log" at the end so I have a log of what happened so I can then lokk the result over and correct the "hey look dummy errors". >> What I don't know is when does the kernel hand over booting to inittab etc. >> >> My theory if not flawed is that some/all binaries are linked to the >> /tools directory, and since /tools has beened removed it hangs. >> Although I could be completely wrong about this. >> >> > It should be simple for you to test this theory - take a program > from each package (starting with /sbin/init) and use ldd to see what > it links to. If the program you picked turns out to be a shell > script, try a different program from the same package (see chapter > 6, I think, for what gets installed in each package ? - I don't have > a graphical browser on my current desktop). OK I'll do that after I get home from work today > If /sbin/init is linked to /tools, I would expect to see a > meaningful error message, but who knows. If /sbin/init is NOT > linked to /tools, then this appears to be a kernel config problem. > > If /bin/bash is linked correctly, you can also try booting with > init=/bin/bash, although it won't give you a nice environment and > is normally reserved for stepping through the init scripts if things > have broken. > -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
