gronod/lfs
1
0
Fork 0
mirror of https://git.linuxfromscratch.org/lfs.git synced 2025-03-05 22:04:48 +00:00
Code Issues Packages Projects Releases Wiki Activity

Applied Alex\'s grammar patch

Browse Source 
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@2082 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Timothy Bauscher 2002-09-08 21:54:14 +00:00
parent cb33ea82fe
commit 44c2fd8fab
15 changed files with 201 additions and 177 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
appendixa/makedev-desc.xml
View File

@ -8,10 +8,11 @@
<sect3><title>Descriptions</title>
<sect4><title>MAKEDEV</title>
<para>MAKEDEV is a script that can help in creating the necessary static
device files that usually reside in the /dev directory. More
information on device nodes can be found in the Linux Kernel source tree
in <filename>Documentation/devices.txt</filename>.</para></sect4>
<para><filename>MAKEDEV</filename> is a script that creates the necessary
static device nodes usually residing in the
<filename class="directory">/dev</filename> directory.
Detailed information on device nodes can be found in the Linux kernel source
tree in <filename>Documentation/devices.txt</filename>.</para></sect4>
</sect3>

3
chapter01/changelog.xml
View File

@ -53,6 +53,9 @@
</itemizedlist>
</para></listitem>
<listitem><para>September 8th, 2002 [timothy]: Chapter 06: Applied Alex's
grammar changes patch.</para></listitem>
<listitem><para>September 7th, 2002 [timothy]: Chapter 06 - Gzip:
Added gzip-1.2.4b.patch.</para></listitem>

60
chapter06/aboutdebug.xml
View File

