1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071 |
- <sect1 id="ch09-theend">
- <title>The End</title>
- <para>Well done! You have finished installing your LFS system. It may have
- been a long process but it was well worth it. We wish you a lot of fun
- with your new shiny custom built Linux system.</para>
- <para>Now would be a good time to strip all debug symbols from
- the binaries on your LFS system. If you are not a programmer and don't plan
- on debugging your software, then you will be happy to know that you can
- reclaim a few tens of megs by removing debug symbols. This process causes
- no inconvenience other than not being able to debug the software fully
- anymore, which is not an issue if you don't know how to debug. You can
- remove the symbols by executing the following command:</para>
- <para>Disclaimer: 98% of the people who use the command mentioned below don't
- experience any problems. But do make a backup of your LFS system before
- you run this command. There's a slight chance it may backfire on you and
- render your system unusable (mostly by destroying your kernel modules
- and dynamic & shared libraries).</para>
- <para>Having that said, the --strip-debug option to strip is quite harmless
- under normal circumstances. It doesn't strip anything vital from the
- files. It also is quite safe to use --strip-all on regular programs
- (don't use that on libraries - they will be destroyed) but it's not as
- safe and the space you gain is not all that much. But if you're tight on
- disk space every little bit helps, so decide yourself. Please refer to
- the strip man page for other strip options you can use. The general idea
- is to not run strip on libraries (other than --strip-debug) just to be
- on the safe side.</para>
- <para><screen><userinput>find / -type f -exec strip --strip-debug '{}' ';'</userinput></screen></para>
- <para>If you plan to ever upgrade to a newer LFS version in the future it
- will be a good idea to create the /etc/lfs-&version; file. By having
- this file it is very easy for you (and for us if you are going to ask
- for help with something at some point) to find out which LFS version
- you have installed on your system. This can just be a null-byte file by
- running:</para>
- <para><screen><userinput>touch /etc/lfs-&version;</userinput></screen></para>
- <para>One final thing you may want to do is run lilo now that you are booted
- into LFS. This way you will put the LFS version of LILO in the MBR
- rather than the one that's there right now from your host system.
- Depending on how old your host distribution is, the LFS version may have
- more advanced features you need/could use.</para>
- <para>Either way, run the following to make the lilo version installed on LFS
- active:</para>
- <para><screen><userinput>/sbin/lilo</userinput></screen></para>
- <para>If you are wondering: "Well, where to go now?" you'll be glad to hear that
- someone has written an LFS hint on the subject at <ulink
- url="&hint-root;afterlfs.txt">&hint-root;afterlfs.txt</ulink>.
- On a same note, if you are not only newbie to LFS, but also
- newbie to Linux in general, you may find the newbie hint at <ulink
- url="&hint-root;newbie.txt">&hint-root;newbie.txt</ulink>
- very interesting.</para>
- <para>Don't forget there are several LFS mailinglists you can subscribe to if
- you are in need of help, advice, etc. See
- <ulink url="ch01-maillists.html">Chapter 1 - Mailinglists</ulink> for
- more information.</para>
- <para>Again, we thank you for using the LFS Book and hope you found this book
- useful and worth your time.</para>
- </sect1>
|