diff options
Diffstat (limited to 'chapter07')
| -rw-r--r-- | chapter07/bootscripts.xml | 207 | ||||
| -rw-r--r-- | chapter07/console.xml | 81 | ||||
| -rw-r--r-- | chapter07/hostname.xml | 12 | ||||
| -rw-r--r-- | chapter07/hosts.xml | 45 | ||||
| -rw-r--r-- | chapter07/inputrc.xml | 41 | ||||
| -rw-r--r-- | chapter07/introduction.xml | 17 | ||||
| -rw-r--r-- | chapter07/network.xml | 79 | ||||
| -rw-r--r-- | chapter07/profile.xml | 83 | ||||
| -rw-r--r-- | chapter07/setclock.xml | 35 | ||||
| -rw-r--r-- | chapter07/udev.xml | 229 | ||||
| -rw-r--r-- | chapter07/usage.xml | 107 |
11 files changed, 917 insertions, 19 deletions
diff --git a/chapter07/bootscripts.xml b/chapter07/bootscripts.xml index 171330018..71d3a353f 100644 --- a/chapter07/bootscripts.xml +++ b/chapter07/bootscripts.xml @@ -3,13 +3,14 @@ <!ENTITY % general-entities SYSTEM "../general.ent"> %general-entities; ]> -<sect1 id="ch-scripts-bootscripts" xreflabel="Bootscripts" role="wrap"> +<sect1 id="ch-scripts-bootscripts" role="wrap"> <title>LFS-Bootscripts-&lfs-bootscripts-version;</title> <?dbhtml filename="bootscripts.html"?> <indexterm zone="ch-scripts-bootscripts"><primary sortas="a-Bootscripts">Bootscripts</primary></indexterm> <sect2 role="package"><title/> +<para>The LFS-Bootscripts package contains a set of bootscripts.</para> <segmentedlist> <segtitle>&buildtime;</segtitle> @@ -17,22 +18,220 @@ <seglistitem><seg>0.1 SBU</seg><seg>0.3 MB</seg></seglistitem> </segmentedlist> +<segmentedlist> +<segtitle>LFS-Bootscripts installation depends on</segtitle> +<seglistitem><seg>Bash and Coreutils</seg></seglistitem> +</segmentedlist> </sect2> <sect2 role="installation"> <title>Installation of LFS-Bootscripts</title> -<para>Installation of the bootscripts is very simple:</para> +<para>Install the package:</para> <screen><userinput>make install</userinput></screen> </sect2> - <sect2 id="contents-bootscripts" role="content"><title>Contents of LFS-bootscripts</title> -<para>See testing</para> +<segmentedlist> +<segtitle>Installed scripts</segtitle> +<seglistitem><seg>checkfs, cleanfs, console, functions, halt, ifdown, ifup, +localnet, mountfs, mountkernfs, network, rc, reboot, sendsignals, setclock, static, +swap, sysklogd, template, and udev</seg></seglistitem> +</segmentedlist> + +<variablelist><bridgehead renderas="sect3">Short Descriptions</bridgehead> +<?dbfo list-presentation="list"?> + +<varlistentry id="checkfs-bootscripts"> +<term><command>checkfs</command></term> +<listitem> +<para>Checks the file systems before they are mounted (with the exception of journal +and network based file systems)</para> +<indexterm zone="ch-scripts-bootscripts checkfs-bootscripts"><primary sortas="d-checkfs">checkfs</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="cleanfs-bootscripts"> +<term><command>cleanfs</command></term> +<listitem> +<para>Removes files that should not be +preserved between reboots, such as those in <filename class="directory">/var/run/</filename> and +<filename class="directory">/var/lock/</filename>; it re-creates <filename>/var/run/utmp</filename> +and removes the possibly present <filename>/etc/nologin</filename>, +<filename>/fastboot</filename>, and <filename>/forcefsck</filename> files</para> +<indexterm zone="ch-scripts-bootscripts cleanfs-bootscripts"><primary sortas="d-cleanfs">cleanfs</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="console-bootscripts"> +<term><command>console</command></term> +<listitem> +<para>Loads the keymap table specified as proper for the keyboard +layout; it also sets the screen font</para> +<indexterm zone="ch-scripts-bootscripts console-bootscripts"><primary sortas="d-console">console</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="functions-bootscripts"> +<term><command>functions</command></term> +<listitem> +<para>Contains functions shared among different scripts, such as error +and status checking</para> +<indexterm zone="ch-scripts-bootscripts functions-bootscripts"><primary sortas="d-functions">functions</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="halt-bootscripts"> +<term><command>halt</command></term> +<listitem> +<para>Halts the system</para> +<indexterm zone="ch-scripts-bootscripts halt-bootscripts"><primary sortas="d-halt">halt</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="hotplug-bootscripts"> +<term><command>hotplug</command></term> +<listitem> +<para>Load modules for system devices</para> +<indexterm zone="ch-scripts-bootscripts hotplug-bootscripts"><primary sortas="d-hotplug">hotplug</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="ifdown-bootscripts"> +<term><command>ifdown</command></term> +<listitem> +<para>Assists the network script with network devices</para> +<indexterm zone="ch-scripts-bootscripts ifdown-bootscripts"><primary sortas="d-ifdown">ifdown</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="ifup-bootscripts"> +<term><command>ifup</command></term> +<listitem> +<para>Assists the network script with network devices</para> +<indexterm zone="ch-scripts-bootscripts ifup-bootscripts"><primary sortas="d-ifup">ifup</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="localnet-bootscripts"> +<term><command>localnet</command></term> +<listitem> +<para>Sets up the system's hostname and local loopback device</para> +<indexterm zone="ch-scripts-bootscripts localnet-bootscripts"><primary sortas="d-localnet">localnet</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="mountfs-bootscripts"> +<term><command>mountfs</command></term> +<listitem> +<para>Mounts all file systems, except ones that are marked +<emphasis>noauto</emphasis> or are network based</para> +<indexterm zone="ch-scripts-bootscripts mountfs-bootscripts"><primary sortas="d-mountfs">mountfs</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="mountkernfs-bootscripts"> +<term><command>mountkernfs</command></term> +<listitem> +<para>Is used to mount kernel-provided file systems, such as +<systemitem class="filesystem">proc</systemitem></para> +<indexterm zone="ch-scripts-bootscripts mountkernfs-bootscripts"><primary sortas="d-mountkernfs">mountkernfs</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="network-bootscripts"> +<term><command>network</command></term> +<listitem> +<para>Sets up network interfaces, such as network cards, and sets up +the default gateway (where applicable)</para> +<indexterm zone="ch-scripts-bootscripts network-bootscripts"><primary sortas="d-network">network</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="rc-bootscripts"> +<term><command>rc</command></term> +<listitem> +<para>The master run-level control script; it is responsible for +running all other scripts one-by-one, in a sequence determined by +the name of the symbolic links being processed</para> +<indexterm zone="ch-scripts-bootscripts rc-bootscripts"><primary sortas="d-rc">rc</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="reboot-bootscripts"> +<term><command>reboot</command></term> +<listitem> +<para>Reboots the system</para> +<indexterm zone="ch-scripts-bootscripts reboot-bootscripts"><primary sortas="d-reboot">reboot</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="sendsignals-bootscripts"> +<term><command>sendsignals</command></term> +<listitem> +<para>Makes sure every process is terminated before the system reboots +or halts</para> +<indexterm zone="ch-scripts-bootscripts sendsignals-bootscripts"><primary sortas="d-sendsignals">sendsignals</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="setclock-bootscripts"> +<term><command>setclock</command></term> +<listitem> +<para>Resets the kernel clock to local time in case the hardware clock +is not set to UTC time</para> +<indexterm zone="ch-scripts-bootscripts setclock-bootscripts"><primary sortas="d-setclock">setclock</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="static-bootscripts"> +<term><command>static</command></term> +<listitem> +<para>Provides the functionality needed to assign a static Internet +Protocol (IP) address to a network interface</para> +<indexterm zone="ch-scripts-bootscripts static-bootscripts"><primary sortas="d-static">static</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="swap-bootscripts"> +<term><command>swap</command></term> +<listitem> +<para>Enables and disables swap files and partitions</para> +<indexterm zone="ch-scripts-bootscripts swap-bootscripts"><primary sortas="d-swap">swap</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="syslog-ng-bootscripts"> +<term><command>syslog-ng</command></term> +<listitem> +<para>Starts and stops the system and kernel log daemons</para> +<indexterm zone="ch-scripts-bootscripts syslog-ng-bootscripts"><primary sortas="d-syslog-ng">syslog-ng</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="template-bootscripts"> +<term><command>template</command></term> +<listitem> +<para>A template to create custom bootscripts for other +daemons</para> +<indexterm zone="ch-scripts-bootscripts template-bootscripts"><primary sortas="d-template">template</primary></indexterm> +</listitem> +</varlistentry> + +<varlistentry id="udev-bootscripts"> +<term><command>udev</command></term> +<listitem> +<para>Sets up udev and create the devices nodes in <filename +class="directory">/dev</filename></para> +<indexterm zone="ch-scripts-bootscripts udev-bootscripts"><primary sortas="d-udev">udev</primary></indexterm> +</listitem> +</varlistentry> +</variablelist> </sect2> </sect1> + diff --git a/chapter07/console.xml b/chapter07/console.xml index 3e5bfdc22..8e59c4bc9 100644 --- a/chapter07/console.xml +++ b/chapter07/console.xml @@ -7,15 +7,66 @@ <title>Configuring the Linux Console</title> <?dbhtml filename="console.html"?> -<para>Create the configuration file:</para> +<indexterm zone="ch-scripts-console"> +<primary sortas="d-console">console</primary> +<secondary>configuring</secondary></indexterm> + +<para>This section discusses how to configure the +<command>console</command> initscript that sets up the keyboard map +and the console font. If non-ASCII characters (British pound and Euro +character are examples of non-ASCII characters) will not be used and +the keyboard is a U.S. one, skip this section. Without the +configuration file, the console initscript will do nothing.</para> + +<para>The <command>console</command> script uses the +<filename>/etc/sysconfig/console</filename> as a configuration file. +Decide which keymap and screen font will be used. The +language-specific HOWTO can help with this. A pre-made +<filename>/etc/sysconfig/console</filename> file with known settings +for several countries was installed with the LFS-Bootscripts package, +so the relevant section can be uncommented if the country is +supported. If still in doubt, look in the <filename +class="directory">/usr/share/kbd</filename> directory for valid +keymaps and screen fonts. Read the loadkeys and setfont manual pages +and determine the correct arguments for these programs. Once decided, +create the configuration file with the following command:</para> <screen><userinput>cat >/etc/sysconfig/console <<"EOF" <literal>KEYMAP="<replaceable>[arguments for loadkeys]</replaceable>" FONT="<replaceable>[arguments for setfont]</replaceable>"</literal> EOF</userinput></screen> -<para>If you see that keycode 14 is Backspace and not Delete, -create the following keymap snippet to fix this issue:</para> +<para>For example, for Spanish users who also want to use the Euro +character (accessible by pressing AltGr+E), the following settings are +correct:</para> + +<screen><userinput>cat >/etc/sysconfig/console <<"EOF" +<literal>KEYMAP="es euro2" +FONT="lat9-16 -u iso01"</literal> +EOF</userinput></screen> + +<note><para>The <envar>FONT</envar> line above is correct only for the ISO 8859-15 +character set. If using ISO 8859-1 and, therefore, a pound sign +instead of Euro, the correct <envar>FONT</envar> line would be:</para> + +<screen><userinput>FONT="lat1-16"</userinput></screen></note> + +<para>If the <envar>KEYMAP</envar> or <envar>FONT</envar> variable is not set, the +<command>console</command> initscript will not run the corresponding +program.</para> + +<para>In some keymaps, the Backspace and Delete keys send characters +different from ones in the default keymap built into the kernel. This +confuses some applications. For example, +<application>Emacs</application> displays its help (instead of erasing +the character before the cursor) when Backspace is pressed. To check +if the keymap in use is effected (this works only for i386 +keymaps):</para> + +<screen><userinput>zgrep '\W14\W' <replaceable>[/path/to/your/keymap]</replaceable></userinput></screen> + +<para>If the keycode 14 is Backspace instead of Delete, create the +following keymap snippet to fix this issue:</para> <screen><userinput>mkdir -p /etc/kbd && cat > /etc/kbd/bs-sends-del <<"EOF" <literal> keycode 14 = Delete Delete Delete Delete @@ -27,12 +78,32 @@ create the following keymap snippet to fix this issue:</para> altgr control alt keycode 111 = Boot</literal> EOF</userinput></screen> -<para>Then tell the <command>console</command> script to load this snippet -after the main keymap:</para> +<para>Tell the <command>console</command> script to load this +snippet after the main keymap:</para> <screen><userinput>cat >>/etc/sysconfig/console <<"EOF" <literal>KEYMAP_CORRECTION="/etc/kbd/bs-sends-del"</literal> EOF</userinput></screen> +<para>To compile the keymap directly into the kernel instead of +setting it every time from the <command>console</command> bootscript, +follow the instructions given in <xref linkend="ch-bootable-kernel" role="."/> +Doing this ensures that the keyboard will always work as expected, +even when booting into maintenance mode (by passing +<parameter>init=/bin/sh</parameter> to the kernel), because the +<command>console</command> bootscript will not be run in that +situation. Additionally, the kernel will not set the screen font +automatically. This should not pose many problems because ASCII characters +will be handled correctly, and it is unlikely that a user would need +to rely on non-ASCII characters while in maintenance mode.</para> + +<para>Since the kernel will set up the keymap, it is possible to omit +the <envar>KEYMAP</envar> variable from the +<filename>/etc/sysconfig/console</filename> configuration file. It can +also be left in place, if desired, without consequence. Keeping it +could be beneficial if running several different kernels where it is +difficult to ensure that the keymap is compiled into every one of +them.</para> + </sect1> diff --git a/chapter07/hostname.xml b/chapter07/hostname.xml index 5b299f335..46c083a43 100644 --- a/chapter07/hostname.xml +++ b/chapter07/hostname.xml @@ -7,10 +7,22 @@ <title>Configuring the localnet Script</title> <?dbhtml filename="hostname.html"?> +<indexterm zone="ch-scripts-hostname"> +<primary sortas="d-localnet">localnet</primary> +<secondary>configuring</secondary></indexterm> + +<para>Part of the localnet script is setting up the system's hostname. This +needs to be configured in the <filename>/etc/sysconfig/network</filename>.</para> <para>Create the <filename>/etc/sysconfig/network</filename> file and enter a hostname by running:</para> <screen><userinput>echo "HOSTNAME=<replaceable>[lfs]</replaceable>" > /etc/sysconfig/network</userinput></screen> +<para><replaceable>[lfs]</replaceable> needs to be replaced with the +name the computer is to be called. Do not enter the Fully Qualified +Domain Name (FQDN) here. That information will be put in the +<filename>/etc/hosts</filename> file later.</para> + </sect1> + diff --git a/chapter07/hosts.xml b/chapter07/hosts.xml index bc81d39e8..b2a77c0c0 100644 --- a/chapter07/hosts.xml +++ b/chapter07/hosts.xml @@ -7,8 +7,42 @@ <title>Creating the /etc/hosts File</title> <?dbhtml filename="hosts.html"?> -<para>If a network card is to be configured, create the -<filename>/etc/hosts</filename> file by running:</para> +<indexterm zone="ch-scripts-hosts"><primary sortas="e-/etc/hosts">/etc/hosts</primary></indexterm> + +<indexterm zone="ch-scripts-hosts"> +<primary sortas="d-localnet">localnet</primary> +<secondary>/etc/hosts</secondary></indexterm> + +<indexterm zone="ch-scripts-hosts"> +<primary sortas="d-network">network</primary> +<secondary>/etc/hosts</secondary></indexterm> + +<para>If a network card is to be configured, decide on the IP-address, +FQDN, and possible aliases for use in the +<filename>/etc/hosts</filename> file. The syntax is:</para> + +<screen><IP address> myhost.example.org aliases</screen> + +<para>Unless the computer is to be visible to the Internet (e.g., +there is a registered domain and a valid block of assigned IP +addresses—most users do not have this), make sure that the IP +address is in the private network IP address range. Valid ranges +are:</para> + +<screen> Class Networks + A 10.0.0.0 + B 172.16.0.0 through 172.31.0.0 + C 192.168.0.0 through 192.168.255.0</screen> + +<para>A valid IP address could be 192.168.1.1. A valid FQDN for this +IP could be www.linuxfromscratch.org (not recommended because this is +a valid registered domain address and could cause domain name server +issues).</para> + +<para>Even if not using a network card, an FQDN is still required. +This is necessary for certain programs to operate correctly.</para> + +<para>Create the <filename>/etc/hosts</filename> file by running:</para> <screen><userinput>cat > /etc/hosts << "EOF" <literal># Begin /etc/hosts (network card version) @@ -19,6 +53,12 @@ # End /etc/hosts (network card version)</literal> EOF</userinput></screen> +<para>The <replaceable>[192.168.1.1]</replaceable> and +<replaceable>[<HOSTNAME>.example.org]</replaceable> +values need to be changed for specific users or requirements (if +assigned an IP address by a network/system administrator and the +machine will be connected to an existing network).</para> + <para>If a network card is not going to be configured, create the <filename>/etc/hosts</filename> file by running:</para> @@ -31,3 +71,4 @@ EOF</userinput></screen> EOF</userinput></screen> </sect1> + diff --git a/chapter07/inputrc.xml b/chapter07/inputrc.xml index 62fcb3173..200f9a31b 100644 --- a/chapter07/inputrc.xml +++ b/chapter07/inputrc.xml @@ -7,7 +7,45 @@ <title>Creating the /etc/inputrc File</title> <?dbhtml filename="inputrc.html"?> -<para>Create the /etc/inputrc file:</para> +<indexterm zone="ch-scripts-inputrc"><primary sortas="e-/etc/inputrc">/etc/inputrc</primary></indexterm> + +<para>The <filename>/etc/inputrc</filename> file deals with mapping +the keyboard for specific situations. This file is the start-up file +used by <application>Readline</application>, the input-related +library used by <application>Bash</application> and most other +shells.</para> + +<para>For more information, see the bash info page, section +<emphasis>Readline Init File</emphasis>. The readline info page is +also a good source of information.</para> + +<para>Global values are set in <filename>/etc/inputrc</filename>. +Personal user values are set in <filename>~/.inputrc</filename>. The +<filename>~/.inputrc</filename> file will override the global settings +file. A later page sets up Bash to use +<filename>/etc/inputrc</filename> if there is no +<filename>.inputrc</filename> for a user when +<filename>/etc/profile</filename> is read (usually at login). To make +the system use both, or to negate global keyboard handling, it is a +good idea to place a default <filename>.inputrc</filename> into the +<filename class="directory">/etc/skel</filename> directory for use +with new users.</para> + +<para>Below is a base <filename>/etc/inputrc</filename>, along with +comments to explain what the various options do. Note that comments +cannot be on the same line as commands.</para> + +<para>To create the <filename>.inputrc</filename> in <filename +class="directory">/etc/skel</filename> using the command below, change +the command's output to <filename +class="directory">/etc/skel/.inputrc</filename> and be sure to +check/set permissions afterward. Copy that file to +<filename>/etc/inputrc</filename> and the home directory of any user +already existing on the system, including <emphasis>root</emphasis>, +that needs a private version of the file. Be certain to use the +<parameter>-p</parameter> parameter of <command>cp</command> to +maintain permissions and be sure to change owner and group +appropriately.</para> <screen><userinput>cat > /etc/inputrc << "EOF" <literal># Begin /etc/inputrc @@ -56,3 +94,4 @@ set bell-style none EOF</userinput></screen> </sect1> + diff --git a/chapter07/introduction.xml b/chapter07/introduction.xml index bfff7e7c7..b4c8ea547 100644 --- a/chapter07/introduction.xml +++ b/chapter07/introduction.xml @@ -7,6 +7,21 @@ <title>Introduction</title> <?dbhtml filename="introduction.html"?> -<para>See testing</para> +<para>This chapter details how to install the bootscripts and set them up +properly. Most of these scripts will work without modification, but a +few require additional configuration files because they deal with +hardware-dependent information.</para> + +<para>System-V style init scripts are employed in this book because they are +widely used. For additional options, a hint detailing the BSD style +init setup is available at +<ulink +url="http://www.linuxfromscratch.org/hints/downloads/files/bsd-init.txt"/>. +Searching the LFS mailing lists for <quote>depinit</quote> will also offer +additional choices.</para> + +<para>If using an alternate style of init scripts, skip this chapter +and move on to <xref linkend="chapter-bootable"/>.</para> </sect1> + diff --git a/chapter07/network.xml b/chapter07/network.xml index 3a86d1a20..304341033 100644 --- a/chapter07/network.xml +++ b/chapter07/network.xml @@ -7,12 +7,43 @@ <title>Configuring the network Script</title> <?dbhtml filename="network.html"?> +<indexterm zone="ch-scripts-network"> +<primary sortas="d-network">network</primary> +<secondary>configuring</secondary></indexterm> + +<para>This section only applies if a network card is to be +configured.</para> + +<para>If a network card will not be used, there is likely no need to +create any configuration files relating to network cards. If that is +the case, remove the <filename class="symlink">network</filename> +symlinks from all run-level directories (<filename +class="directory">/etc/rc.d/rc*.d</filename>).</para> <sect2> <title>Creating Network Interface Configuration Files</title> -<para>The following command creates a sample <filename>ipv4</filename> file for the -<filename>eth0</filename> device:</para> +<!-- Edit Me --> +<para>Which interfaces are brought up and down by the network script +depends on the files and directories in the <filename +class="directory">/etc/sysconfig/network-devices</filename> hierarchy. +This directory should contain a directory for each interface to be configured, +such as <filename>ifconfig.xyz</filename>, where <quote>xyz</quote> is a +network interface name. Inside this directory would be files defining +the attributes to this interface, such as its IP address(es), subnet +masks, and so forth.</para> +<!-- --> + +<para>If the <filename +class="directory">/etc/sysconfig/network-devices</filename> directory +is to be renamed or moved, make sure to edit the +<filename>/etc/sysconfig/rc</filename> file and update the +<quote>network_devices</quote> option by providing it with the new +path.</para> + +<para>New files are created in this directory. The following +command creates a sample <filename>ipv4</filename> file for the +<emphasis>eth0</emphasis> device:</para> <screen><userinput>cd /etc/sysconfig/network-devices && mkdir ifconfig.eth0 && @@ -25,12 +56,46 @@ PREFIX=24 BROADCAST=192.168.1.255</literal> EOF</userinput></screen> +<para>The values of these variables must be changed in every file to +match the proper setup. If the <envar>ONBOOT</envar> variable is +set to <quote>yes</quote> the network script will bring up the +Network Interface Card (NIC) during booting of the system. If set +to anything but <quote>yes</quote> the NIC will be ignored by the +network script and not brought up.</para> + +<para>The <envar>SERVICE</envar> variable defines the method of +obtaining the IP address. The LFS bootscripts have a modular IP +assignment format, and creating additional files in the <filename +class="directory">/etc/sysconfig/network-devices/services</filename> +directory allows other IP assignment methods. This is commonly used +for Dynamic Host Configuration Protocol (DHCP), which is addressed in the BLFS book.</para> + +<para>The <envar>GATEWAY</envar> variable should contain +the default gateway IP address, if one is present. If not, then comment out +the variable entirely.</para> + +<para>The <envar>PREFIX</envar> variable needs to contain the +number of bits used in the subnet. Each octet in an IP address is 8 +bits. If the subnet's netmask is 255.255.255.0, then it is using the +first three octets (24 bits) to specify the network number. If the +netmask is 255.255.255.240, it would be using the first 28 bits. +Prefixes longer than 24 bits are commonly used by DSL- and cable-based +Internet Service Providers (ISPs). In this example (PREFIX=24), the netmask +is 255.255.255.0. Adjust according to the specific subnet.</para> + </sect2> <sect2 id="resolv.conf"> <title>Creating the /etc/resolv.conf File</title> +<indexterm zone="resolv.conf"><primary sortas="e-/etc/resolv.conf">/etc/resolv.conf</primary></indexterm> -<para>Create the file by running the following:</para> +<para>If the system is going to be connected to the Internet, it will +need some means of Domain Name Service (DNS) name resolution to +resolve Internet domain names to IP addresses, and vice versa. This is +best achieved by placing the IP address of the DNS server, available +from the ISP or network administrator, into +<filename>/etc/resolv.conf</filename>. Create the file by running the +following:</para> <screen><userinput>cat > /etc/resolv.conf << "EOF" <literal># Begin /etc/resolv.conf @@ -42,6 +107,14 @@ nameserver <replaceable>[IP address of your secondary nameserver]</replaceable> # End /etc/resolv.conf</literal> EOF</userinput></screen> +<para>Replace <replaceable>[IP address of the +nameserver]</replaceable> with the IP address of the DNS most +appropriate for the setup. There will often be more than one entry +(requirements demand secondary servers for fallback capability). If +you only need or want one DNS server, remove the second +<emphasis>nameserver</emphasis> line from the file. The IP address may +also be a router on the local network.</para> </sect2> </sect1> + diff --git a/chapter07/profile.xml b/chapter07/profile.xml index d60d64d67..fa1b1a232 100644 --- a/chapter07/profile.xml +++ b/chapter07/profile.xml @@ -7,8 +7,74 @@ <title>The Bash Shell Startup Files</title> <?dbhtml filename="profile.html"?> +<indexterm zone="ch-scripts-profile"><primary sortas="e-/etc/profile">/etc/profile</primary></indexterm> -<para>Create the <filename>/etc/profile</filename> file:</para> +<para>The shell program <command>/bin/bash</command> (hereafter +referred to as <quote>the shell</quote>) uses a collection of startup +files to help create an environment to run in. Each file has a +specific use and may effect login and interactive environments +differently. The files in the <filename +class="directory">/etc</filename> directory provide global settings. +If an equivalent file exists in the home directory, it may override +the global settings.</para> + +<para>An interactive login shell is started after a successful login, +using <command>/bin/login</command>, by reading the +<filename>/etc/passwd</filename> file. An interactive non-login shell +is started at the command-line (e.g., +<prompt>[prompt]$</prompt><command>/bin/bash</command>). A +non-interactive shell is usually present when a shell script is +running. It is non-interactive because it is processing a script and +not waiting for user input between commands.</para> + +<para>For more information, see <command>info bash</command> - Nodes: +Bash Startup Files and Interactive Shells.</para> + +<para>The files <filename>/etc/profile</filename> and +<filename>~/.bash_profile</filename> are read when the shell is +invoked as an interactive login shell.</para> + +<para>A base <filename>/etc/profile</filename> below sets some +environment variables necessary for native language support. Setting +them properly results in:</para> + +<itemizedlist> +<listitem><para>The output of programs translated into the native +language</para></listitem> +<listitem><para>Correct classification of characters into letters, +digits and other classes. This is necessary for Bash to properly +accept non-ASCII characters in command lines in non-English +locales</para></listitem> +<listitem><para>The correct alphabetical sorting order for the +country</para></listitem> +<listitem><para>Appropriate default paper size</para></listitem> +<listitem><para>Correct formatting of monetary, time, and date +values</para></listitem> +</itemizedlist> + +<para>This script also sets the <envar>INPUTRC</envar> +environment variable that makes <application>Bash</application> and +<application>Readline</application> use the +<filename>/etc/inputrc</filename> file created earlier.</para> + +<para>Replace <replaceable>[ll]</replaceable> below with the +two-letter code for the desired language (e.g., <quote>en</quote>) and +<replaceable>[CC]</replaceable> with the two-letter code for the +appropriate country (e.g., <quote>GB</quote>). It may also be +necessary to specify (and this is actually the preferred form) the +character encoding (e.g. <quote>iso8859-1</quote>) after a dot (so +that the result is <quote>en_GB.iso8859-1</quote>). Issue the +following command for more information:</para> + +<screen><userinput>man 3 setlocale</userinput></screen> + +<para>The list of all locales supported by Glibc can be obtained by running +the following command:</para> + +<screen><userinput>locale -a</userinput></screen> + +<para>Once the proper locale settings have been determined, create the +<filename>/etc/profile</filename> file:</para> <screen><userinput>cat > /etc/profile << "EOF" <literal># Begin /etc/profile @@ -20,4 +86,19 @@ export INPUTRC=/etc/inputrc # End /etc/profile</literal> EOF</userinput></screen> +<note><para>The <quote>C</quote> (default) and <quote>en_US</quote> +(the recommended one for United States English users) locales are +different.</para></note> + +<para>Setting the keyboard layout, screen font, and +locale-related environment variables are the only internationalization +steps needed to support locales that use ordinary single-byte +encodings and left-to-right writing direction. More complex cases +(including UTF-8 based locales) require additional steps and +additional patches because many applications tend to not work properly +under such conditions. These steps and patches are not included in +the LFS book and such locales are not supported by LFS in any +way.</para> + </sect1> + diff --git a/chapter07/setclock.xml b/chapter07/setclock.xml index d933eb59f..0527fac00 100644 --- a/chapter07/setclock.xml +++ b/chapter07/setclock.xml @@ -7,6 +7,36 @@ <title>Configuring the setclock Script</title> <?dbhtml filename="setclock.html"?> +<indexterm zone="ch-scripts-setclock"> +<primary sortas="d-setclock">setclock</primary> +<secondary>configuring</secondary></indexterm> + +<para>The <command>setclock</command> script reads the time from the hardware clock, +also known as BIOS or the Complementary Metal Oxide Semiconductor +(CMOS) clock. If the hardware clock is set to UTC, this script will convert the hardware clock's time to +the local time using the <filename>/etc/localtime</filename> file +(which tells the <command>hwclock</command> program which timezone the +user is in). There is no way to +detect whether or not the hardware clock is set to UTC time, so this +needs to be manually configured.</para> + +<para>If you cannot remember whether or not the hardware +clock is set to UTC time, find out by running +the <userinput>hwclock --localtime --show</userinput> command. This will tell +what the current time is according to the hardware clock. If this time +matches whatever your watch says, then the hardware clock is set to +local time. If the output from <command>hwclock</command> is not local +time, chances are it is set to UTC time. Verify this by adding or +subtracting the proper amount of hours for the timezone to this +<command>hwclock</command> time. For example, if you live in the MST +timezone, which is also known as GMT -0700, add seven hours to the local +time. Then, account for Daylight Savings Time, which requires +subtracting an hour (or only add six in the first place) during the summer +months.</para> + +<para>Change the value of the <envar>UTC</envar> variable below +to a value of <parameter>0</parameter> (zero) if the hardware clock +is <emphasis>not</emphasis> set to UTC time.</para> <para>Create a new file <filename>/etc/sysconfig/clock</filename> by running the following:</para> @@ -19,4 +49,9 @@ UTC=1 # End /etc/sysconfig/clock</literal> EOF</userinput></screen> +<para>A good hint explaining how to deal with time on LFS is available +at <ulink url="&hints-root;time.txt"/>. It explains issues such as +time zones, UTC, and the <envar>TZ</envar> environment variable.</para> + </sect1> + diff --git a/chapter07/udev.xml b/chapter07/udev.xml index 73b90c419..51e001134 100644 --- a/chapter07/udev.xml +++ b/chapter07/udev.xml @@ -11,8 +11,235 @@ <primary sortas="a-Udev">Udev</primary> <secondary>usage</secondary></indexterm> +<para>In <xref linkend="chapter-building-system"/>, we installed the Udev +package. Before we go into the details regarding how this works, +a brief history of previous methods of handling devices is in +order.</para> -<para>See testing</para> +<para>Linux systems in general traditionally use a static device +creation method, whereby a great many device nodes are created under +<filename class="directory">/dev</filename> (sometimes literally +thousands of nodes), regardless of whether the corresponding hardware +devices actually exist. This is typically done via a +<command>MAKEDEV</command> script, which contains a number of +calls to the <command>mknod</command> program with the relevant major and minor device +numbers for every possible device that might exist in the world. Using +the udev method, only those devices which are detected by the kernel +get device nodes created for them. Because these device nodes will be +created each time the system boots, they will be stored on a +<systemitem class="filesystem">ramfs</systemitem> (a file system that +resides entirely in memory and does not take up any disk space). +Device nodes do not require much disk space, so the memory that is +used in negligable.</para> + +<sect2> +<title>History</title> + +<para>In February 2000, a new filesystem called <systemitem +class="filesystem">devfs</systemitem> was merged into the 2.3.46 +kernel and was made available during the 2.4 series of +stable kernels. Although it was present in the kernel source itself, +this method of creating devices dynamically never received +overwhelming support from the core kernel developers.</para> + +<para>The main problem with the approach adopted by <systemitem +class="filesystem">devfs</systemitem> was the way it handled +device detection, creation, and naming. The latter issue, that of +device node naming, was perhaps the most critical. It is generally +accepted that if device names are allowed to be configurable, then +the device naming policy should be up to a system administrator, not +imposed on them by any particular developer(s). The <systemitem +class="filesystem">devfs</systemitem> file system also suffers from race +conditions that are inherent in its design and cannot be fixed +without a substantial revision to the kernel. It has also been marked +as deprecated due to a lack of recent maintenance.</para> + +<para>With the development of the unstable 2.5 kernel tree, later +released as the 2.6 series of stable kernels, a new virtual filesystem +called <systemitem class="filesystem">sysfs</systemitem> came to be. +The job of <systemitem class="filesystem">sysfs</systemitem> is to +export a view of the system's structure to userspace processes. With +this userspace visible representation, the possibility of seeing a +userspace replacement for <systemitem +class="filesystem">devfs</systemitem> became much more +realistic.</para> +</sect2> + +<sect2> +<title>Udev Implementation</title> + +<para>The <systemitem class="filesystem">sysfs</systemitem> filesystem +was mentioned briefly above. One may wonder how <systemitem +class="filesystem">sysfs</systemitem> knows about the devices present +on a system and what device numbers should be used. Drivers that +have been compiled into the kernel directly register their objects +with <systemitem class="filesystem">sysfs</systemitem> as they are +detected by the kernel. For drivers compiled as modules, this will +happen when the module is loaded. Once the <systemitem +class="filesystem">sysfs</systemitem> filesystem is mounted (on +<filename class="directory">/sys</filename>), the data which the +built-in drivers registered with <systemitem +class="filesystem">sysfs</systemitem> are available to userspace +processes and to <command>udev</command> for device node creation.</para> + +<para>The <command>S10udev</command> initscript takes care of creating +these device nodes when Linux is booted. This script starts with +registering <command>/sbin/udev</command> as a hotplug event handler. +Hotplug events (discussed below) should not be generated during this +stage, but <command>udev</command> is registered just in case they do +occur. The <command>udevstart</command> program then walks through +the <systemitem class="filesystem">/sys</systemitem> filesystem and +creates devices under <filename class="directory">/dev</filename> that +match the descriptions. For example, +<filename>/sys/class/tty/vcs/dev</filename> contains the string +<quote>7:0</quote> This string is used by <command>udevstart</command> +to create <filename>/dev/vcs</filename> with major number +<emphasis>7</emphasis> and minor <emphasis>0</emphasis>. The +permissions of each and every device that <command>udevstart</command> +creates are set using files from the <filename +class="directory">/etc/udev.d/permissions.d/</filename> directory. +These are numbered in a similar fashion to the LFS bootscripts. If +<command>udev</command> cannot find a permissions file for the device +it is creating, it will default permissions to +<emphasis>600</emphasis> and ownership to +<emphasis>root:root</emphasis>. The names of the nodes created under +the <filename class="directory">/dev</filename> directory are +configured according to the rules specified in the files within the +<filename class="directory">/etc/udev/rules.d/</filename> +directory.</para> + +<para>Once the above stage is complete, all devices that were already +present and have compiled-in drivers will be available for use. What +about those devices that have modular drivers?</para> + +<para>Earlier, we mentioned the concept of a <quote>hotplug event +handler.</quote> When a new device connection is detected by the +kernel, the kernel will generate a hotplug event and look at the file +<filename>/proc/sys/kernel/hotplug</filename> to find out the +userspace program that handles the device's connection. The +<command>udev</command> initscript registered <command>udev</command> +as this handler. When these hotplug events are generated, the kernel +will tell <command>udev</command> to check the <filename +class="directory">/sys</filename> filesystem for the information +pertaining to this new device and create the <filename +class="directory">/dev</filename> entry for it.</para> + +<para>This brings us to one problem that exists with +<command>udev</command>, and likewise with <systemitem +class="filesystem">devfs</systemitem> before it. It is commonly +referred to as the <quote>chicken and egg</quote> problem. Most Linux +distrubtions handle loading modules via entries in +<filename>/etc/modules.conf</filename>. Access to a device node causes +the appropriate kernel module to load. With <command>udev</command>, +this method will not work because the device node does not exist until +the module is loaded. To solve this, the +<command>S05modules</command> bootscript was added to the +lfs-bootscripts package, along with the +<filename>/etc/sysconfig/modules</filename> file. By +adding module +names to the <filename>modules</filename> file, these modules will be +loaded when the computer is starting up. This allows +<command>udev</command> to detect the devices and create the +appropriate device nodes.</para> + +<para>Note that on slower machines or for drivers that create a lot +of device nodes, the process of creating devices may take a few +seconds to complete. This means that some device nodes may not be +immediately accessible.</para> +</sect2> + +<sect2> +<title>Handling Hotpluggable/Dynamic Devices</title> + +<para>When you plug in a device, such a Universal Serial Bus (USB) MP3 player, the kernel +recognizes that the device is now connected and generates a hotplug +event. If the driver is already loaded (either because it was compiled +into the kernel or because it was loaded via the +<command>S05modules</command> bootscript), <command>udev</command> will +be called upon to create the relevant device node(s) according to the +<systemitem class="filesystem">sysfs</systemitem> data available in +<filename class="directory">/sys</filename>. If the driver for the +just plugged in device is available as a module but currently unloaded, +then attaching the device to the system will only cause the kernel's +bus driver to generate a hotplug event that notifies userspace of the +new device connection and it not being attached to a driver. In +effect, nothing happens and the device itself is not usable +yet.</para> + +<para>If building a system that has a lot of drivers compiled as +modules rather than directly built into the kernel, using the +<command>S05modules</command> may not be practical. The Hotplug +package (see <ulink url="http://linux-hotplug.sourceforge.net/"/>) can +be beneficial in these cases. When the Hotplug package is installed, +it will respond to the aforementioned kernel's bus driver hotplug +events. The Hotplug package will load the appropriate module and make +this device available by creating the device node(s) for it.</para> +</sect2> + +<sect2> +<title>Problems with Creating Devices</title> + +<para>There are a few known problems when it comes to automatically creating +devices nodes:</para> + +<para>1) A kernel driver may not export its data to <systemitem +class="filesystem">sysfs</systemitem>.</para> + +<para>This is most common with third party drivers from outside the +kernel tree. These drivers will not end up having their device nodes +created. Use the +<filename>/etc/sysconfig/createfiles</filename> configuration file to +manually create the devices. Consult the +<filename>devices.txt</filename> file inside the kernel documentation +or the documentation for that driver to find the proper major/minor +numbers.</para> + +<para>2) A non-hardware device is required. This is most common with +the Advanced Linux Sound Architecture (ALSA) project's Open Sound +System (OSS) compatibility module. These types of devices can be +handled in one of two ways:</para> + +<itemizedlist> + +<listitem><para>Adding the module names to +<filename>/etc/sysconfig/modules</filename></para></listitem> +<listitem><para>Using an +<quote>install</quote> line in +<filename>/etc/modprobe.conf</filename>. This tells the +<command>modprobe</command> command <quote>when loading this module, +also load this other module, at the same time.</quote> For example:</para> + +<screen><userinput>install snd-pcm modprobe -i snd-pcm ; modprobe \ + snd-pcm-oss ; true</userinput></screen> + +<para>This will cause the system to load both the +<emphasis>snd-pcm</emphasis> and <emphasis>snd-pcm-oss</emphasis> +modules when any request is made to load the driver +<emphasis>snd-pcm</emphasis>.</para></listitem> +</itemizedlist> +</sect2> + +<sect2> +<title>Useful Reading</title> + +<para>Additional helpful documentation is available at the following +sites:</para> + +<itemizedlist> +<listitem><para remap="verbatim">A Userspace Implementation of devfs +<ulink url="http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf"><phrase +condition="pdf">http://www.kroah.com/linux/talks/ols_2003_udev_paper/ +Reprint-Kroah-Hartman-OLS2003.pdf</phrase></ulink></para></listitem> + +<listitem><para remap="verbatim">udev FAQ +<ulink url="http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ"/></para></listitem> + +<listitem><para remap="verbatim">The Linux Kernel Driver Model +<ulink url="http://public.planetmirror.com/pub/lca/2003/proceedings/papers/Patrick_Mochel/Patrick_Mochel.pdf"><phrase +condition="pdf">http://public.planetmirror.com/pub/lca/2003/proceedings/papers/ +Patrick_Mochel/Patrick_Mochel.pdf</phrase></ulink></para></listitem> +</itemizedlist> +</sect2> </sect1> diff --git a/chapter07/usage.xml b/chapter07/usage.xml index 918f981f7..5baede25b 100644 --- a/chapter07/usage.xml +++ b/chapter07/usage.xml @@ -7,7 +7,112 @@ <title>How Do These Bootscripts Work?</title> <?dbhtml filename="usage.html"?> +<indexterm zone="ch-scripts-usage"> +<primary sortas="a-Bootscripts">Bootscripts</primary> +<secondary>usage</secondary></indexterm> -<para>See testing</para> +<para>Linux uses a special booting facility named SysVinit that is +based on a concept of <emphasis>run-levels</emphasis>. It can be quite +different from one system to another, so it cannot be assumed that +because things worked in <insert distro name>, they should work +the same in LFS too. LFS has its own way of doing things, but it +respects generally accepted standards.</para> + +<para>SysVinit (which will be referred to as <quote>init</quote> from +now on) works using a run-levels scheme. There are seven (from 0 to 6) +run-levels (actually, there are more run-levels, but they are for +special cases and are generally not used. The init man page describes +those details), and each one of those corresponds to the actions the +computer is supposed to perform when it starts up. The default +run-level is 3. Here are the descriptions of the different run-levels +as they are implemented:</para> + +<literallayout>0: halt the computer +1: single-user mode +2: multi-user mode without networking +3: multi-user mode with networking +4: reserved for customization, otherwise does the same as 3 +5: same as 4, it is usually used for GUI login (like X's <command>xdm</command> or KDE's <command>kdm</command>) +6: reboot the computer</literallayout> + +<para>The command used to change run-levels is <command>init +<replaceable>[runlevel]</replaceable></command>, where +<replaceable>[runlevel]</replaceable> is the target run-level. For +example, to reboot the computer, a user would issue the <command>init +6</command> command. The <command>reboot</command> command is an +alias for it, as is the <command>halt</command> command an alias for +<command>init 0</command>.</para> + +<para>There are a number of directories under <filename +class="directory">/etc/rc.d</filename> that look like <filename +class="directory">rc?.d</filename> (where ? is the number of the +run-level) and <filename class="directory">rcsysinit.d</filename>, all +containing a number of symbolic links. Some begin with a +<emphasis>K</emphasis>, the others begin with an +<emphasis>S</emphasis>, and all of them have two numbers following the +initial letter. The K means to stop (kill) a service and the S means +to start a service. The numbers determine the order in which the +scripts are run, from 00 to 99—the lower the number the earlier it +gets executed. When init switches to another run-level, the +appropriate services get killed and others get started.</para> + +<para>The real scripts are in <filename +class="directory">/etc/rc.d/init.d</filename>. They do the actual +work, and the symlinks all point to them. Killing links and starting +links point to the same script in <filename +class="directory">/etc/rc.d/init.d</filename>. This is because the +scripts can be called with different parameters like +<parameter>start</parameter>, <parameter>stop</parameter>, +<parameter>restart</parameter>, <parameter>reload</parameter>, and +<parameter>status</parameter>. When a K link is encountered, the +appropriate script is run with the <parameter>stop</parameter> +argument. When an S link is encountered, the appropriate script is run +with the <parameter>start</parameter> argument.</para> + +<para>There is one exception to this explanation. Links that start +with an <emphasis>S</emphasis> in the <filename +class="directory">rc0.d</filename> and <filename +class="directory">rc6.d</filename> directories will not cause anything +to be started. They will be called with the parameter +<parameter>stop</parameter> to stop something. The logic behind this +is that when a user is going to reboot or halt the system, nothing +needs to be started. The system only needs to be stopped.</para> + +<para>These are descriptions of what the arguments make the scripts +do:</para> + +<variablelist> +<varlistentry> +<term><parameter>start</parameter></term> +<listitem><para>The service is started.</para></listitem> +</varlistentry> + +<varlistentry> +<term><parameter>stop</parameter></term> +<listitem><para>The service is stopped.</para></listitem> +</varlistentry> + +<varlistentry> +<term><parameter>restart</parameter></term> +<listitem><para>The service is stopped and then started again.</para></listitem> +</varlistentry> + +<varlistentry> +<term><parameter>reload</parameter></term> +<listitem><para>The configuration of the service is updated. +This is used after the configuration file of a service was modified, when +the service does not need to be restarted.</para></listitem> +</varlistentry> + +<varlistentry> +<term><parameter>status</parameter></term> +<listitem><para>Tells if the service is running and with which PIDs.</para></listitem> +</varlistentry> +</variablelist> + +<para>Feel free to modify the way the boot process works (after all, +it is your own LFS system). The files given here are an example of how +it can be done.</para> </sect1> + |