diff --git a/chapter01/changelog.xml b/chapter01/changelog.xml index 42c4fb7c1..d3039bfab 100644 --- a/chapter01/changelog.xml +++ b/chapter01/changelog.xml @@ -91,6 +91,9 @@ First a summary, then a detailed log. +July 2nd, 2005 [archaic]: Several minor wording changes in +chapter 8 (matt). + July 1st, 2005 [archaic]: Brought all occurences of LFS-Bootscripts into conformity. diff --git a/chapter07/bootscripts.xml b/chapter07/bootscripts.xml index 721b4e909..2024f4208 100644 --- a/chapter07/bootscripts.xml +++ b/chapter07/bootscripts.xml @@ -50,8 +50,8 @@ swap, sysklogd, template, and udev checkfs -Checks the file systems before they are mounted (with the exception of journal -and network based file systems) +Checks the integrity of the file systems before they are mounted (with the +exception of journal and network based file systems) checkfs @@ -71,8 +71,8 @@ and removes the possibly present /etc/nologin, console -Loads the keymap table specified as proper for the keyboard -layout; it also sets the screen font +Loads the correct keymap table for the desired keyboard layout; it also +sets the screen font console @@ -80,8 +80,8 @@ layout; it also sets the screen font functions -Contains functions shared among different scripts, such as error -and status checking +Contains common functions that are used by several bootscripts, such as +error and status checking functions @@ -97,7 +97,7 @@ and status checking hotplug -Load modules for system devices +Loads modules for system devices hotplug @@ -105,7 +105,7 @@ and status checking ifdown -Assists the network script with network devices +Assists the network script with stopping network devices ifdown @@ -113,7 +113,7 @@ and status checking ifup -Assists the network script with network devices +Assists the network script with starting network devices ifup @@ -138,8 +138,8 @@ and status checking mountkernfs -Is used to mount kernel-provided file systems, such as -proc +Mounts virtual kernel file systems, such as proc mountkernfs @@ -156,9 +156,9 @@ the default gateway (where applicable) rc -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 +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 rc @@ -226,8 +226,8 @@ daemons udev -Sets up udev and create the device nodes in /dev +Prepares the /dev directory and +starts Udev udev diff --git a/chapter07/console.xml b/chapter07/console.xml index e7e3da325..736d1be9e 100644 --- a/chapter07/console.xml +++ b/chapter07/console.xml @@ -11,26 +11,26 @@ console configuring -This section discusses how to configure the -console 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. +This section discusses how to configure the console +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 console bootscript will +do nothing. -The console script uses the -/etc/sysconfig/console as a configuration file. -Decide which keymap and screen font will be used. The -language-specific HOWTO can help with this. A pre-made -/etc/sysconfig/console 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 /usr/share/kbd 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: +The console script reads the +/etc/sysconfig/console file for configuration information. +Decide which keymap and screen font will be used. Various language-specific +HOWTO's can also help with this (see . A pre-made +/etc/sysconfig/console 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 /usr/share/kbd 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: cat >/etc/sysconfig/console <<"EOF" KEYMAP="[arguments for loadkeys]" 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 @@ localnet configuring -Part of the localnet script is setting up the system's -hostname. This needs to be configured in the +Part of the job of the localnet script is setting the +system's hostname. This needs to be configured in the /etc/sysconfig/network file. -Create the /etc/sysconfig/network file and enter a hostname by -running: +Create the /etc/sysconfig/network file and enter a +hostname by running: echo "HOSTNAME=[lfs]" > /etc/sysconfig/network -[lfs] 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 -/etc/hosts file later. +[lfs] 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 /etc/hosts file in the next +section. diff --git a/chapter07/network.xml b/chapter07/network.xml index 98bb8f7d7..cd99e47cd 100644 --- a/chapter07/network.xml +++ b/chapter07/network.xml @@ -47,16 +47,15 @@ PREFIX=24 BROADCAST=192.168.1.255 EOF -The values of these variables must be changed in every file to -match the proper setup. If the ONBOOT variable is -set to yes the network script will bring up the -Network Interface Card (NIC) during booting of the system. If set -to anything but yes the NIC will be ignored by the -network script and not brought up. +The values of these variables must be changed in every file to match the +proper setup. If the ONBOOT variable is set to yes +the network script will bring up the Network Interface Card (NIC) during booting +of the system. If set to anything but yes the NIC will be ignored +by the network script and not be brought up. -The SERVICE 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 The SERVICE 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 /etc/sysconfig/network-devices/services directory allows other IP assignment methods. This is commonly used for Dynamic Host Configuration Protocol (DHCP), which is addressed in the BLFS book. @@ -65,14 +64,14 @@ Configuration Protocol (DHCP), which is addressed in the BLFS book. the default gateway IP address, if one is present. If not, then comment out the variable entirely. -The PREFIX 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. +The PREFIX 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 PREFIX variable according to +your specific subnet. 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: The output of programs translated into the native language -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 +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 The correct alphabetical sorting order for the country Appropriate default paper size diff --git a/chapter07/setclock.xml b/chapter07/setclock.xml index a5a43f6a0..08c751cb4 100644 --- a/chapter07/setclock.xml +++ b/chapter07/setclock.xml @@ -11,28 +11,25 @@ setclock configuring -The setclock 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 /etc/localtime file -(which tells the hwclock 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. +The setclock 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 +/etc/localtime file (which tells the +hwclock 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. -If you cannot remember whether or not the hardware -clock is set to UTC time, find out by running -the hwclock --localtime --show 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 hwclock 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 -hwclock time. For example, if you live in the MST +If you cannot remember whether or not the hardware clock is set to UTC +time, find out by running the hwclock --localtime --show +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 hwclock 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 +hwclock. 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. +time. Change the value of the UTC variable below to a value of 0 (zero) if the hardware clock diff --git a/chapter07/udev.xml b/chapter07/udev.xml index 7b9be92ad..4ec10b504 100644 --- a/chapter07/udev.xml +++ b/chapter07/udev.xml @@ -12,25 +12,23 @@ usage In , 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. -Linux systems in general traditionally use a static device -creation method, whereby a great many device nodes are created under -/dev (sometimes literally -thousands of nodes), regardless of whether the corresponding hardware -devices actually exist. This is typically done via a -MAKEDEV script, which contains a number of -calls to the mknod 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 -tmpfs (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. +Linux systems in general traditionally use a static device creation +method, whereby a great many device nodes are created under /dev (sometimes literally thousands of nodes), +regardless of whether the corresponding hardware devices actually exist. This is +typically done via a MAKEDEV script, which contains a number +of calls to the mknod 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 tmpfs 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. History @@ -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. -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 sysfs came to be. -The job of sysfs 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 devfs became much more +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 sysfs came to be. The job of sysfs 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 +devfs became much more realistic. + Udev Implementation -The sysfs filesystem -was mentioned briefly above. One may wonder how sysfs 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 sysfs as they are -detected by the kernel. For drivers compiled as modules, this will -happen when the module is loaded. Once the sysfs filesystem is mounted (on -/sys), data which the +The sysfs filesystem was +mentioned briefly above. One may wonder how sysfs 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 sysfs as they are detected by the kernel. For +drivers compiled as modules, this registration will happen when the module is +loaded. Once the sysfs filesystem is +mounted (on /sys), data which the built-in drivers registered with sysfs are available to userspace -processes and to udev for device node creation. +class="filesystem">sysfs are available to userspace processes and +to udev for device node creation. The S10udev initscript takes care of creating these -device nodes when Linux is booted. This script starts with registering -/sbin/udevsend as a hotplug event handler. Hotplug events -(discussed below) should not be generated during this stage, but -udev is registered just in case they do occur. The +device nodes when Linux is booted. This script starts by registering +/sbin/udevsend as a hotplug event handler. Hotplug events +(discussed below) are not usually generated during this stage, but +udev is registered just in case they do occur. The udevstart program then walks through the /sys filesystem and creates devices under -/dev that match the descriptions. For +/dev that match the descriptions. For example, /sys/class/tty/vcs/dev contains the string 7:0 This string is used by udevstart to create /dev/vcs with major number 7 and minor -0. The names and permissions of the nodes created under +0. The names and permissions of the nodes created under the /dev directory are configured according to the rules specified in the files within the /etc/udev/rules.d/ directory. These are numbered in @@ -101,39 +98,34 @@ a similar fashion to the LFS-Bootscripts package. If udev can't find a rule for the device it is creating, it will default permissions to 660 and ownership to root:root. -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? +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. Earlier, we mentioned the concept of a hotplug event -handler. When a new device connection is detected by the -kernel, the kernel will generate a hotplug event and look at the file -/proc/sys/kernel/hotplug to find out the -userspace program that handles the device's connection. The -udev initscript registered udevsend -as this handler. When these hotplug events are generated, the kernel -will tell udev to check the /sys filesystem for the information +handler. When a new device connection is detected by the kernel, the +kernel will generate a hotplug event and look at the file +/proc/sys/kernel/hotplug to determine the userspace program +that handles the device's connection. The udev bootscript +registered udevsend as this handler. When these hotplug +events are generated, the kernel will tell udev to check the +/sys filesystem for the information pertaining to this new device and create the /dev entry for it. -This brings us to one problem that exists with -udev, and likewise with devfs before it. It is commonly -referred to as the chicken and egg problem. Most Linux -distributions handle loading modules via entries in -/etc/modules.conf. Access to a device node causes -the appropriate kernel module to load. With udev, -this method will not work because the device node does not exist until -the module is loaded. To solve this, the -S05modules bootscript was added to the +This brings us to one problem that exists with udev, +and likewise with devfs before it. +It is commonly referred to as the chicken and egg problem. Most +Linux distributions handle loading modules via entries in +/etc/modules.conf. Access to a device node causes the +appropriate kernel module to load. With udev, this method +will not work because the device node does not exist until the module is loaded. +To solve this, the S05modules bootscript was added to the LFS-Bootscripts package, along with the -/etc/sysconfig/modules file. By -adding module -names to the modules file, these modules will be -loaded when the computer is starting up. This allows -udev to detect the devices and create the -appropriate device nodes. +/etc/sysconfig/modules file. By adding module names to the +modules file, these modules will be loaded when the +computer is starts up. This allows udev to detect the devices +and create the appropriate device nodes. 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: 1) A kernel driver may not export its data to sysfs. -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 -/etc/sysconfig/createfiles configuration file to -manually create the devices. Consult the -devices.txt file inside the kernel documentation -or the documentation for that driver to find the proper major/minor -numbers. +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 /etc/sysconfig/createfiles configuration file to +manually create the devices. Consult the devices.txt file +inside the kernel documentation or the documentation for that driver to find the +proper major/minor numbers. 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 @@ Bootscripts usage -Linux uses a special booting facility named SysVinit that is -based on a concept of run-levels. 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. +Linux uses a special booting facility named SysVinit that is based on a +concept of run-levels. 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. -SysVinit (which will be referred to as init 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: +SysVinit (which will be referred to as init 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: 0: halt the computer 1: single-user mode @@ -37,24 +35,23 @@ as they are implemented: The command used to change run-levels is init [runlevel], where -[runlevel] is the target run-level. For -example, to reboot the computer, a user would issue the init -6 command. The reboot command is an -alias for it, as is the halt command an alias for -init 0. +[runlevel] is the target run-level. For example, to +reboot the computer, a user could issue the init 6 command, +which is an alias for the reboot command. Likewise, +init 0 is an alias for the halt +command. There are a number of directories under /etc/rc.d that look like rc?.d (where ? is the number of the -run-level) and rcsysinit.d, all -containing a number of symbolic links. Some begin with a -K, the others begin with an -S, 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. +class="directory">rc?.d (where ? is the number of the run-level) and +rcsysinit.d, all containing a number of +symbolic links. Some begin with a K, the others begin with +an S, 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 +are either started or stopped, depending on the runlevel chosen. The real scripts are in /etc/rc.d/init.d. They do the actual diff --git a/general.ent b/general.ent index 22ee2aef4..1722771d9 100644 --- a/general.ent +++ b/general.ent @@ -1,6 +1,6 @@ - - + +