diff options
| -rw-r--r-- | chapter01/changelog.xml | 3 | ||||
| -rw-r--r-- | chapter07/bootscripts.xml | 32 | ||||
| -rw-r--r-- | chapter07/console.xml | 40 | ||||
| -rw-r--r-- | chapter07/hostname.xml | 16 | ||||
| -rw-r--r-- | chapter07/network.xml | 35 | ||||
| -rw-r--r-- | chapter07/profile.xml | 7 | ||||
| -rw-r--r-- | chapter07/setclock.xml | 39 | ||||
| -rw-r--r-- | chapter07/udev.xml | 144 | ||||
| -rw-r--r-- | chapter07/usage.xml | 57 | ||||
| -rw-r--r-- | general.ent | 4 |
10 files changed, 181 insertions, 196 deletions
diff --git a/chapter01/changelog.xml b/chapter01/changelog.xml index 3da8af896..e2ea85714 100644 --- a/chapter01/changelog.xml +++ b/chapter01/changelog.xml @@ -87,6 +87,9 @@ First a summary, then a detailed log.</para> </itemizedlist> </listitem> +<listitem><para>July 2nd, 2005 [archaic]: Several minor wording changes in +chapter 8 (matt).</para></listitem> + <listitem><para>July 1st, 2005 [archaic]: Several minor wording changes in chapter 6 (matt).</para></listitem> diff --git a/chapter07/bootscripts.xml b/chapter07/bootscripts.xml index 5e0c31478..06c146571 100644 --- a/chapter07/bootscripts.xml +++ b/chapter07/bootscripts.xml @@ -50,8 +50,8 @@ swap, sysklogd, template, and udev</seg></seglistitem> <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> +<para>Checks the integrity of 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> @@ -71,8 +71,8 @@ and removes the possibly present <filename>/etc/nologin</filename>, <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> +<para>Loads the correct keymap table for the desired 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> @@ -80,8 +80,8 @@ layout; it also sets the screen font</para> <varlistentry id="functions-bootscripts"> <term><command>functions</command></term> <listitem> -<para>Contains functions shared among different scripts, such as error -and status checking</para> +<para>Contains common functions that are used by several bootscripts, such as +error and status checking</para> <indexterm zone="ch-scripts-bootscripts functions-bootscripts"><primary sortas="d-functions">functions</primary></indexterm> </listitem> </varlistentry> @@ -97,7 +97,7 @@ and status checking</para> <varlistentry id="hotplug-bootscripts"> <term><command>hotplug</command></term> <listitem> -<para>Load modules for system devices</para> +<para>Loads modules for system devices</para> <indexterm zone="ch-scripts-bootscripts hotplug-bootscripts"><primary sortas="d-hotplug">hotplug</primary></indexterm> </listitem> </varlistentry> @@ -105,7 +105,7 @@ and status checking</para> <varlistentry id="ifdown-bootscripts"> <term><command>ifdown</command></term> <listitem> -<para>Assists the network script with network devices</para> +<para>Assists the network script with stopping network devices</para> <indexterm zone="ch-scripts-bootscripts ifdown-bootscripts"><primary sortas="d-ifdown">ifdown</primary></indexterm> </listitem> </varlistentry> @@ -113,7 +113,7 @@ and status checking</para> <varlistentry id="ifup-bootscripts"> <term><command>ifup</command></term> <listitem> -<para>Assists the network script with network devices</para> +<para>Assists the network script with starting network devices</para> <indexterm zone="ch-scripts-bootscripts ifup-bootscripts"><primary sortas="d-ifup">ifup</primary></indexterm> </listitem> </varlistentry> @@ -138,8 +138,8 @@ and status checking</para> <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> +<para>Mounts virtual kernel 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> @@ -156,9 +156,9 @@ the default gateway (where applicable)</para> <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> +<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> <indexterm zone="ch-scripts-bootscripts rc-bootscripts"><primary sortas="d-rc">rc</primary></indexterm> </listitem> </varlistentry> @@ -226,8 +226,8 @@ daemons</para> <varlistentry id="udev-bootscripts"> <term><command>udev</command></term> <listitem> -<para>Sets up udev and create the device nodes in <filename -class="directory">/dev</filename></para> +<para>Prepares the <filename class="directory">/dev</filename> directory and +starts Udev</para> <indexterm zone="ch-scripts-bootscripts udev-bootscripts"><primary sortas="d-udev">udev</primary></indexterm> </listitem> </varlistentry> diff --git a/chapter07/console.xml b/chapter07/console.xml index cf8ad4d78..1780d790b 100644 --- a/chapter07/console.xml +++ b/chapter07/console.xml @@ -11,26 +11,26 @@ <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 <command>loadkeys</command> and -<command>setfont</command> manual pages -and determine the correct arguments for these programs. Once decided, -create the configuration file with the following command:</para> +<para>This section discusses how to configure the <command>console</command> +bootscript 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 <command>console</command> bootscript will +do nothing.</para> + +<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 +HOWTO's can also help with this (see <ulink +url="http://www.tldp.org/HOWTO/HOWTO-INDEX/other-lang.html"/>. 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 <command>loadkeys</command> and +<command>setfont</command> 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>" diff --git a/chapter07/hostname.xml b/chapter07/hostname.xml index 4d336e5b7..0d89e785f 100644 --- a/chapter07/hostname.xml +++ b/chapter07/hostname.xml @@ -11,19 +11,19 @@ <primary sortas="d-localnet">localnet</primary> <secondary>configuring</secondary></indexterm> -<para>Part of the <command>localnet</command> script is setting up the system's -hostname. This needs to be configured in the +<para>Part of the job of the <command>localnet</command> script is setting the +system's hostname. This needs to be configured in the <filename>/etc/sysconfig/network</filename> file.</para> -<para>Create the <filename>/etc/sysconfig/network</filename> file and enter a hostname by -running:</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> +<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 will be put in the <filename>/etc/hosts</filename> file in the next +section.</para> </sect1> diff --git a/chapter07/network.xml b/chapter07/network.xml index f389ec40a..4dbbdd293 100644 --- a/chapter07/network.xml +++ b/chapter07/network.xml @@ -47,16 +47,15 @@ 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 package has a modular IP assignment format, and -creating additional files in the <filename +<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 be brought up.</para> + +<para>The <envar>SERVICE</envar> variable defines the method used in obtaining +the IP address. The LFS-Bootscripts package has 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> @@ -65,14 +64,14 @@ Configuration Protocol (DHCP), which is addressed in the BLFS book.</para> 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> +<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 the <envar>PREFIX</envar> variable according to +your specific subnet.</para> <beginpage/> diff --git a/chapter07/profile.xml b/chapter07/profile.xml index 64336dc88..9f52bcc48 100644 --- a/chapter07/profile.xml +++ b/chapter07/profile.xml @@ -41,10 +41,9 @@ 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>Correct classification of characters into letters, digits and +other classes. This is necessary for <command>bash</command> 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> diff --git a/chapter07/setclock.xml b/chapter07/setclock.xml index 9b7231aa3..a032d8cf5 100644 --- a/chapter07/setclock.xml +++ b/chapter07/setclock.xml @@ -11,28 +11,25 @@ <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 the 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 +<para>The <command>setclock</command> script reads the time from the hardware +clock, also known as the 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 configured manually.</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 display 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 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. Then, account for Daylight Savings Time, which requires -subtracting an hour (or only add six in the first place) during the summer -months.</para> +time.</para> <para>Change the value of the <envar>UTC</envar> variable below to a value of <parameter>0</parameter> (zero) if the hardware clock diff --git a/chapter07/udev.xml b/chapter07/udev.xml index 7967a8f2b..7cbee0ab8 100644 --- a/chapter07/udev.xml +++ b/chapter07/udev.xml @@ -12,25 +12,23 @@ <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, +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>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">tmpfs</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 is negligible.</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">tmpfs</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> <sect2> <title>History</title> @@ -54,46 +52,45 @@ 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 +<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 +hardrware configuration 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>), data which the +<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 for them. 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 registration will happen when the module is +loaded. Once the <systemitem class="filesystem">sysfs</systemitem> filesystem is +mounted (on <filename class="directory">/sys</filename>), 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> +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/udevsend</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 +device nodes when Linux is booted. This script starts by registering +<command>/sbin/udevsend</command> as a hotplug event handler. Hotplug events +(discussed below) are not usually 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 +<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 names and permissions of the nodes created under +<emphasis>0</emphasis>. The names and permissions 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. These are numbered in @@ -101,39 +98,34 @@ a similar fashion to the LFS-Bootscripts package. If <command>udev</command> can't find a rule for the device it is creating, it will default permissions to <emphasis>660</emphasis> and ownership to <emphasis>root:root</emphasis>.</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>Once the above stage is complete, all devices that were already present +and have compiled-in drivers will be available for use. This leads us to the +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>udevsend</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 +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 determine the userspace program +that handles the device's connection. The <command>udev</command> bootscript +registered <command>udevsend</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 -distributions 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 +<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 distributions 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> +<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 starts 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 @@ -167,14 +159,12 @@ device 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>This is most common with third party drivers from outside the kernel tree. +Udev will be unable to automatically create device nodes for such drivers. 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 diff --git a/chapter07/usage.xml b/chapter07/usage.xml index 5baede25b..9e6672d3e 100644 --- a/chapter07/usage.xml +++ b/chapter07/usage.xml @@ -11,21 +11,19 @@ <primary sortas="a-Bootscripts">Bootscripts</primary> <secondary>usage</secondary></indexterm> -<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> +<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>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 manual 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 @@ -37,24 +35,23 @@ as they are implemented:</para> <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> +<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> +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> +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 +<command>init</command> switches to another run-level, the appropriate services +are either started or stopped, depending on the runlevel chosen.</para> <para>The real scripts are in <filename class="directory">/etc/rc.d/init.d</filename>. They do the actual diff --git a/general.ent b/general.ent index 350c909be..1a9de830d 100644 --- a/general.ent +++ b/general.ent @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="ISO-8859-1"?> -<!ENTITY version "TESTING-20050701"> -<!ENTITY releasedate "July 1, 2005"> +<!ENTITY version "TESTING-20050702"> +<!ENTITY releasedate "July 2, 2005"> <!ENTITY milestone "6.1"> <!ENTITY generic-version "testing"> <!-- Use "svn", "testing", or "x.y[-pre{x}]" --> |