My su is to chmod/chown the file I scp from the main computer to the lfs computer.
On Sun, Nov 1, 2015 at 6:31 PM, Ken Moffat <[email protected]> wrote: > On Sun, Nov 01, 2015 at 04:10:52PM -0500, Michael Havens wrote: > > Good afternoon. I am on section 5.33 . > > Here is what I enter into the computer: > > > > #scp [email protected]: > /home/bmike1/Documents/LFS/7.8/build/5.33build.txt > > $LFS/sources;exit > > #chmod 777 $LFS/sources/5.33build.txt; chown lfs > > $LFS/sources/5.33build.txt;su - lfs > > I've no idea whether this is relevant to your problem or not, but > why are you su'ing to lfs for each package [ if I have interpreted > you correctly ] ? > > We recommend building without scripts (and then booting, and going > back and fixing the kernel .config until it *does* successfully boot) > for the first build so that you can concentrate on what is in the > book without worrying about the ways in which your own script can > fail. On your first attempt last year, your machine died (been > there in a different context, so you have my sympathies) so this is > still your first build. > > And so, you become the lfs user, build some packages, perhaps log > off and shut down, and later return, become the lfs user again, and > build some more packages. Or, you leave the machine running but idle > (not tremendously clever if the machine is using a lot of power, but > it's how some of us started here). Or you build a bit and then let > the machine sleep (if your machine is set up for suspend to RAM or > even suspend to disk). > > We cannot guess at your background : some lfs builders seem to do it > as a required stage before working as a developer, and they therefore > start with a lot of knowledge (in particular, I remember one guy who > worked for an obscure manufacturer who, when I said I was trying to > build LFS on the product said "been there, done that."). We do not > usually hear from those people because for them everything in LFS > just works. You appear to not have much experience of building > software, and therefore you have a lot to learn. That in itself is > fine, but you are making the process harder for yourself by trying to > automate some of the build before you understand what is going on. > > After a *successful* build, developing your own scripts is good, and > worthwhile if you either want to stick with LFS and BLFS, or if you > wish to develop your scripting skills. But until you have done it > once, scripts are likely to get in your way. > > But anyway: > > #cd $sources;./5.33build.txt > > tar xf util-linux-2.27.tar.xz;cd util-linux-2.27 > > ./configure --prefix=/tools \ > > --without-python \ > > --disable-makeinstall-chown \ > > --without-systemdsystemunitdir \ > > PKG_CONFIG="" > > ( make 2>&1 | tee ../5.33.make.log && exit $PIPESTATUS ) && echo GOOD > > #make check > > ( make install 2>&1 | tee ../5.33.makeinstall.log && exit $PIPESTATUS ) > && > > echo GOOD > > #rm -rf util-linux-2.27 > > > > The lines with the hash mark are entered individually (except for make > > check. I do not enter that at all). > > The error I am getting in the makelog is: > > > > collect2: error: ld returned 1 exit status > > make[2]: *** [mount] Error 1 > > make[2]: Leaving directory `/mnt/lfs/sources/util-linux-2.27' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/mnt/lfs/sources/util-linux-2.27' > > make: *** [all] Error 2 > > > > the complete makelog is found: > > > > http://pastebin.com/GFtFP9Ng > > > > If you cannot read your own log (NB having a log is *good*) and > produce the error message associated with the error [ hint: it is > almost certainly in the few lines above the collect2 error you > showed ] then I'm not going to look at pastebin. If you find the > detailed error message, then either you will be able to see what > went wrong, or else you will still need to ask for help, but you > will save the list from wasting time reading a log. > > > The makeinstall log error is similar: > > > > Duh ? If *any* step in LFS fails, *STOP*. Attempting to install a > package where the build has failed will normally begin by attempting > to complete the build, and we know that will fail. > > In case it is not obvious (and apparently, it isn't), configure > produces a Makefile (or a series of Makefiles in the top directory > and some subdirectories) which ought to build on the current system > with any options you specified. 'make' then builds the various > targets (programs, libraries, documentation, whatever). 'make > install' then attempts to install the targets - if they do not exist > (in this case, because the build failed), it will try to build them > so that it can install them. > > And, as before, repeating the same instructions after a failure is > unlikely to work [ occasionally, it does - either there is a race in > the Makefile and make -jN tries to build something before its > dependencies have been created, or the machine is flakey - e.g. at > least some AMD phenoms, one of which is mine : in those cases, a > fallback of 'make' instead of 'make -jN' usually works ]. > > ĸen > -- > Il Porcupino Nil Sodomy Est! (if you will excuse my latatian) > aka "The hedgehog song" > -- > http://lists.linuxfromscratch.org/listinfo/lfs-support > FAQ: http://www.linuxfromscratch.org/blfs/faq.html > Unsubscribe: See the above information page > > Do not top post on this list. > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > http://en.wikipedia.org/wiki/Posting_style > -- :-)~MIKE~(-:
-- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
