123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100 |
- <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>
- <blockquote><literallayout>
- <userinput>find / -type f -exec strip --strip-debug '{}' ';'
- </userinput>
- </literallayout></blockquote>
- <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>
- <blockquote><literallayout>
- <userinput>touch /etc/lfs-&version;</userinput>
- </literallayout></blockquote>
- <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>
- <blockquote><literallayout>
- <userinput>/sbin/lilo</userinput>
- </literallayout></blockquote>
- <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="http://archive.linuxfromscratch.org/lfs-hints/afterlfs.txt">
- http://archive.linuxfromscratch.org/lfs-hints/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="http://archive.linuxfromscratch.org/lfs-hints/newbie.txt">
- http://archive.linuxfromscratch.org/lfs-hints/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>
|