@ -2,49 +2,49 @@
<title>About debugging symbols</title>
<?dbhtml filename="aboutdebug.html" dir="chapter06"?>
<para>Most programs and libraries by default are compiled with debugging
symbols (gcc option -g).</para>
<para>Most programs and libraries are by default compiled with debugging
symbols included (with gcc option -g).</para>
<para>A program compiled with debugging symbols means a user can run a program
or library through a debugger and the debugger's output will be user
friendly. These debugging symbols also enlarge the program or library
significantly.</para>
<para>Before you start wondering whether these debugging symbols really make a
big difference, here are some statistics. Use them to draw your own
conclusion.</para>
<para>When debugging a program or library that was compiled with debugging
information included, the debugger can give you not only memory addresses
but also the names of the routines and variables.</para>
<para>But the inclusion of these debugging symbols enlarges a program or
library significantly. To get an idea of the amount of space these symbols
occupy, have a look at the following:</para>
<itemizedlist>
<listitem><para>A dynamic Bash binary
with debugging symbols: 1.2 MB</para></listitem>
<listitem><para>a bash binary
with debugging symbols: 1200 KB</para></listitem>
<listitem><para>A dynamic Bash binary
without debugging symbols: 478 KB</para></listitem>
<listitem><para>a bash binary
without debugging symbols: 480 KB</para></listitem>
<listitem><para>/lib and /usr/lib (glibc
and gcc files) with debugging symbols: 87 MB</para></listitem>
<listitem><para>glibc and gcc files (/lib and /usr/lib)
with debugging symbols: 87 MB</para></listitem>
<listitem><para>/lib and /usr/lib (glibc
and gcc files) without debugging symbols: 16 MB</para></listitem>
<listitem><para>glibc and gcc files
without debugging symbols: 16 MB</para></listitem>
</itemizedlist>
<para>Sizes vary depending on which compiler was used and which C library
version was used to link dynamic programs against, but results will be
similar if you compare programs with and without debugging symbols.</para>
<para>Sizes may vary a little, depending on which compiler was used and
which C library. But when comparing programs with and without debugging
symbols, the difference will generally be a factor between 2 and 5.</para>
<para>To remove debugging symbols from a binary (must be an a.out or ELF
binary) run <userinput>strip --strip-debug filename</userinput>. Wildcards
can be used to strip debugging symbols from multiple files (use something
like <userinput>strip --strip-debug $LFS/usr/bin/*</userinput>). Most
people will probably never use a debugger on software, so by removing
those symbols a lot of disk space can be regained.</para>
<para>As most people will probably never use a debugger on their system
software, a lot of disk space can be regained by removing these symbols .</para>
<para>To remove debugging symbols from a binary (which must be an a.out
or ELF binary), run <userinput>strip --strip-debug filename</userinput>.
Wildcards can be used to treat multiple files (use something like
<userinput>strip --strip-debug $LFS/static/bin/*</userinput>).</para>
<para>For your convenience, chapter 9 includes one simple command to strip
all debugging symbols from the programs and libraries on your system. You
might find additional information in the optimization hint which can be
found at <ulink url="&hints-root;optimization.txt"/>.</para>
all debugging symbols from all programs and libraries on your system.
Additional information on optimization you can find in the hint at
<ulink url="&hints-root;optimization.txt"/>.</para>
</sect1>

19
chapter06/changingowner.xml
View File

@ -2,15 +2,20 @@
<title>Changing ownership</title>
<?dbhtml filename="changingowner.html" dir="chapter06"?>
<para>Now we're in chroot, it is time to change the ownership of
the files and directories that were installed in chapter 5 to root.
Run the following command to do so:</para>
<para>The first thing we'll do, now that we're <emphasis>root</emphasis>,
is change the ownership of the files and directories installed in chapter 5
to root -- because when later we don't delete the
<filename class="directory">/static</filename> directory and start adding
new users, one of these users might end up owning the statically linked
programs, which is not a good idea.</para>
<para><screen><userinput>chown -R 0:0 /</userinput></screen></para>
<para>Run the following command to make root the owner of all the statically
linked programs:</para>
<para>This command changes the ownership of the root partition to
root. The command uses 0:0 instead of root:root, because the user name
"root" can't be resolved, as glibc is not installed yet.</para>
<para><screen><userinput>chown -R 0:0 /static</userinput></screen></para>
<para>The command uses "0:0" instead of "root:root", because there is no way
to resolve the name "root", as glibc hasn't been installed yet.</para>
</sect1>

4
chapter06/chapter06.xml
View File

@ -7,10 +7,10 @@
&c6-chroot;
&c6-changingowner;
&c6-creatingdirs;
&c6-pwdgroup;
&c6-mtablink;
&c6-mountproc;
&c6-mtablink;
&c6-createfiles;
&c6-pwdgroup;
&c6-makedev;
&c6-kernel;
&c6-manpages;

56
chapter06/chroot.xml
View File

@ -2,35 +2,41 @@
<title>Entering the chroot'ed environment</title>
<?dbhtml filename="chroot.html" dir="chapter06"?>
<para>It's time to enter our chroot'ed environment in order to install the
rest of the software we need. Before you can chroot you need to change to
the <emphasis>root</emphasis> user since only user
<emphasis>root</emphasis> can use the <userinput>chroot</userinput>
command.</para>
<para>It is time to enter the chroot'ed environment in order to begin installing
the packages we need. Before you can chroot, however, you need to become
<emphasis>root</emphasis>, since only <emphasis>root</emphasis>
can execute the <userinput>chroot</userinput> command.</para>
<para>Enter the following commands to enter the chroot'ed environment. From
this point on there's no need to use the $LFS variable anymore, because
everything a user does will be restricted to the LFS partition (since / is
actually /mnt/lfs, but the shell doesn't know that).</para>
<para>Become <emphasis>root</emphasis> and run the following command
to enter the chroot'ed environment:</para>
<para>&c6-chrootcmd;</para>
<para><screen><userinput>chroot $LFS /static/bin/env -i \
&nbsp;&nbsp;&nbsp;&nbsp;HOME=/root TERM=$TERM PS1='\u:\w\$ ' \
&nbsp;&nbsp;&nbsp;&nbsp;PATH=/bin:/usr/bin:/sbin:/usr/sbin:/static/bin \
&nbsp;&nbsp;&nbsp;&nbsp;/static/bin/bash --login</userinput></screen>
</para>
<para>The -i option will clear all environment variables for as long as you
are in the chroot'ed environment and only the HOME, TERM, PS1 and PATH
variables are set. The TERM=$TERM construction will set the TERM variable
inside chroot to the same value as outside chroot which is needed for
programs like vim and less to operate properly. If you need other variables
present, such as CFLAGS or CXXFLAGS, you need to set them again.</para>
<para>The <userinput>-i</userinput> option given to the
<userinput>env</userinput> command will clear all variables of the chroot'ed
environment. After that, only the HOME, TERM, PS1 and PATH variables are
set again. The TERM=$TERM construct will set the TERM variable inside chroot
to the same value as outside chroot; this variable is needed for programs
like vim and less to operate properly. If you need other variables present,
such as CFLAGS or CXXFLAGS, this is a good place to set them again.</para>
<para>Now that we are inside a chroot'ed environment, we can continue to
install all the basic system software. You have to make sure all the
following commands in this and following chapters are run from within the
chroot'ed environment. If you ever leave this environment for any reason
(when rebooting for example) you must remember to enter chroot and mount
$LFS/proc again (as will be discussed later) before continuing with the
book.</para>
<para>From this point on there's no need anymore to use the $LFS variable,
because everything you do will be restricted to the LFS file system -- since
what the shell thinks is <filename class="directory">/</filename> is actually
<filename class="directory">/mnt/lfs</filename>.</para>
<para>Note that the bash prompt will contain "I have no name!" This is
normal because Glibc hasn't been installed yet.</para>
<para>You have to make sure all the commands in the rest of this chapter and
in the following chapters are run from within the chroot'ed environment.
If you ever leave this environment for any reason (rebooting for example),
you must remember to again enter chroot and mount proc (discussed later)
before continuing with the installations.</para>
<para>Note that the bash prompt will say "I have no name!" This is
normal, as the Glibc package hasn't been installed yet.</para>
</sect1>

7
chapter06/chrootcmd.xml
View File

@ -1,4 +1,3 @@
<screen><userinput>chroot $LFS /static/bin/env -i HOME=/root TERM=$TERM \
&nbsp;&nbsp;&nbsp;&nbsp;PS1='\u:\w\$ ' \
&nbsp;&nbsp;&nbsp;&nbsp;PATH=/bin:/usr/bin:/sbin:/usr/sbin:/static/bin \
&nbsp;&nbsp;&nbsp;&nbsp;/static/bin/bash --login</userinput></screen>
[delete me]

9
chapter06/createfiles.xml
View File

@ -3,11 +3,12 @@
<?dbhtml filename="createfiles.html" dir="chapter06"?>
<para>Some programs hard-wire paths to programs which don't exist yet. In
order to satisfy these programs, we create the <filename>/bin/bash</filename>
and <filename>/bin/sh</filename> symlinks.</para>
order to satisfy these programs, we create the symbolic links
<filename>/bin/bash</filename> and <filename>/bin/sh</filename>, both
pointing to the static <filename>bash</filename> program.</para>
<para>Create the /bin/bash and /bin/sh symlinks by running the following
commands:</para>
<para>Create the <filename>/bin/bash</filename> and <filename>/bin/sh</filename>
symlinks by running the following commands:</para>
<para><screen><userinput>ln -s /static/bin/bash /bin/bash &amp;&amp;
ln -s bash /bin/sh</userinput></screen></para>

53
chapter06/creatingdirs.xml
View File

@ -2,10 +2,9 @@
<title>Creating directories</title>
<?dbhtml filename="creatingdirs.html" dir="chapter06"?>
<para>Let's now create the directory tree on the LFS partition based on
the FHS standard, which can be found at
<ulink url="http://www.pathname.com/fhs/"/>.
Issuing the following commands will create a default directory layout:</para>
<para>Let's now create some structure in our LFS file system, let's create
a directory tree. Issuing the following commands will create a more or less
standard tree:</para>
<para><screen><userinput>mkdir -p /{bin,boot,dev/pts,etc/opt,home,lib,mnt,proc} &amp;&amp;
mkdir -p /{root,sbin,tmp,usr/local,var,opt} &amp;&amp;
@ -23,35 +22,39 @@ mkdir /opt/{bin,doc,include,info} &amp;&amp;
mkdir -p /opt/{lib,man/man{1,2,3,4,5,6,7,8}} &amp;&amp;
ln -s ../var/tmp /usr</userinput></screen></para>
<para>Normally, directories are created with permission mode 755, which isn't
desired for all directories. The first change is a mode 0750 for the
/root directory. This is to make sure that not just everybody can
enter the /root directory (the same a user would do with his /home/username
directory). The second change is a mode 1777 for the tmp
directories. In this way any user can write to the /tmp and /var/tmp
directories, but cannot remove other users's files from them (the latter is prohibited
by the so-called "sticky bit" -- bit 1 in the 1777 bit mask).</para>
<para>Directories are by default created with permission mode 755, but this
isn't desirable for all directories. We will make two changes: one to the home
directory of root, and another to the directories for temporary files.</para>
<para><screen><userinput>chmod 0750 /root &amp;&amp;
chmod 1777 /tmp /var/tmp</userinput></screen></para>
<para>The first mode change ensures that not just everybody can enter the
<filename class="directory">/root</filename> directory -- the same
a normal user would do with his or her home directory.
The second mode change makes sure that any user can write to the
<filename class="directory">/tmp</filename> and
<filename class="directory">/var/tmp</filename> directories, but
cannot remove other users's files from them. The latter is prohibited
by the so-called "sticky bit" -- the highest bit in the 1777 bit mask.</para>
<para>Now that the directories are created, copy the source files that were
downloaded in chapter 3 to some subdirectory under /usr/src (you
will need to create the desired directory yourself).</para>
downloaded in chapter 3 to some subdirectory under
<filename class="directory">/usr/src</filename> (you
will have to create the desired subdirectory yourself).</para>
<sect2>
<title>FHS compliance notes</title>
<title>FHS compliance note</title>
<para>The FHS stipulates that the /usr/local directory should contain the
bin, games, include, lib, man, sbin, and share subdirectories. You can
alter your /usr/local directory yourself if you want your system to be
FHS-compliant.</para>
<para>Also, the standard says that there should exist a /usr/share/games
directory, which we don't much like for a base system. But feel free to
make your system FHS-compliant if you wish. The FHS isn't precise as
to the structure of the /usr/local/share subdirectories, so we took the
liberty of creating the directories that we felt were needed.</para>
<para>We have based our directory tree on the FHS standard (available at
<ulink url="http://www.pathname.com/fhs/"/>). Besides the above created
tree this standard stipulates the existence of
<filename class="directory">/usr/local/games</filename> and
<filename class="directory">/usr/share/games</filename>, but we don't
much like these for a base system. However, feel free to make your system
FHS-compliant. As to the structure of the
<filename class="directory">/usr/local/share</filename> subdirectory the FHS
isn't precise, so we created here the directories that we think are needed.</para>
</sect2>

44
chapter06/introduction.xml
View File

@ -7,29 +7,31 @@ constructing our LFS system in earnest. That is, we chroot into
our temporary mini Linux system, create some auxiliary things,
and then start installing all the packages, one by one.</para>
<para>The installation of all the software is pretty straightforward, and
you will probably think it would be so much easier and shorter to give
the generic installation instructions for a package here and only explain
in full the installation of those packages that require an alternate
method. Although we agree with that, we choose to give the
full instructions for each and every package, simply to avoid any
possible confusion and errors.</para>
<para>The installation of all this software is pretty straightforward,
and you will probably think it would be much shorter to give here
the generic installation instructions and explain in full only the
installation of those packages that require an alternate method.
Although we agree with that, we nevertheless choose to give the
full instructions for each and every package, simply to minimize
the possibilities for mistakes.</para>
<para>If you plan to use compiler optimization for the packages
installed in this chapter, take a look at the optimization hint
at <ulink url="&hints-root;optimization.txt"/>.
Compiler optimization can make a program run
faster, but may also cause compilation problems. If you run into problems
when using optimization, always try it without optimization to see if
the problem persists.</para>
<para>If you plan to use compiler optimizations in this chapter,
take a look at the optimization hint at
<ulink url="&hints-root;optimization.txt"/>.
Compiler optimizations can make a program run faster, but they
may also cause compilation difficulties. If a package refuses
to compile when using optimization, try to compile it without
optimization and see if the problem goes away.</para>
<para>Please refrain from installing more than one package at a time, even
if it may save you time (especially with dual CPU machines). If you install
the wrong package at the wrong time, it may hard-wire program paths to
<filename class="directory">$LFS/static</filename> which will cause the
programs to stop working once the static directory is removed. The order
packages are installed in this chapter have to be followed exactly to be
sure nothing is hard-wiring the static paths.</para>
<para>The order in which packages are installed in this chapter has
to be strictly followed, to ensure that no program gets a path referring
to <filename class="directory">/static</filename> hard-wired into it.
For the same reason, <emphasis>do not </emphasis> compile packages
in parallel. Compiling in parallel may save you some time (especially on
dual-CPU machines), but it could result in a program containing a
hard-wired path to <filename class="directory">/static</filename>,
which will cause the program to stop working when the static directory
is removed.</para>
</sect1>

11
chapter06/makedev-exp.xml
View File

@ -2,11 +2,12 @@
<title>Command explanations</title>
<para><userinput>./MAKEDEV -v generic:</userinput> This creates a whole
bunch of generic devices. Normally, these are all the devices you need. It's possible
that you are missing some special devices that are needed for your hardware
configuration. Create them with ./MAKEDEV -v &lt;device&gt;.
The <userinput>generic-nopty</userinput> option does a similar job, but skips
some devices which are not needed if you are using devpts.</para>
bunch of devices. Normally, these are all the devices you will need. But it
is possible that some special devices needed for your hardware configuration
are missing. Create these with ./MAKEDEV -v &lt;device&gt;.
The <userinput>generic-nopty</userinput> option mostly creates the same
devices as <userinput>generic-nopty</userinput>, but skips those that aren't
needed if you are using devpts.</para>
</sect2>

30
chapter06/makedev-inst.xml
View File

@ -1,33 +1,31 @@
<sect2>
<title>Creating devices</title>
<para>Note: the MAKEDEV-&makedev-version;.bz2 file you have unpacked is not
an archive, so it won't create a directory for you to cd into.</para>
<para>(Note that unpacking the MAKEDEV-&makedev-version;.bz2 file doesn't create
a directory for you to cd into, as the file only contains a script.)</para>
<para>Create the device files by running the following commands:</para>
<para>Prepare for the creation of the device files by running the
following commands:</para>
<para><screen><userinput>cp MAKEDEV-&makedev-version; /dev/MAKEDEV &amp;&amp;
cd /dev &amp;&amp;
chmod 754 MAKEDEV</userinput></screen></para>
<para>Now, depending on whether you are going to use devpts or not, you
can run one of two commands:</para>
<para>If you do not intend to use devpts, run:</para>
<para>Most people will now want to create devices by running:</para>
<para><screen><userinput>./MAKEDEV -v generic</userinput></screen></para>
<para>If you do intend to use devpts, then run:</para>
<para>But if you intend to use devpts, then run this instead:</para>
<para><screen><userinput>./MAKEDEV -v generic-nopty</userinput></screen></para>
<para>Note that if you aren't sure, it's best to use
the <userinput>./MAKEDEV -v generic</userinput> command as this will
ensure you have the devices you need. If you are sure you are going to
use devpts however, the other command makes sure that you don't create a
set of devices which you don't require.</para>
<para>Note that if you aren't sure, it's best to use the
<userinput>./MAKEDEV -v generic</userinput> command as this will ensure you
have all the devices you need. But if you are certain you are going to use
devpts, the other command skips creating a set of devices you won't need.</para>
<para>MAKEDEV will create hda[1-20] to hdh[1-20] and such, but keep in mind
that you may not be able to use all of these devices due to kernel
limits on the maximum number of partitions.</para>
<para><filename>MAKEDEV</filename> will create hda[1-20] to hdh[1-20] and
many more of such disk device nodes, but keep in mind that you probably won't
be able to use all of these, due to kernel limits on the maximum number of
partitions.</para>
</sect2>

15
chapter06/mountproc.xml
View File

@ -1,16 +1,17 @@
<sect1 id="ch06-proc">
<title>Mounting /proc file system</title>
<title>Mounting the proc file system</title>
<?dbhtml filename="proc.html" dir="chapter06"?>
<para>In order for certain programs to function properly, the proc file
system must be available from within the chroot'ed environment.
A file system can be mounted as many times and in as many places
as you'd like, so it's not a problem that the proc file system is already
mounted on your host system, especially so because proc is a
system must be available within the chroot'ed environment.
As a file system can be mounted as many times and in as many places
as you like, it's not a problem that the proc file system is already
mounted on your host system -- especially so because proc is a
virtual file system.</para>
<para>The proc file system is mounted under /proc by running the
following command.</para>
<para>The proc file system is mounted under
<filename class="directory">/proc</filename> by running the
following command:</para>
<para><screen><userinput>mount proc /proc -t proc</userinput></screen></para>

27
chapter06/mtablink.xml
View File

@ -1,24 +1,25 @@
<sect1 id="ch06-mtablink">
<title>Creating the /etc/mtab symlink</title>
<title>Creating the mtab symlink</title>
<?dbhtml filename="mtablink.html" dir="chapter06"?>
<para>The next thing to do is to create a symlink pointing from
/etc/mtab to /proc/mounts. This is done using the following
command:</para>
<filename>/etc/mtab</filename> to <filename>/proc/mounts</filename>.
This is done using the following command:</para>
<para><screen><userinput>ln -s /proc/mounts /etc/mtab</userinput></screen></para>
<para>Creating this symlink avoids problems which can occur if / is
mounted read-only and the information in /etc/mtab is stale (i.e. out of
date). By creating the symlink to /proc/mounts, we ensure that
/etc/mtab will always be up-to-date.</para>
<para>Creating this symlink avoids problems which can occur if
<filename class="directory">/</filename> is mounted read-only and the
information in <filename>/etc/mtab</filename> is stale (i.e. out of date).
By creating the symlink to <filename>/proc/mounts</filename>, we ensure that
the information on currently mounted devices is always up-to-date.</para>
<para>Note that using this symlink requires that you have /proc
filesystem support compiled into your kernel. This is included by
default and should not be removed unless you <emphasis>really</emphasis>
know what you are doing as many more things than just the /etc/mtab
symlink depend on /proc being present. In summary, make sure you have
/proc filesystem support in your kernel.</para>
<para>Note that using this symlink requires that you have support for the
proc filesystem compiled into your kernel. This support is included by
default, and should not be removed unless you <emphasis>really</emphasis>
know what you are doing, as some more things besides the
<filename>/etc/mtab</filename> symlink depend on proc being present.
In short, make sure you have proc filesystem support in your kernel.</para>
</sect1>

31
chapter06/pwdgroup.xml
View File

@ -1,25 +1,21 @@
<sect1 id="ch06-pwdgroup">
<title>Creating passwd and group files</title>
<title>Creating the passwd and group files</title>
<?dbhtml filename="pwdgroup.html" dir="chapter06"?>
<para>In order for the user and the group "root" to be recognized and to be
able to login, there need to be entries in the /etc/passwd and /etc/group file.
Besides the group "root", a couple of other groups are recommended or needed
by some packages. The groups created below aren't part of any standard.
The LSB only recommends a group "bin" with GID 1 to be present besides
"root". Other group names and GIDs can be chosen by the user.
Well-written packages don't depend on GID numbers, but use the group's
name; so it doesn't matter which GID a group has. Since there
aren't any standards for groups, the groups created here are the groups the
MAKEDEV script (the script that creates the device files in the /dev
directory) mentions.</para>
<para>In order for root to be able to login and for the name "root" to be
recognized, there need to be relevant entries in the
<filename>/etc/passwd</filename> and
<filename>/etc/group</filename> files.</para>
<para>Create a new file <filename>/etc/passwd</filename> by running the
<para>Create the <filename>/etc/passwd</filename> file by running the
following command:</para>
<para><screen><userinput>echo "root:x:0:0:root:/root:/bin/bash" &gt; /etc/passwd</userinput></screen></para>
<para>Create a new file <filename>/etc/group</filename> by running the
<para>The actual password for root (the "x" here is just a placeholder) will
be set later.</para>
<para>Create the <filename>/etc/group</filename> file by running the
following command:</para>
<para><screen><userinput>cat &gt; /etc/group &lt;&lt; "EOF"</userinput>
@ -37,5 +33,12 @@ dialout:x:10:
audio:x:11:
<userinput>EOF</userinput></screen></para>
<para>The created groups aren't part of any standard -- they are the groups
that the MAKEDEV script in the next section uses.
Besides the group "root", the LSB recommends only a group "bin" with a GID
of 1 to be present. All other group names and GIDs can be chosen freely by
the user, as well-written packages don't depend on GID numbers but use the
group's name.</para>
</sect1>