diff options
Diffstat (limited to 'chapter09')
| -rw-r--r-- | chapter09/bootscripts.xml | 14 | ||||
| -rw-r--r-- | chapter09/introduction.xml | 16 | ||||
| -rw-r--r-- | chapter09/network.xml | 42 | ||||
| -rw-r--r-- | chapter09/symlinks.xml | 74 | ||||
| -rw-r--r-- | chapter09/udev.xml | 79 | ||||
| -rw-r--r-- | chapter09/usage.xml | 130 |
6 files changed, 180 insertions, 175 deletions
diff --git a/chapter09/bootscripts.xml b/chapter09/bootscripts.xml index cb88a9fd8..fbffa76df 100644 --- a/chapter09/bootscripts.xml +++ b/chapter09/bootscripts.xml @@ -74,7 +74,7 @@ <term><command>checkfs</command></term> <listitem> <para>Checks the integrity of the file systems before they are mounted - (with the exception of journal and network based file systems)</para> + (with the exception of journaling and network-based file systems)</para> <indexterm zone="ch-config-bootscripts checkfs-bootscripts"> <primary sortas="d-checkfs">checkfs</primary> </indexterm> @@ -173,8 +173,8 @@ <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> + <para>Mounts all file systems, except those that are marked + <emphasis>noauto</emphasis>, or are network based</para> <indexterm zone="ch-config-bootscripts mountfs-bootscripts"> <primary sortas="d-mountfs">mountfs</primary> </indexterm> @@ -208,7 +208,7 @@ <listitem> <para>The master run-level control script; it is responsible for running all the other bootscripts one-by-one, in a sequence determined - by the name of the symbolic links being processed</para> + by the names of the symbolic links to those other bootscripts</para> <indexterm zone="ch-config-bootscripts rc-bootscripts"> <primary sortas="d-rc">rc</primary> </indexterm> @@ -239,8 +239,8 @@ <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> + <para>Resets the system clock to local time if the hardware clock + is not set to UTC</para> <indexterm zone="ch-config-bootscripts setclock-bootscripts"> <primary sortas="d-setclock">setclock</primary> </indexterm> @@ -305,7 +305,7 @@ <term><command>udev</command></term> <listitem> <para>Prepares the <filename class="directory">/dev</filename> - directory and starts Udev</para> + directory and starts the udev daemon</para> <indexterm zone="ch-config-bootscripts udev-bootscripts"> <primary sortas="d-udev">udev</primary> </indexterm> diff --git a/chapter09/introduction.xml b/chapter09/introduction.xml index da5ffe67c..745ca3165 100644 --- a/chapter09/introduction.xml +++ b/chapter09/introduction.xml @@ -11,19 +11,19 @@ <title>Introduction</title> <para>Booting a Linux system involves several tasks. The process must - mount both virtual and real file systems, initialize devices, activate swap, - check file systems for integrity, mount any swap partitions or files, set + mount both virtual and real file systems, initialize devices, + check file systems for integrity, mount and activate any swap partitions or files, set the system clock, bring up networking, start any daemons required by the - system, and accomplish any other custom tasks needed by the user. This + system, and accomplish any other custom tasks specified by the user. This process must be organized to ensure the tasks are performed in the correct - order but, at the same time, be executed as fast as possible.</para> + order and executed as quickly as possible.</para> <sect2 id='sysv-desc'> <title>System V</title> <para>System V is the classic boot process that has been used in Unix and Unix-like systems such as Linux since about 1983. It consists of a small - program, <command>init</command>, that sets up basic programs such as + program, <command>init</command>, that sets up basic processes such as <command>login</command> (via getty) and runs a script. This script, usually named <command>rc</command>, controls the execution of a set of additional scripts that perform the tasks required to initialize the @@ -31,7 +31,7 @@ <para>The <command>init</command> program is controlled by the <filename>/etc/inittab</filename> file and is organized into run levels that - can be run by the user. In LFS, they are used as follows:</para> + can be chosen by the user. In LFS, they are used as follows:</para> <literallayout>0 — halt 1 — Single user mode @@ -70,13 +70,13 @@ <listitem> <para>Serial processing of boot tasks. This is related to the previous - point. A delay in any process such as a file system check, will + point. A delay in any process, such as a file system check, will delay the entire boot process.</para> </listitem> <listitem> <para>Does not directly support advanced features like - control groups (cgroups), and per-user fair share scheduling.</para> + control groups (cgroups) and per-user fair share scheduling.</para> </listitem> <listitem> diff --git a/chapter09/network.xml b/chapter09/network.xml index 5ea7e3add..e2d0a5edf 100644 --- a/chapter09/network.xml +++ b/chapter09/network.xml @@ -17,15 +17,15 @@ <sect2> <title>Creating Network Interface Configuration Files</title> - <para>Which interfaces are brought up and down by the network script - usually depends on the files in <filename - class="directory">/etc/sysconfig/</filename>. This directory should + <para>The files in <filename class="directory">/etc/sysconfig/</filename> + usually determine which interfaces are brought up and down by the network + script. This directory should contain a file for each interface to be configured, such as - <filename>ifconfig.xyz</filename>, where <quote>xyz</quote> should describe + <filename>ifconfig.xyz</filename>, where <quote>xyz</quote> describes the network card. The interface name (e.g. eth0) is usually appropriate. - Inside this file are attributes to this interface, such as its IP - address(es), subnet masks, and so forth. It is necessary that the stem of - the filename be <emphasis>ifconfig</emphasis>.</para> + Each file contains the attributes of one interface, such as its IP + address(es), subnet masks, and so forth. The stem of + the filename must be <emphasis>ifconfig</emphasis>.</para> <note> <para>If the procedure in the previous section was not used, udev @@ -38,10 +38,10 @@ <para>The interface names depend on the implementation and configuration of the udev daemon running on the system. The udev daemon for LFS (installed in <xref linkend="ch-system-eudev"/>) will - not run until the LFS system is booted. So it's unreliable to - determine the interface names being used in LFS system by running + not run until the LFS system is booted. So the interface names + in the LFS system cannot always be determined by running those commands on the host distro, - <emphasis>even though in the chroot environment</emphasis>.</para> + <emphasis>even in the chroot environment</emphasis>.</para> </note> <para>The following command creates a sample file for the @@ -59,14 +59,14 @@ PREFIX=<replaceable>24</replaceable> BROADCAST=<replaceable>192.168.1.255</replaceable></literal> EOF</userinput></screen> - <para>The values in italics must be changed in every file to match - the proper setup.</para> + <para>The values in italics must be changed in each file, to set + the interfaces up correctly.</para> <para>If the <envar>ONBOOT</envar> variable is set to <quote>yes</quote> the System V network script will bring up the Network Interface Card (NIC) during - the system boot process. If set to anything but <quote>yes</quote> the NIC - will be ignored by the network script and not be automatically brought up. - The interface can be manually started or stopped with the + the system boot process. If set to anything besides <quote>yes</quote>, the NIC + will be ignored by the network script and will not be started automatically. + Interfaces can be manually started or stopped with the <command>ifup</command> and <command>ifdown</command> commands.</para> <para>The <envar>IFACE</envar> variable defines the interface name, @@ -84,11 +84,11 @@ EOF</userinput></screen> gateway IP address, if one is present. If not, then comment out the variable entirely.</para> - <para>The <envar>PREFIX</envar> variable contains 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 + <para>The <envar>PREFIX</envar> variable specifies the number of + bits used in the subnet. Each segment of an IP address is 8 bits. If the + subnet's netmask is 255.255.255.0, then it is using the first three segments (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 + the subnet is 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 the <envar>PREFIX</envar> variable according to your specific subnet. @@ -139,7 +139,7 @@ EOF</userinput></screen> </sect2> <sect2 id="ch-config-hostname"> - <title>Configuring the system hostname</title> + <title>Configuring the System Hostname</title> <indexterm zone="ch-config-hostname"> <primary sortas="d-hostname">hostname</primary> @@ -156,7 +156,7 @@ EOF</userinput></screen> <para><replaceable><lfs></replaceable> needs to be replaced with the name given to the computer. Do not enter the Fully Qualified Domain Name - (FQDN) here. That information is put in the + (FQDN) here. That information goes in the <filename>/etc/hosts</filename> file.</para> </sect2> diff --git a/chapter09/symlinks.xml b/chapter09/symlinks.xml index 24ebf537d..86528ba69 100644 --- a/chapter09/symlinks.xml +++ b/chapter09/symlinks.xml @@ -17,27 +17,28 @@ <para>Udev, by default, names network devices according to Firmware/BIOS data or physical characteristics like the bus, slot, or MAC address. The purpose of this naming convention is to ensure that network devices are - named consistently and not based on the time the network card was - discovered. For example, on a computer having two network cards made by - Intel and Realtek, the network card manufactured by Intel may become eth0 - and the Realtek card becomes eth1. In some cases, after a reboot the cards - could get renumbered the other way around.</para> - - <para>In the new naming scheme, typical network device names would then - be something like enp5s0 or wlp3s0. If this naming convention is not - desired, the traditional naming scheme or a custom scheme can be + named consistently, not based on when the network card was + discovered. In older versions of Linux—on a computer with two + network cards made by Intel and Realtek, for instance—the + network card manufactured by Intel might have become eth0 + while the Realtek card became eth1. After a reboot, the cards + would sometimes get renumbered the other way around.</para> + + <para>In the new naming scheme, typical network device names are + something like enp5s0 or wlp3s0. If this naming convention is not + desired, the traditional naming scheme, or a custom scheme, can be implemented.</para> <sect3> <title>Disabling Persistent Naming on the Kernel Command Line</title> - <para>The traditional naming scheme using eth0, eth1, etc can be + <para>The traditional naming scheme using eth0, eth1, etc. can be restored by adding <userinput>net.ifnames=0</userinput> on the - kernel command line. This is most appropriate for those systems - that have only one ethernet device of the same type. Laptops - often have multiple ethernet connections that are named eth0 and - wlan0 and are also candidates for this method. The command line - is passed in the GRUB configuration file. + kernel command line. This is most appropriate for systems + that have just one ethernet device of a particular type. Laptops + often have two ethernet connections named eth0 and + wlan0; such laptops can also use this method. The command line + is in the GRUB configuration file. See <xref linkend="grub-cfg"/>.</para> </sect3> @@ -56,23 +57,22 @@ <screen role="nodump"><userinput>cat /etc/udev/rules.d/70-persistent-net.rules</userinput></screen> - <note><para>In some cases such as when MAC addresses have been assigned to - a network card manually or in a virtual environment such as Qemu or Xen, - the network rules file may not have been generated because addresses + <note><para>In some cases, such as when MAC addresses have been assigned to + a network card manually, or in a virtual environment such as Qemu or Xen, + the network rules file may not be generated because addresses are not consistently assigned. In these cases, this method cannot be used.</para></note> - <para>The file begins with a comment block followed by two lines for each + <para>The file begins with a comment block, followed by two lines for each NIC. The first line for each NIC is a commented description showing its hardware IDs (e.g. its PCI vendor and device IDs, if it's a PCI card), - along with its driver in parentheses, if the driver can be found. Neither + along with its driver (in parentheses, if the driver can be found). Neither the hardware ID nor the driver is used to determine which name to give an interface; this information is only for reference. The second line is the udev rule that matches this NIC and actually assigns it a name.</para> - <para>All udev rules are made up of several keys, separated by commas and - optional whitespace. This rule's keys and an explanation of each of them - are as follows:</para> + <para>All udev rules are made up of several keywords, separated by commas and + optional whitespace. Here are the keywords, and an explanation of each one:</para> <itemizedlist> <listitem> @@ -88,10 +88,10 @@ <para><literal>DRIVERS=="?*"</literal> - This exists so that udev will ignore VLAN or bridge sub-interfaces (because these sub-interfaces do not have drivers). These sub-interfaces are skipped because the name - that would be assigned would collide with their parent devices.</para> + that would be assigned would collide with the parent devices.</para> </listitem> <listitem> - <para><literal>ATTR{address}</literal> - The value of this key is the + <para><literal>ATTR{address}</literal> - The value of this keyword is the NIC's MAC address.</para> </listitem> <listitem> @@ -102,7 +102,7 @@ skipped: there would be a name collision otherwise.</para> </listitem> <listitem> - <para><literal>NAME</literal> - The value of this key is the name that + <para><literal>NAME</literal> - The value of this keyword is the name that udev will assign to this interface.</para> </listitem> </itemizedlist> @@ -110,7 +110,7 @@ <para>The value of <literal>NAME</literal> is the important part. Make sure you know which name has been assigned to each of your network cards before proceeding, and be sure to use that <literal>NAME</literal> value when - creating your configuration files below.</para> + creating your network configuration files.</para> </sect3> @@ -118,10 +118,10 @@ <sect2 revision="sysv"> - <title>CD-ROM symlinks</title> + <title>CD-ROM Symlinks</title> <para>Some software that you may want to install later (e.g., various - media players) expect the <filename class="symlink">/dev/cdrom</filename> + media players) expects the <filename class="symlink">/dev/cdrom</filename> and <filename class="symlink">/dev/dvd</filename> symlinks to exist, and to point to a CD-ROM or DVD-ROM device. Also, it may be convenient to put references to those symlinks into <filename>/etc/fstab</filename>. Udev @@ -139,15 +139,15 @@ <command>ata_id</command> or <command>scsi_id</command> programs, depending on which type of device you have.</para> - <para>There are advantages to each approach; the correct approach to use - will depend on what kinds of device changes may happen. If you expect the + <para>There are advantages to each approach; the correct approach + depends on what kinds of device changes may happen. If you expect the physical path to the device (that is, the ports and/or slots that it plugs into) to change, for example because you plan on moving the drive to a different IDE port or a different USB connector, then you should use the <quote>by-id</quote> mode. On the other hand, if you expect the device's - identification to change, for example because it may die, and you would - replace it with a different device with the same capabilities and which - is plugged into the same connectors, then you should use the + identification to change, for example because it may die, and you intend + to replace it with a different device that + plugs into the same connectors, then you should use the <quote>by-path</quote> mode.</para> <para>If either type of change is possible with your drive, then choose a @@ -198,13 +198,13 @@ this is only an issue if you need the symlinks on both systems to point to the same device. If you need that, then inspect (and possibly edit) the generated <filename>/etc/udev/rules.d/70-persistent-cd.rules</filename> - file after booting, to make sure the assigned symlinks match what you need.</para> + file after booting, to make sure the assigned symlinks match your needs.</para> </sect2> <sect2> - <title>Dealing with duplicate devices</title> + <title>Dealing with Duplicate Devices</title> <para>As explained in <xref linkend="ch-config-udev"/>, the order in which devices with the same function appear in @@ -214,7 +214,7 @@ <filename>/dev/video1</filename> refers to the tuner, and sometimes after a reboot the order changes. For all classes of hardware except sound cards and network cards, this is - fixable by creating udev rules for custom persistent symlinks. + fixable by creating udev rules to create persistent symlinks. The case of network cards is covered separately in <xref linkend="ch-config-network"/>, and sound card configuration can be found in <ulink url="&blfs-book;postlfs/devices.html">BLFS</ulink>.</para> diff --git a/chapter09/udev.xml b/chapter09/udev.xml index 396f2b389..20212035c 100644 --- a/chapter09/udev.xml +++ b/chapter09/udev.xml @@ -16,23 +16,23 @@ </indexterm> <para>In <xref linkend="chapter-building-system"/>, we installed the udev - package when <phrase revision="sysv">eudev</phrase> + daemon when <phrase revision="sysv">eudev</phrase> <phrase revision="systemd">systemd</phrase> was built. Before we go into the - details regarding how this works, a brief history of previous methods of + details regarding how udev works, a brief history of previous methods of handling devices is in order.</para> <para>Linux systems in general traditionally used a static device creation method, whereby a great many device nodes were created under <filename class="directory">/dev</filename> (sometimes literally thousands of nodes), regardless of whether the corresponding hardware devices actually existed. This - was typically done via a <command>MAKEDEV</command> script, which contains a + was typically done via a <command>MAKEDEV</command> script, which contained 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.</para> - <para>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 + <para>Using the udev method, device nodes are only created for those devices + which are detected by the kernel. These device nodes are + created each time the system boots; they are stored in a <systemitem class="filesystem">devtmpfs</systemitem> file system (a virtual file system that resides entirely in system memory). Device nodes do not require much space, so the memory that is used is negligible.</para> @@ -51,23 +51,23 @@ 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 + device names are configurable, the device naming policy + should be chosen by system administrators, and not imposed on them by the + developer(s). The <systemitem class="filesystem">devfs</systemitem> file system also suffered from race - conditions that were inherent in its design and could not be fixed without a - substantial revision to the kernel. It was marked as deprecated for a long - period – due to a lack of maintenance – and was finally removed + conditions that were inherent in its design; these could not be fixed without a + substantial revision of the kernel. <systemitem class="filesystem">devfs</systemitem> + was marked as deprecated for a long + time, and was finally removed from the kernel in June, 2006.</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 + <systemitem class="filesystem">sysfs</systemitem> is to provide information about the system's hardware configuration to userspace processes. With this - userspace-visible representation, the possibility of developing a userspace - replacement for <systemitem class="filesystem">devfs</systemitem> became - much more realistic.</para> + userspace-visible representation, it became possible to develop a userspace + replacement for <systemitem class="filesystem">devfs</systemitem>.</para> </sect2> @@ -81,12 +81,13 @@ 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 for them. Drivers that - have been compiled into the kernel directly register their objects with a + have been compiled into the kernel register their objects in <systemitem class="filesystem">sysfs</systemitem> (devtmpfs internally) - as they are detected by the kernel. For drivers compiled as modules, this - registration will happen when the module is loaded. Once the <systemitem - class="filesystem">sysfs</systemitem> filesystem is mounted (on /sys), - data which the drivers register with <systemitem + as they are detected by the kernel. For drivers compiled as modules, + registration happens when the module is loaded. Once the <systemitem + class="filesystem">sysfs</systemitem> filesystem is mounted (on + <filename class="directory">/sys</filename>), + data which the drivers have registered with <systemitem class="filesystem">sysfs</systemitem> are available to userspace processes and to udevd for processing (including modifications to device nodes).</para> @@ -96,13 +97,13 @@ <sect3 id='ch-config-udev-device-node-creation'> <title>Device Node Creation</title> - <para>Device files are created by the kernel by the <systemitem - class="filesystem">devtmpfs</systemitem> filesystem. Any driver that - wishes to register a device node will go through the <systemitem + <para>Device files are created by the kernel in the <systemitem + class="filesystem">devtmpfs</systemitem> file system. Any driver that + wishes to register a device node will use the <systemitem class="filesystem">devtmpfs</systemitem> (via the driver core) to do it. When a <systemitem class="filesystem">devtmpfs</systemitem> instance is mounted on <filename class="directory">/dev</filename>, the device node - will initially be created with a fixed name, permissions, and + will initially be exposed to userspace with a fixed name, permissions, and owner.</para> <para>A short time later, the kernel will send a uevent to <command> @@ -172,7 +173,7 @@ creating device nodes.</para> <sect3> - <title>A kernel module is not loaded automatically</title> + <title>A Kernel Module Is Not Loaded Automatically</title> <para>Udev will only load a module if it has a bus-specific alias and the bus driver properly exports the necessary aliases to <systemitem @@ -206,8 +207,8 @@ </sect3> <sect3> - <title>A kernel module is not loaded automatically, and udev is not - intended to load it</title> + <title>A Kernel Module Is Not Loaded Automatically, and Udev Is Not + Intended to Load It</title> <para>If the <quote>wrapper</quote> module only enhances the functionality provided by some other module (e.g., @@ -236,7 +237,7 @@ </sect3> <sect3> - <title>Udev loads some unwanted module</title> + <title>Udev Loads Some Unwanted Module</title> <para>Either don't build the module, or blacklist it in a <filename>/etc/modprobe.d/blacklist.conf</filename> file as done with the @@ -250,7 +251,7 @@ </sect3> <sect3> - <title>Udev creates a device incorrectly, or makes a wrong symlink</title> + <title>Udev Creates a Device Incorrectly, or Makes the Wrong Symlink</title> <para>This usually happens if a rule unexpectedly matches a device. For example, a poorly-written rule can match both a SCSI disk (as desired) @@ -261,7 +262,7 @@ </sect3> <sect3> - <title>Udev rule works unreliably</title> + <title>Udev Rule Works Unreliably</title> <para>This may be another manifestation of the previous problem. If not, and your rule uses <systemitem class="filesystem">sysfs</systemitem> @@ -275,15 +276,15 @@ </sect3> <sect3> - <title>Udev does not create a device</title> + <title>Udev Does Not Create a Device</title> - <para>Further text assumes that the driver is built statically into the - kernel or already loaded as a module, and that you have already checked - that udev doesn't create a misnamed device.</para> + <para>First, be certain that the driver is built into the + kernel or already loaded as a module, and that + udev isn't creating a misnamed device.</para> - <para>Udev has no information needed to create a device node if a kernel - driver does not export its data to - <systemitem class="filesystem">sysfs</systemitem>. This is most common + <para>If a kernel driver does not export its data to + <systemitem class="filesystem">sysfs</systemitem>, udev lacks the + information needed to create a device node. This is most likely to happen with third party drivers from outside the kernel tree. Create a static device node in <filename>/usr/lib/udev/devices</filename> with the appropriate major/minor numbers (see the file @@ -295,7 +296,7 @@ </sect3> <sect3> - <title>Device naming order changes randomly after rebooting</title> + <title>Device Naming Order Changes Randomly After Rebooting</title> <para>This is due to the fact that udev, by design, handles uevents and loads modules in parallel, and thus in an unpredictable order. This will diff --git a/chapter09/usage.xml b/chapter09/usage.xml index 88c0296d6..2e9843988 100644 --- a/chapter09/usage.xml +++ b/chapter09/usage.xml @@ -19,25 +19,29 @@ <sect2> <title>How Do the System V Bootscripts Work?</title> - <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 one - particular Linux distribution, they should work the same in LFS too. LFS has its - own way of doing things, but it respects generally accepted standards.</para> + <para>This version of LFS uses a special booting facility named SysVinit, based on a + series of <emphasis>run levels</emphasis>. The boot procedure can be quite different from one + system to another; the fact that things worked one way in a particular Linux + distribution does not guarantee they will work the same way in LFS. LFS has its + own way of doing things, but it does respect generally accepted standards.</para> + + <para>There is an alternative boot procedure called <command>systemd</command>. We will + not discuss that boot process any further here. For a detailed description visit + <ulink url="https://www.linux.com/training-tutorials/understanding-and-using-systemd/"/>.</para> <para>SysVinit (which will be referred to as <quote>init</quote> from now on) - works using a run-levels scheme. There are seven (numbered 0 to 6) run-levels - (actually, there are more run-levels, but they are for special cases and are - generally not used. See <filename>init(8)</filename> for more 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 in LFS:</para> + uses a run levels scheme. There are seven run levels, numbered 0 to 6. + (Actually, there are more run levels, but the others are for special cases and are + generally not used. See <filename>init(8)</filename> for more details.) + Each one of the seven corresponds to actions the computer is supposed to + perform when it starts up or shuts down. The default run level is 3. Here are the + descriptions of the different run levels as they are implemented in LFS:</para> <literallayout>0: halt the computer 1: single-user mode -2: reserved for customization, otherwise does the same as 3 +2: reserved for customization, otherwise the same as 3 3: multi-user mode with networking -4: reserved for customization, otherwise does the same as 3 +4: reserved for customization, otherwise the same as 3 5: same as 4, it is usually used for GUI login (like GNOME's <command>gdm</command> or LXDE's <command>lxdm</command>) 6: reboot the computer</literallayout> @@ -45,9 +49,9 @@ <para> Classically, run level 2 above was defined as "multi-user mode without networking", but this was only the case - many years ago when multiple users could log into a system connected via - serial ports. In today's environment it makes no sense and - we designate it now as "reserved". + many years ago when multiple users could connect to a system via + serial ports. In today's environment it makes no sense, and + we now say it is "reserved". </para> </note> @@ -65,8 +69,8 @@ <primary sortas="e-/etc/inittab">/etc/inittab</primary> </indexterm> - <para>During the kernel initialization, the first program that is run - is either specified on the command line or, by default + <para>During kernel initialization, the first program that is run + (if not overridden on the command line) is <command>init</command>. This program reads the initialization file <filename>/etc/inittab</filename>. Create this file with:</para> @@ -101,8 +105,8 @@ s1:1:respawn:/sbin/sulogin EOF</userinput></screen> <para>An explanation of this initialization file is in the man page for - <emphasis>inittab</emphasis>. For LFS, the key command that is run is - <command>rc</command>. The initialization file above will instruct + <emphasis>inittab</emphasis>. In LFS, the key command is + <command>rc</command>. The initialization file above instructs <command>rc</command> to run all the scripts starting with an S in the <filename class="directory">/etc/rc.d/rcS.d</filename> directory followed by all the scripts starting with an S in the <filename @@ -113,22 +117,22 @@ EOF</userinput></screen> functions in <filename class="directory">/lib/lsb/init-functions</filename>. This library also reads an optional configuration file, <filename>/etc/sysconfig/rc.site</filename>. Any of the system - configuration file parameters described in subsequent sections can be - alternatively placed in this file allowing consolidation of all system + configuration parameters described in subsequent sections can be + placed in this file, allowing consolidation of all system parameters in this one file.</para> <para>As a debugging convenience, the functions script also logs all output to <filename>/run/var/bootlog</filename>. Since the <filename class="directory">/run</filename> directory is a tmpfs, this file is not - persistent across boots, however it is appended to the more permanent file + persistent across boots; however, it is appended to the more permanent file <filename>/var/log/boot.log</filename> at the end of the boot process.</para> <sect3 id="init-levels" > <title>Changing Run Levels</title> - <para>Changing run-levels is done with <command>init + <para>Changing run levels is done with <command>init <replaceable><runlevel></replaceable></command>, where - <replaceable><runlevel></replaceable> is the target run-level. For example, to + <replaceable><runlevel></replaceable> is the target run level. For example, to reboot the computer, a user could issue the <command>init 6</command> command, which is an alias for the <command>reboot</command> command. Likewise, <command>init 0</command> is an alias for the <command>halt</command> @@ -136,15 +140,15 @@ EOF</userinput></screen> <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 + class="directory">rc?.d</filename> (where ? is the number of the run level) and <filename class="directory">rcS.d</filename>, all containing a number of - symbolic links. Some begin with a <emphasis>K</emphasis>, the others begin with + symbolic links. Some links 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 - <command>init</command> switches to another run-level, the appropriate services - are either started or stopped, depending on the runlevel chosen.</para> + to 99—the smaller the number, the sooner tht script runs. When + <command>init</command> switches to another run level, the appropriate services + are either started or stopped, depending on the run level chosen.</para> <para>The real scripts are in <filename class="directory">/etc/rc.d/init.d</filename>. They do the actual work, and @@ -227,25 +231,25 @@ EOF</userinput></screen> <para>The <filename>/etc/rc.d/init.d/udev</filename> initscript starts <command>udevd</command>, triggers any "coldplug" devices that have - already been created by the kernel and waits for any rules to complete. + already been created by the kernel, and waits for any rules to complete. The script also unsets the uevent handler from the default of <filename>/sbin/hotplug </filename>. This is done because the kernel no - longer needs to call out to an external binary. Instead + longer needs to call an external binary. Instead, <command>udevd</command> will listen on a netlink socket for uevents that the kernel raises.</para> - <para>The <command>/etc/rc.d/init.d/udev_retry</command> initscript takes + <para>The <command>/etc/rc.d/init.d/udev_retry</command> script takes care of re-triggering events for subsystems whose rules may rely on - filesystems that are not mounted until the <command>mountfs</command> + file systems that are not mounted until the <command>mountfs</command> script is run (in particular, <filename class="directory">/usr</filename> and <filename class="directory">/var</filename> may cause this). This script runs after the <command>mountfs</command> script, so those rules (if re-triggered) should succeed the second time around. It is - configured from the <filename>/etc/sysconfig/udev_retry</filename> file; + configured by the <filename>/etc/sysconfig/udev_retry</filename> file; any words in this file other than comments are considered subsystem names to trigger at retry time. To find the subsystem of a device, use <command>udevadm info --attribute-walk <device></command> where - <device> is an absolute path in /dev or /sys such as /dev/sr0 or + <device> is an absolute path in /dev or /sys, such as /dev/sr0, or /sys/class/rtc.</para> <para>For information on kernel module loading and udev, see @@ -260,13 +264,13 @@ EOF</userinput></screen> <secondary>configuring</secondary></indexterm> <para>The <command>setclock</command> script reads the time from the hardware - clock, also known as the BIOS or the Complementary Metal Oxide Semiconductor + clock, also known as the BIOS or 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 to use). There is no + <command>hwclock</command> program which time zone to use). There is no way to detect whether or not the hardware clock is set to UTC, so this - needs to be configured manually.</para> + must be configured manually.</para> <para>The <command>setclock</command> program is run via <application>udev</application> when the kernel detects the hardware @@ -279,9 +283,9 @@ EOF</userinput></screen> 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 the time shown by + the proper number of hours for your time zone to the time shown by <command>hwclock</command>. For example, if you are currently in the MST - timezone, which is also known as GMT -0700, add seven hours to the local + time zone, which is also known as GMT -0700, add seven hours to the local time.</para> <para>Change the value of the <envar>UTC</envar> variable below @@ -325,7 +329,7 @@ EOF</userinput></screen> <para>This section discusses how to configure the <command>console</command> bootscript that sets up the keyboard map, console font, and console kernel log level. If non-ASCII characters (e.g., the copyright sign, the British pound - sign and Euro symbol) will not be used and the keyboard is a U.S. one, much + sign, and the Euro symbol) will not be used and the keyboard is a U.S. one, much of this section can be skipped. Without the configuration file, (or equivalent settings in <filename>rc.site</filename>), the <command>console</command> bootscript will do nothing.</para> @@ -333,11 +337,11 @@ EOF</userinput></screen> <para>The <command>console</command> script reads the <filename>/etc/sysconfig/console</filename> file for configuration information. Decide which keymap and screen font will be used. Various - language-specific HOWTOs can also help with this, see <ulink + language-specific HOWTOs can also help with this; see <ulink url="https://tldp.org/HOWTO/HOWTO-INDEX/other-lang.html"/>. If still in doubt, look in the <filename class="directory">/usr/share/keymaps</filename> and <filename class="directory">/usr/share/consolefonts</filename> directories - for valid keymaps and screen fonts. Read <filename>loadkeys(1)</filename> and + for valid keymaps and screen fonts. Read the <filename>loadkeys(1)</filename> and <filename>setfont(8)</filename> manual pages to determine the correct arguments for these programs.</para> @@ -358,7 +362,7 @@ EOF</userinput></screen> <term>KEYMAP</term> <listitem> <para>This variable specifies the arguments for the - <command>loadkeys</command> program, typically, the name of keymap + <command>loadkeys</command> program, typically, the name of the keymap to load, e.g., <quote>it</quote>. If this variable is not set, the bootscript will not run the <command>loadkeys</command> program, and the default kernel keymap will be used. Note that a few keymaps @@ -390,11 +394,11 @@ EOF</userinput></screen> name, <quote>-m</quote>, and the name of the application character map to load. E.g., in order to load the <quote>lat1-16</quote> font together with the <quote>8859-1</quote> application character map - (as it is appropriate in the USA), + (appropriate in the USA), <!-- because of the copyright sign --> set this variable to <quote>lat1-16 -m 8859-1</quote>. - In UTF-8 mode, the kernel uses the application character map for - conversion of composed 8-bit key codes in the keymap to UTF-8, and thus + In UTF-8 mode, the kernel uses the application character map to + convert 8-bit key codes to UTF-8. Therefore the argument of the "-m" parameter should be set to the encoding of the composed key codes in the keymap.</para> @@ -404,7 +408,7 @@ EOF</userinput></screen> <varlistentry> <term>UNICODE</term> <listitem> - <para>Set this variable to <quote>1</quote>, <quote>yes</quote> or + <para>Set this variable to <quote>1</quote>, <quote>yes</quote>, or <quote>true</quote> in order to put the console into UTF-8 mode. This is useful in UTF-8 based locales and harmful otherwise.</para> @@ -522,7 +526,7 @@ EOF</userinput></screen> UTF-8 mode it is a problem; e.g., for the Greek language, where one sometimes needs to put an accent on the letter <quote>alpha</quote>. The solution is either to avoid the use of UTF-8, or to install the - X window system that doesn't have this limitation in its input + X window system, which doesn't have this limitation, in its input handling.</para> </listitem> @@ -531,7 +535,7 @@ EOF</userinput></screen> console cannot be configured to display the needed characters. Users who need such languages should install the X Window System, fonts that cover the necessary character ranges, and the proper input method (e.g., - SCIM, supports a wide variety of languages).</para> + SCIM supports a wide variety of languages).</para> </listitem> </itemizedlist> @@ -565,7 +569,7 @@ EOF</userinput></screen> </sect2> <sect2 id="ch-config-sysklogd"> - <title>Configuring the sysklogd Script</title> + <title>Configuring the Sysklogd Script</title> <indexterm zone="ch-config-sysklogd"> <primary sortas="d-sysklogd">sysklogd</primary> @@ -600,8 +604,8 @@ EOF</userinput></screen> <filename>console</filename>, and <filename>clock</filename> files in the <filename class='directory'>/etc/sysconfig/</filename> directory. If the associated variables are present in both these separate files and - <filename>rc.site</filename>, the values in the script specific files have - precedence. </para> + <filename>rc.site</filename>, the values in the script-specific files take + effect. </para> <para><filename>rc.site</filename> also contains parameters that can customize other aspects of the boot process. Setting the IPROMPT variable @@ -615,8 +619,8 @@ EOF</userinput></screen> <title>Customizing the Boot and Shutdown Scripts</title> <para>The LFS boot scripts boot and shut down a system in a fairly - efficient manner, but there are a few tweaks that you can make in the - rc.site file to improve speed even more and to adjust messages according + efficient manner, but there are a few tweaks you can make in the + rc.site file to improve speed even more, and to adjust messages according to your preferences. To do this, adjust the settings in the <filename>/etc/sysconfig/rc.site</filename> file above.</para> @@ -624,18 +628,18 @@ EOF</userinput></screen> <listitem><para>During the boot script <filename>udev</filename>, there is a call to <command>udev settle</command> that requires some time to - complete. This time may or may not be required depending on devices present + complete. This time may or may not be required depending on the devices in the system. If you only have simple partitions and a single ethernet card, the boot process will probably not need to wait for this command. To skip it, set the variable OMIT_UDEV_SETTLE=y.</para></listitem> <listitem><para>The boot script <filename>udev_retry</filename> also runs - <command>udev settle</command> by default. This command is only needed by - default if the <filename class='directory'>/var</filename> directory is - separately mounted. This is because the clock needs the file - <filename>/var/lib/hwclock/adjtime</filename>. Other customizations may + <command>udev settle</command> by default. This command is only needed + if the <filename class='directory'>/var</filename> directory is + separately mounted, because the clock needs the + <filename>/var/lib/hwclock/adjtime</filename> file. Other customizations may also need to wait for udev to complete, but in many installations it is not - needed. Skip the command by setting the variable OMIT_UDEV_RETRY_SETTLE=y. + necessary. Skip the command by setting the variable OMIT_UDEV_RETRY_SETTLE=y. </para></listitem> <listitem><para>By default, the file system checks are silent. This can @@ -664,7 +668,7 @@ EOF</userinput></screen> <listitem><para>During shutdown, the <command>init</command> program sends a TERM signal to each program it has started (e.g. agetty), waits for a set - time (default 3 seconds), and sends each process a KILL signal and waits + time (default 3 seconds), then sends each process a KILL signal and waits again. This process is repeated in the <command>sendsignals</command> script for any processes that are not shut down by their own scripts. The delay for <command>init</command> can be set by passing a parameter. For |