1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
<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 <ulink
url="http://archive.linuxfromscratch.org/lfs-hints/Afterlfs.txt">LFS-Hint</ulink>
on that subject. On a same note, if you are not only newbie to LFS, but also
newbie to Linux in general, you may find the <ulink
url="http://archive.linuxfromscratch.org/lfs-hints/newbie.txt">newbie
hint</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>
|
