diff --git a/chapter07/bootscripts.xml b/chapter07/bootscripts.xml index 7c1004a0f..775215e7e 100644 --- a/chapter07/bootscripts.xml +++ b/chapter07/bootscripts.xml @@ -1,239 +1,302 @@ - %general-entities; ]> + -LFS-Bootscripts-&lfs-bootscripts-version; - + -Bootscripts + LFS-Bootscripts-&lfs-bootscripts-version; - -<para>The LFS-Bootscripts package contains a set of scripts to start/stop the -LFS system at bootup/shutdown.</para> + <indexterm zone="ch-scripts-bootscripts"> + <primary sortas="a-Bootscripts">Bootscripts</primary> + </indexterm> -<segmentedlist> -<segtitle>&buildtime;</segtitle> -<segtitle>&diskspace;</segtitle> -<seglistitem><seg>0.1 SBU</seg><seg>516 KB</seg></seglistitem> -</segmentedlist> + <sect2 role="package"> + <title/> -<segmentedlist> -<segtitle>&dependencies;</segtitle> -<seglistitem><seg>Bash and Coreutils</seg></seglistitem> -</segmentedlist> -</sect2> + <para>The LFS-Bootscripts package contains a set of scripts to start/stop the + LFS system at bootup/shutdown.</para> -<sect2 role="installation"> -<title>Installation of LFS-Bootscripts + + &buildtime; + &diskspace; -Install the package: + + 0.1 SBU + 516 KB + + + + + &dependencies; + + + Bash and Coreutils + + + + + + + Installation of LFS-Bootscripts + + Install the package: make install - + -Contents of LFS-Bootscripts + + Contents of LFS-Bootscripts - -Installed scripts -checkfs, cleanfs, console, functions, halt, hotplug, ifdown, ifup, -localnet, mountfs, mountkernfs, network, rc, reboot, sendsignals, setclock, static, -swap, sysklogd, template, and udev - + + Installed scripts -Short Descriptions - - + + checkfs, cleanfs, console, functions, halt, hotplug, ifdown, ifup, + localnet, mountfs, mountkernfs, network, rc, reboot, sendsignals, + setclock, static, swap, sysklogd, template, and udev + + - -checkfs - -Checks the integrity of the file systems before they are mounted (with the -exception of journal and network based file systems) -checkfs - - + + Short Descriptions + + - -cleanfs - -Removes files that should not be -preserved between reboots, such as those in /var/run/ and -/var/lock/; it re-creates /var/run/utmp -and removes the possibly present /etc/nologin, -/fastboot, and /forcefsck files -cleanfs - - + + checkfs + + Checks the integrity of the file systems before they are mounted + (with the exception of journal and network based file systems) + + checkfs + + + - -console - -Loads the correct keymap table for the desired keyboard layout; it also -sets the screen font -console - - + + cleanfs + + Removes files that should not be preserved between reboots, such + as those in /var/run/ and + /var/lock/; it re-creates + /var/run/utmp and removes the possibly present + /etc/nologin, /fastboot, and + /forcefsck files + + cleanfs + + + - -functions - -Contains common functions, such as error and status checking, that are -used by several bootscripts -functions - - + + console + + Loads the correct keymap table for the desired keyboard layout; + it also sets the screen font + + console + + + - -halt - -Halts the system -halt - - + + functions + + Contains common functions, such as error and status checking, + that are used by several bootscripts + + functions + + + - -hotplug - -Loads modules for system devices -hotplug - - + + halt + + Halts the system + + halt + + + - -ifdown - -Assists the network script with stopping network devices -ifdown - - + + hotplug + + Loads modules for system devices + + hotplug + + + - -ifup - -Assists the network script with starting network devices -ifup - - + + ifdown + + Assists the network script with stopping network devices + + ifdown + + + - -localnet - -Sets up the system's hostname and local loopback device -localnet - - + + ifup + + Assists the network script with starting network devices + + ifup + + + - -mountfs - -Mounts all file systems, except ones that are marked -noauto or are network based -mountfs - - + + localnet + + Sets up the system's hostname and local loopback device + + localnet + + + - -mountkernfs - -Mounts virtual kernel file systems, such as proc -mountkernfs - - + + mountfs + + Mounts all file systems, except ones that are marked + noauto or are network based + + mountfs + + + - -network - -Sets up network interfaces, such as network cards, and sets up -the default gateway (where applicable) -network - - + + mountkernfs + + Mounts virtual kernel file systems, such as proc + + mountkernfs + + + - -rc - -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 - - + + network + + Sets up network interfaces, such as network cards, and sets up + the default gateway (where applicable) + + network + + + - -reboot - -Reboots the system -reboot - - + + rc + + 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 + + + - -sendsignals - -Makes sure every process is terminated before the system reboots -or halts -sendsignals - - + + reboot + + Reboots the system + + reboot + + + - -setclock - -Resets the kernel clock to local time in case the hardware clock -is not set to UTC time -setclock - - + + sendsignals + + Makes sure every process is terminated before the system reboots + or halts + + sendsignals + + + - -static - -Provides the functionality needed to assign a static Internet -Protocol (IP) address to a network interface -static - - + + setclock + + Resets the kernel clock to local time in case the hardware clock + is not set to UTC time + + setclock + + + - -swap - -Enables and disables swap files and partitions -swap - - + + static + + Provides the functionality needed to assign a static Internet + Protocol (IP) address to a network interface + + static + + + - -sysklogd - -Starts and stops the system and kernel log daemons -sysklogd - - + + swap + + Enables and disables swap files and partitions + + swap + + + - -template - -A template to create custom bootscripts for other -daemons -template - - + + sysklogd + + Starts and stops the system and kernel log daemons + + sysklogd + + + - -udev - -Prepares the /dev directory and -starts Udev -udev - - - + + template + + A template to create custom bootscripts for other + daemons + + template + + + - + + udev + + Prepares the /dev + directory and starts Udev + + udev + + + + + + + - diff --git a/chapter07/chapter07.xml b/chapter07/chapter07.xml index 51219b045..c47adeb08 100644 --- a/chapter07/chapter07.xml +++ b/chapter07/chapter07.xml @@ -1,24 +1,27 @@ - %general-entities; ]> - - -Setting Up System Bootscripts - - - - - - - - - - - - - + + + + + Setting Up System Bootscripts + + + + + + + + + + + + + diff --git a/chapter07/console.xml b/chapter07/console.xml index 9da42a23c..315112366 100644 --- a/chapter07/console.xml +++ b/chapter07/console.xml @@ -1,70 +1,76 @@ - %general-entities; ]> + -Configuring the Linux Console - + - -console -configuring + Configuring the Linux Console -This section discusses how to configure the console -bootscript that sets up the keyboard map and the console font. If non-ASCII -characters (e.g., the British pound sign and Euro character) 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. + + console + configuring + -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 loadkeys(1) and -setfont(8) to determine the correct arguments for -these programs. Once decided, create the configuration file with the following -command: + This section discusses how to configure the console + bootscript that sets up the keyboard map and the console font. If non-ASCII + characters (e.g., the British pound sign and Euro character) 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 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 loadkeys(1) and + setfont(8) to 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]" FONT="[arguments for setfont]" EOF -For example, for Spanish users who also want to use the Euro -character (accessible by pressing AltGr+E), the following settings are -correct: + For example, for Spanish users who also want to use the Euro + character (accessible by pressing AltGr+E), the following settings are + correct: cat >/etc/sysconfig/console <<"EOF" KEYMAP="es euro2" FONT="lat9-16 -u iso01" EOF -The FONT line above is correct only for the ISO 8859-15 -character set. If using ISO 8859-1 and, therefore, a pound sign -instead of Euro, the correct FONT line would be: + + The FONT line above is correct only for the ISO 8859-15 + character set. If using ISO 8859-1 and, therefore, a pound sign + instead of Euro, the correct FONT line would be: -FONT="lat1-16" +FONT="lat1-16" + -If the KEYMAP or FONT variable is not set, the -console initscript will not run the corresponding -program. + If the KEYMAP or FONT variable is not set, + the console initscript will not run the corresponding + program. -In some keymaps, the Backspace and Delete keys send characters different -from ones in the default keymap built into the kernel. This confuses some -applications. For example, Emacs displays its help (instead of erasing the -character before the cursor) when Backspace is pressed. To check if the keymap -in use is affected (this works only for i386 keymaps): + In some keymaps, the Backspace and Delete keys send characters different + from ones in the default keymap built into the kernel. This confuses some + applications. For example, Emacs displays its help (instead of erasing the + character before the cursor) when Backspace is pressed. To check if the keymap + in use is affected (this works only for i386 keymaps): zgrep '\W14\W' [/path/to/your/keymap] -If the keycode 14 is Backspace instead of Delete, create the -following keymap snippet to fix this issue: + If the keycode 14 is Backspace instead of Delete, create the + following keymap snippet to fix this issue: mkdir -pv /etc/kbd && cat > /etc/kbd/bs-sends-del <<"EOF" keycode 14 = Delete Delete Delete Delete @@ -76,32 +82,31 @@ following keymap snippet to fix this issue: altgr control alt keycode 111 = Boot EOF -Tell the console script to load this -snippet after the main keymap: + Tell the console script to load this + snippet after the main keymap: cat >>/etc/sysconfig/console <<"EOF" KEYMAP_CORRECTIONS="/etc/kbd/bs-sends-del" EOF -To compile the keymap directly into the kernel instead of -setting it every time from the console bootscript, -follow the instructions given in -Doing this ensures that the keyboard will always work as expected, -even when booting into maintenance mode (by passing -init=/bin/sh to the kernel), because the -console bootscript will not be run in that -situation. Additionally, the kernel will not set the screen font -automatically. This should not pose many problems because ASCII characters -will be handled correctly, and it is unlikely that a user would need -to rely on non-ASCII characters while in maintenance mode. + To compile the keymap directly into the kernel instead of + setting it every time from the console bootscript, + follow the instructions given in + Doing this ensures that the keyboard will always work as expected, + even when booting into maintenance mode (by passing + init=/bin/sh to the kernel), because the + console bootscript will not be run in that + situation. Additionally, the kernel will not set the screen font + automatically. This should not pose many problems because ASCII characters + will be handled correctly, and it is unlikely that a user would need + to rely on non-ASCII characters while in maintenance mode. -Since the kernel will set up the keymap, it is possible to omit -the KEYMAP variable from the -/etc/sysconfig/console configuration file. It can -also be left in place, if desired, without consequence. Keeping it -could be beneficial if running several different kernels where it is -difficult to ensure that the keymap is compiled into every one of -them. + Since the kernel will set up the keymap, it is possible to omit + the KEYMAP variable from the + /etc/sysconfig/console configuration file. It can + also be left in place, if desired, without consequence. Keeping it + could be beneficial if running several different kernels where it is + difficult to ensure that the keymap is compiled into every one of + them. - diff --git a/chapter07/hostname.xml b/chapter07/hostname.xml index 0d89e785f..7515d6a03 100644 --- a/chapter07/hostname.xml +++ b/chapter07/hostname.xml @@ -1,29 +1,32 @@ - %general-entities; ]> + -Configuring the localnet Script - + - -localnet -configuring + Configuring the localnet Script -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. + + localnet + configuring + -Create the /etc/sysconfig/network file and enter a -hostname by running: + 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: echo "HOSTNAME=[lfs]" > /etc/sysconfig/network -[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. + [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/hosts.xml b/chapter07/hosts.xml index f08dfab4e..6e6549913 100644 --- a/chapter07/hosts.xml +++ b/chapter07/hosts.xml @@ -1,48 +1,53 @@ - %general-entities; ]> + -Creating the /etc/hosts File - + -/etc/hosts + Creating the /etc/hosts File - -localnet -/etc/hosts + + /etc/hosts + - -network -/etc/hosts + + localnet + /etc/hosts -If a network card is to be configured, decide on the IP address, -FQDN, and possible aliases for use in the -/etc/hosts file. The syntax is: + + network + /etc/hosts -<IP address> myhost.example.org aliases + If a network card is to be configured, decide on the IP address, + FQDN, and possible aliases for use in the + /etc/hosts file. The syntax is: -Unless the computer is to be visible to the Internet (i.e., -there is a registered domain and a valid block of assigned IP -addresses—most users do not have this), make sure that the IP -address is in the private network IP address range. Valid ranges -are: +<IP address> myhost.example.org aliases - Class Networks + Unless the computer is to be visible to the Internet (i.e., + there is a registered domain and a valid block of assigned IP + addresses—most users do not have this), make sure that the IP + address is in the private network IP address range. Valid ranges + are: + + Class Networks A 10.0.0.0 B 172.16.0.0 through 172.31.0.255 - C 192.168.0.0 through 192.168.255.255 + C 192.168.0.0 through 192.168.255.255 -A valid IP address could be 192.168.1.1. A valid FQDN for this -IP could be www.linuxfromscratch.org (not recommended because this is -a valid registered domain address and could cause domain name server -issues). + A valid IP address could be 192.168.1.1. A valid FQDN for this + IP could be www.linuxfromscratch.org (not recommended because this is + a valid registered domain address and could cause domain name server + issues). -Even if not using a network card, an FQDN is still required. -This is necessary for certain programs to operate correctly. + Even if not using a network card, an FQDN is still required. + This is necessary for certain programs to operate correctly. -Create the /etc/hosts file by running: + Create the /etc/hosts file by running: cat > /etc/hosts << "EOF" # Begin /etc/hosts (network card version) @@ -53,14 +58,14 @@ This is necessary for certain programs to operate correctly. # End /etc/hosts (network card version) EOF -The [192.168.1.1] and -[<HOSTNAME>.example.org] -values need to be changed for specific users or requirements (if -assigned an IP address by a network/system administrator and the -machine will be connected to an existing network). + The [192.168.1.1] and + [<HOSTNAME>.example.org] + values need to be changed for specific users or requirements (if + assigned an IP address by a network/system administrator and the + machine will be connected to an existing network). -If a network card is not going to be configured, create the -/etc/hosts file by running: + If a network card is not going to be configured, create the + /etc/hosts file by running: cat > /etc/hosts << "EOF" # Begin /etc/hosts (no network card version) @@ -71,4 +76,3 @@ machine will be connected to an existing network). EOF - diff --git a/chapter07/inputrc.xml b/chapter07/inputrc.xml index 61418c129..5c5ce2278 100644 --- a/chapter07/inputrc.xml +++ b/chapter07/inputrc.xml @@ -1,31 +1,37 @@ - %general-entities; ]> + -Creating the /etc/inputrc File - + -/etc/inputrc + Creating the /etc/inputrc File -The inputrc file handles keyboard mapping for -specific situations. This file is the startup file used by Readline — the -input-related library — used by Bash and most other shells. + + /etc/inputrc + -Most people do not need user-specific keyboard mappings so the command -below creates a global /etc/inputrc used by everyone who -logs in. If you later decide you need to override the defaults on a per-user -basis, you can create a .inputrc file in the user's home -directory with the modified mappings. + The inputrc file handles keyboard mapping for + specific situations. This file is the startup file used by Readline — the + input-related library — used by Bash and most other shells. -For more information on how to edit the inputrc file, -see info bash under the Readline Init File -section. info readline is also a good source of information. + Most people do not need user-specific keyboard mappings so the command + below creates a global /etc/inputrc used by everyone who + logs in. If you later decide you need to override the defaults on a per-user + basis, you can create a .inputrc file in the user's home + directory with the modified mappings. -Below is a generic global inputrc along with comments -to explain what the various options do. Note that comments cannot be on the same -line as commands. Create the file using the following command: + For more information on how to edit the inputrc + file, see info bash under the Readline Init + File section. info readline is also a good + source of information. + + Below is a generic global inputrc along with comments + to explain what the various options do. Note that comments cannot be on the same + line as commands. Create the file using the following command: cat > /etc/inputrc << "EOF" # Begin /etc/inputrc @@ -74,4 +80,3 @@ set bell-style none EOF - diff --git a/chapter07/introduction.xml b/chapter07/introduction.xml index 37ab2f626..a7b846ee7 100644 --- a/chapter07/introduction.xml +++ b/chapter07/introduction.xml @@ -1,27 +1,28 @@ - %general-entities; ]> + -Introduction - + -This chapter details how to install and configure the LFS-Bootscripts -package. Most of these scripts will work without modification, but a few require -additional configuration files because they deal with hardware-dependent -information. + Introduction -System-V style init scripts are employed in this book because they are -widely used. For additional options, a hint detailing the BSD style -init setup is available at -. -Searching the LFS mailing lists for depinit will also offer -additional choices. + This chapter details how to install and configure the LFS-Bootscripts + package. Most of these scripts will work without modification, but a few require + additional configuration files because they deal with hardware-dependent + information. -If using an alternative style of init scripts, skip this chapter -and move on to . + System-V style init scripts are employed in this book because they are + widely used. For additional options, a hint detailing the BSD style init setup + is available at . + Searching the LFS mailing lists for depinit will also offer + additional choices. + + If using an alternative style of init scripts, skip this chapter + and move on to . - diff --git a/chapter07/network.xml b/chapter07/network.xml index 229f6d394..c09f92431 100644 --- a/chapter07/network.xml +++ b/chapter07/network.xml @@ -1,40 +1,42 @@ - %general-entities; ]> + -Configuring the network Script - + - -network -configuring + Configuring the network Script -This section only applies if a network card is to be -configured. + + network + configuring -If a network card will not be used, there is likely no need to -create any configuration files relating to network cards. If that is -the case, remove the network -symlinks from all run-level directories (/etc/rc.d/rc*.d). + This section only applies if a network card is to be + configured. - -Creating Network Interface Configuration Files + If a network card will not be used, there is likely no need to + create any configuration files relating to network cards. If that is + the case, remove the network + symlinks from all run-level directories (/etc/rc.d/rc*.d). - -Which interfaces are brought up and down by the network script -depends on the files and directories in the /etc/sysconfig/network-devices hierarchy. -This directory should contain a sub-directory for each interface to be configured, -such as ifconfig.xyz, where xyz is a -network interface name. Inside this directory would be files defining -the attributes to this interface, such as its IP address(es), subnet -masks, and so forth. + + Creating Network Interface Configuration Files -The following command creates a sample ipv4 file for -the eth0 device: + Which interfaces are brought up and down by the network script + depends on the files and directories in the /etc/sysconfig/network-devices hierarchy. + This directory should contain a sub-directory for each interface to be + configured, such as ifconfig.xyz, where + xyz is a network interface name. Inside this directory + would be files defining the attributes to this interface, such as its IP + address(es), subnet masks, and so forth. + + The following command creates a sample ipv4 + file for the eth0 device: cd /etc/sysconfig/network-devices && mkdir -v ifconfig.eth0 && @@ -47,45 +49,50 @@ 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 be 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 used for 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. + The SERVICE variable defines the method used for + 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. -The GATEWAY variable should contain -the default gateway IP address, if one is present. If not, then comment out -the variable entirely. + The GATEWAY variable should contain 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 the PREFIX variable according to -your 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. - + - -Creating the /etc/resolv.conf File -/etc/resolv.conf + + Creating the /etc/resolv.conf File -If the system is going to be connected to the Internet, it will -need some means of Domain Name Service (DNS) name resolution to -resolve Internet domain names to IP addresses, and vice versa. This is -best achieved by placing the IP address of the DNS server, available -from the ISP or network administrator, into -/etc/resolv.conf. Create the file by running the -following: + + /etc/resolv.conf + + + If the system is going to be connected to the Internet, it will + need some means of Domain Name Service (DNS) name resolution to + resolve Internet domain names to IP addresses, and vice versa. This is + best achieved by placing the IP address of the DNS server, available + from the ISP or network administrator, into + /etc/resolv.conf. Create the file by running the + following: cat > /etc/resolv.conf << "EOF" # Begin /etc/resolv.conf @@ -97,14 +104,13 @@ nameserver [IP address of your secondary nameserver] # End /etc/resolv.conf EOF -Replace [IP address of the -nameserver] with the IP address of the DNS most -appropriate for the setup. There will often be more than one entry -(requirements demand secondary servers for fallback capability). If -you only need or want one DNS server, remove the second -nameserver line from the file. The IP address may -also be a router on the local network. - + Replace [IP address of the nameserver] + with the IP address of the DNS most appropriate for the setup. There will + often be more than one entry (requirements demand secondary servers for + fallback capability). If you only need or want one DNS server, remove the + second nameserver line from the file. The IP address + may also be a router on the local network. + + - diff --git a/chapter07/profile.xml b/chapter07/profile.xml index c00bdd130..dd53a5141 100644 --- a/chapter07/profile.xml +++ b/chapter07/profile.xml @@ -1,91 +1,99 @@ - %general-entities; ]> + -The Bash Shell Startup Files - + -/etc/profile + The Bash Shell Startup Files -The shell program /bin/bash (hereafter -referred to as the shell) uses a collection of startup -files to help create an environment to run in. Each file has a -specific use and may affect login and interactive environments -differently. The files in the /etc directory provide global settings. -If an equivalent file exists in the home directory, it may override -the global settings. + + /etc/profile + -An interactive login shell is started after a successful login, -using /bin/login, by reading the -/etc/passwd file. An interactive non-login shell -is started at the command-line (e.g., -[prompt]$/bin/bash). A -non-interactive shell is usually present when a shell script is -running. It is non-interactive because it is processing a script and -not waiting for user input between commands. + The shell program /bin/bash (hereafter referred to + as the shell) uses a collection of startup files to help + create an environment to run in. Each file has a specific use and may affect + login and interactive environments differently. The files in the /etc directory provide global settings. If an + equivalent file exists in the home directory, it may override the global + settings. -For more information, see info bash under the -Bash Startup Files and Interactive Shells section. + An interactive login shell is started after a successful login, using + /bin/login, by reading the /etc/passwd + file. An interactive non-login shell is started at the command-line (e.g., + [prompt]$/bin/bash). A non-interactive + shell is usually present when a shell script is running. It is non-interactive + because it is processing a script and not waiting for user input between + commands. -The files /etc/profile and -~/.bash_profile are read when the shell is -invoked as an interactive login shell. + For more information, see info bash under the + Bash Startup Files and Interactive Shells section. -The base /etc/profile below sets some -environment variables necessary for native language support. Setting -them properly results in: + The files /etc/profile and + ~/.bash_profile are read when the shell is + invoked as an interactive login shell. - -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 -The correct alphabetical sorting order for the -country -Appropriate default paper size -Correct formatting of monetary, time, and date -values - + The base /etc/profile below sets some + environment variables necessary for native language support. Setting + them properly results in: -This script also sets the INPUTRC environment variable that -makes Bash and Readline use the /etc/inputrc file created -earlier. + + + 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 + + + The correct alphabetical sorting order for the country + + + Appropriate default paper size + + + Correct formatting of monetary, time, and date values + + -Replace [ll] below with the -two-letter code for the desired language (e.g., en) and -[CC] with the two-letter code for the -appropriate country (e.g., GB). -[charmap] should be replaced with the -canonical charmap for your chosen locale. + This script also sets the INPUTRC environment variable that + makes Bash and Readline use the /etc/inputrc file created + earlier. -The list of all locales supported by Glibc can be obtained by running -the following command: + Replace [ll] below with the two-letter code + for the desired language (e.g., en) and + [CC] with the two-letter code for the appropriate + country (e.g., GB). [charmap] should + be replaced with the canonical charmap for your chosen locale. + + The list of all locales supported by Glibc can be obtained by running + the following command: locale -a -Locales can have a number of synonyms, e.g. ISO-8859-1 is -also referred to as iso8859-1 and iso88591. -Some applications cannot handle the various synonyms correctly, so it is safest -to choose the canonical name for a particular locale. To determine the -canonical name, run the following command, where -[locale name] is the output given by -locale -a for your preferred locale -(en_GB.iso88591 in our example). + Locales can have a number of synonyms, e.g. ISO-8859-1 + is also referred to as iso8859-1 and iso88591. + Some applications cannot handle the various synonyms correctly, so it is + safest to choose the canonical name for a particular locale. To determine + the canonical name, run the following command, where [locale + name] is the output given by locale -a for + your preferred locale (en_GB.iso88591 in our example). LC_ALL=[locale name] locale charmap -For the en_GB.iso88591 locale, the above command -will print: + For the en_GB.iso88591 locale, the above command + will print: -ISO-8859-1 +ISO-8859-1 -This results in a final locale setting of en_GB.ISO-8859-1. -It is important that the locale found using the heuristic above is tested prior -to it being added to the Bash startup files: + This results in a final locale setting of en_GB.ISO-8859-1. + It is important that the locale found using the heuristic above is tested prior + to it being added to the Bash startup files: LC_ALL=[locale name] locale country LC_ALL=[locale name] locale language @@ -93,39 +101,40 @@ LC_ALL=[locale name] locale charmap LC_ALL=[locale name] locale int_curr_symbol LC_ALL=[locale name] locale int_prefix -The above commands should print the country and language names, the -character encoding used by the locale, the local currency and the prefix to dial -before the telephone number in order to get into the country. If any of the -commands above fail with a message similar to the one shown below, this means -that your locale was either not installed in Chapter 6 or is not supported by -the default installation of Glibc. + The above commands should print the country and language names, the + character encoding used by the locale, the local currency and the prefix to dial + before the telephone number in order to get into the country. If any of the + commands above fail with a message similar to the one shown below, this means + that your locale was either not installed in Chapter 6 or is not supported by + the default installation of Glibc. locale: Cannot set LC_* to default locale: No such file or directory -If this happens, you should either install the desired locale using the localedef command, or consider choosing a different locale. -Further instructions assume that there are no such error messages from Glibc. - + If this happens, you should either install the desired locale using the + localedef command, or consider choosing a different locale. + Further instructions assume that there are no such error messages from + Glibc. -Some packages beyond LFS may also lack support for your chosen locale. One -example is the X library (part of the X Window System), which outputs the -following error message: + Some packages beyond LFS may also lack support for your chosen locale. One + example is the X library (part of the X Window System), which outputs the + following error message: Warning: locale not supported by Xlib, locale set to C -Sometimes it is possible to fix this by removing the charmap part of the -locale specification, as long as that does not change the character map that -Glibc associates with the locale (this can be checked by running the -locale charmap command in both locales). For example, one -would have to change "de_DE.ISO-8859-15@euro" to -"de_DE@euro" in order to get this locale recognized by Xlib. + Sometimes it is possible to fix this by removing the charmap part of the + locale specification, as long as that does not change the character map that + Glibc associates with the locale (this can be checked by running the + locale charmap command in both locales). For example, one + would have to change "de_DE.ISO-8859-15@euro" to + "de_DE@euro" in order to get this locale recognized by Xlib. -Other packages can also function incorrectly (but may not necessarily -display any error messages) if the locale name does not meet their expectations. -In those cases, investigating how other Linux distributions support your locale -might provide some useful information. + Other packages can also function incorrectly (but may not necessarily + display any error messages) if the locale name does not meet their expectations. + In those cases, investigating how other Linux distributions support your locale + might provide some useful information. -Once the proper locale settings have been determined, create the -/etc/profile file: + Once the proper locale settings have been determined, create the + /etc/profile file: cat > /etc/profile << "EOF" # Begin /etc/profile @@ -136,18 +145,17 @@ export INPUTRC=/etc/inputrc # End /etc/profile EOF -The C (default) and en_US -(the recommended one for United States English users) locales are -different. + + The C (default) and en_US (the + recommended one for United States English users) locales are different. + -Setting the keyboard layout, screen font, and -locale-related environment variables are the only internationalization -steps needed to support locales that use ordinary single-byte -encodings and left-to-right writing direction. More complex cases -(including UTF-8 based locales) require additional steps and -additional patches because many applications tend to not work properly -under such conditions. These steps and patches are not included in -the LFS book and such locales are not yet supported by LFS. + Setting the keyboard layout, screen font, and locale-related environment + variables are the only internationalization steps needed to support locales + that use ordinary single-byte encodings and left-to-right writing direction. + More complex cases (including UTF-8 based locales) require additional steps + and additional patches because many applications tend to not work properly + under such conditions. These steps and patches are not included in the LFS + book and such locales are not yet supported by LFS. - diff --git a/chapter07/setclock.xml b/chapter07/setclock.xml index 772f2d3d3..2098fd74d 100644 --- a/chapter07/setclock.xml +++ b/chapter07/setclock.xml @@ -1,42 +1,45 @@ - %general-entities; ]> + -Configuring the setclock Script - + - -setclock -configuring + Configuring the setclock Script -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, so this -needs to be configured manually. + + setclock + configuring -If you cannot remember whether or not the hardware clock is set to UTC, -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. + 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, so this + needs to be configured manually. -Change the value of the UTC variable below -to a value of 0 (zero) if the hardware clock -is not set to UTC time. + If you cannot remember whether or not the hardware clock is set to UTC, + 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. -Create a new file /etc/sysconfig/clock by running -the following: + Change the value of the UTC variable below + to a value of 0 (zero) if the hardware clock + is not set to UTC time. + + Create a new file /etc/sysconfig/clock by running + the following: cat > /etc/sysconfig/clock << "EOF" # Begin /etc/sysconfig/clock @@ -46,9 +49,8 @@ UTC=1 # End /etc/sysconfig/clock EOF -A good hint explaining how to deal with time on LFS is available -at . It explains issues such as -time zones, UTC, and the TZ environment variable. + A good hint explaining how to deal with time on LFS is available + at . It explains issues such as + time zones, UTC, and the TZ environment variable. - diff --git a/chapter07/sysklogd.xml b/chapter07/sysklogd.xml index 70816cc66..b31420130 100644 --- a/chapter07/sysklogd.xml +++ b/chapter07/sysklogd.xml @@ -1,22 +1,26 @@ - %general-entities; ]> + -Configuring the sysklogd script - + - -sysklogd -configuring + Configuring the sysklogd script -The sysklogd script invokes the -syslogd program with the -m 0 option. -This option turns off the periodic timestamp mark that -syslogd writes to the log files every 20 minutes by default. -If you want to turn on this periodic timestamp mark, edit the -sysklogd script and make the changes accordingly. See -man syslogd for more information. + + sysklogd + configuring + + + The sysklogd script invokes the + syslogd program with the -m 0 option. + This option turns off the periodic timestamp mark that + syslogd writes to the log files every 20 minutes by default. + If you want to turn on this periodic timestamp mark, edit the + sysklogd script and make the changes accordingly. See + man syslogd for more information. diff --git a/chapter07/udev.xml b/chapter07/udev.xml index 64b3a43c7..5f98e6139 100644 --- a/chapter07/udev.xml +++ b/chapter07/udev.xml @@ -1,213 +1,237 @@ - %general-entities; ]> + -Device and Module Handling on an LFS System - + - -Udev -usage + Device and Module Handling on an LFS System -In , we installed the Udev -package. Before we go into the details regarding how this works, -a brief history of previous methods of handling devices is in -order. + + Udev + usage + -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. + In , we installed the Udev + package. Before we go into the details regarding how this works, + a brief history of previous methods of handling devices is in + order. - -History + 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. -In February 2000, a new filesystem called devfs was merged into the 2.3.46 -kernel and was made available during the 2.4 series of -stable kernels. Although it was present in the kernel source itself, -this method of creating devices dynamically never received -overwhelming support from the core kernel developers. + + History -The main problem with the approach adopted by devfs 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 devfs file system also suffers from race -conditions that are inherent in its design and cannot be fixed -without a substantial revision to the kernel. It has also been marked -as deprecated due to a lack of recent maintenance. + In February 2000, a new filesystem called devfs was merged into the 2.3.46 kernel + and was made available during the 2.4 series of stable kernels. Although + it was present in the kernel source itself, this method of creating devices + dynamically never received overwhelming support from the core kernel + developers. -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. + The main problem with the approach adopted by devfs 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 devfs + file system also suffers from race conditions that are inherent in its design + and cannot be fixed without a substantial revision to the kernel. It has also + been marked as deprecated due to a lack of recent maintenance. - + 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 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. + + Udev Implementation -The S10udev initscript takes care of creating these -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 -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 -the /dev directory are configured -according to the rules specified in the files within the /etc/udev/rules.d/ directory. These are numbered in -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. + 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. -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. + The S10udev initscript takes care of creating + these 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 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 the /dev directory are configured according to the + rules specified in the files within the /etc/udev/rules.d/ directory. These are + numbered in 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. -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 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. + 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. -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 starts up. This allows udev to detect the devices -and create the appropriate device nodes. + 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 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. -Note that on slower machines or for drivers that create a lot -of device nodes, the process of creating devices may take a few -seconds to complete. This means that some device nodes may not be -immediately accessible. - + 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 starts up. This allows udev to detect the devices + and create the appropriate device nodes. - -Handling Hotpluggable/Dynamic Devices + Note that on slower machines or for drivers that create a lot of device + nodes, the process of creating devices may take a few seconds to complete. + This means that some device nodes may not be immediately accessible. -When you plug in a device, such as a Universal Serial Bus (USB) MP3 player, the kernel -recognizes that the device is now connected and generates a hotplug -event. If the driver is already loaded (either because it was compiled -into the kernel or because it was loaded via the -S05modules bootscript), udev will -be called upon to create the relevant device node(s) according to the -sysfs data available in -/sys. + -If the driver for the just plugged in device is available as a module but -currently unloaded, the Hotplug package will load the appropriate module -and make this device available by creating the device node(s) for it. - + + Handling Hotpluggable/Dynamic Devices - -Problems with Creating Devices + When you plug in a device, such as a Universal Serial Bus (USB) MP3 + player, the kernel recognizes that the device is now connected and generates + a hotplug event. If the driver is already loaded (either because it was + compiled into the kernel or because it was loaded via the + S05modules bootscript), udev will be + called upon to create the relevant device node(s) according to the + sysfs data available in + /sys. -There are a few known problems when it comes to automatically creating -device nodes: + If the driver for the just plugged in device is available as a module but + currently unloaded, the Hotplug package will load the appropriate module + and make this device available by creating the device node(s) for it. -1) A kernel driver may not export its data to sysfs. - -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 -System (OSS) compatibility module. These types of devices can be -handled in one of two ways: + + Problems with Creating Devices - + There are a few known problems when it comes to automatically creating + device nodes: -Adding the module names to -/etc/sysconfig/modules -Using an -install line in -/etc/modprobe.conf. This tells the -modprobe command when loading this module, -also load this other module, at the same time. For example: + 1) A kernel driver may not export its data to sysfs. + + 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 + System (OSS) compatibility module. These types of devices can be + handled in one of two ways: + + + + + Adding the module names to + /etc/sysconfig/modules + + + + Using an install line in + /etc/modprobe.conf. This tells the + modprobe command when loading this module, + also load this other module, at the same time. + For example: install snd-pcm modprobe -i snd-pcm ; modprobe \ snd-pcm-oss ; true -This will cause the system to load both the -snd-pcm and snd-pcm-oss -modules when any request is made to load the driver -snd-pcm. - - + This will cause the system to load both the + snd-pcm and snd-pcm-oss + modules when any request is made to load the driver + snd-pcm. + - -Useful Reading + -Additional helpful documentation is available at the following -sites: + - -A Userspace Implementation of devfs - + + Useful Reading -udev FAQ - + Additional helpful documentation is available at the following + sites: -The Linux Kernel Driver Model - - - + + + + A Userspace Implementation of devfs + + + + + udev FAQ + + + + + The Linux Kernel Driver Model + + + + + + - diff --git a/chapter07/usage.xml b/chapter07/usage.xml index 4ff169ee8..991cf55dc 100644 --- a/chapter07/usage.xml +++ b/chapter07/usage.xml @@ -1,29 +1,33 @@ - %general-entities; ]> + -How Do These Bootscripts Work? - + - -Bootscripts -usage + How Do These Bootscripts Work? -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. + + Bootscripts + usage + -SysVinit (which will be referred to as init 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 init(8) 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: + 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 (numbered 0 to 6) run-levels + (actually, there are more run-levels, but they are for special cases and are + generally not used. See init(8) 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: 0: halt the computer 1: single-user mode @@ -33,83 +37,93 @@ different run-levels as they are implemented: 5: same as 4, it is usually used for GUI login (like X's xdm or KDE's kdm) 6: reboot the computer -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 could issue the init 6 command, -which is an alias for the reboot command. Likewise, -init 0 is an alias for the halt -command. + 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 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 -are either started or stopped, depending on the runlevel chosen. + 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 + are either started or stopped, depending on the runlevel chosen. -The real scripts are in /etc/rc.d/init.d. They do the actual -work, and the symlinks all point to them. Killing links and starting -links point to the same script in /etc/rc.d/init.d. This is because the -scripts can be called with different parameters like -start, stop, -restart, reload, and -status. When a K link is encountered, the -appropriate script is run with the stop -argument. When an S link is encountered, the appropriate script is run -with the start argument. + The real scripts are in /etc/rc.d/init.d. They do the actual work, and + the symlinks all point to them. Killing links and starting links point to + the same script in /etc/rc.d/init.d. + This is because the scripts can be called with different parameters like + start, stop, + restart, reload, and + status. When a K link is encountered, the appropriate + script is run with the stop argument. When an S link + is encountered, the appropriate script is run with the + start argument. -There is one exception to this explanation. Links that start -with an S in the rc0.d and rc6.d directories will not cause anything -to be started. They will be called with the parameter -stop to stop something. The logic behind this -is that when a user is going to reboot or halt the system, nothing -needs to be started. The system only needs to be stopped. + There is one exception to this explanation. Links that start + with an S in the rc0.d and rc6.d directories will not cause anything + to be started. They will be called with the parameter + stop to stop something. The logic behind this + is that when a user is going to reboot or halt the system, nothing + needs to be started. The system only needs to be stopped. -These are descriptions of what the arguments make the scripts -do: + These are descriptions of what the arguments make the scripts + do: - - -start -The service is started. - + - -stop -The service is stopped. - + + start + + The service is started. + + - -restart -The service is stopped and then started again. - + + stop + + The service is stopped. + + - -reload -The configuration of the service is updated. -This is used after the configuration file of a service was modified, when -the service does not need to be restarted. - + + restart + + The service is stopped and then started again. + + - -status -Tells if the service is running and with which PIDs. - - + + reload + + The configuration of the service is updated. + This is used after the configuration file of a service was modified, when + the service does not need to be restarted. + + -Feel free to modify the way the boot process works (after all, -it is your own LFS system). The files given here are an example of how -it can be done. + + status + + Tells if the service is running and with which PIDs. + + + + + + Feel free to modify the way the boot process works (after all, + it is your own LFS system). The files given here are an example of how + it can be done. -