From 06df566407a129388f9bfdc4ec4838e5ce3aa6c8 Mon Sep 17 00:00:00 2001 From: David Bryant Date: Fri, 30 Dec 2022 12:57:01 -0600 Subject: [PATCH] Removed superfluities, corrected spelling and capitalization. Clarifed things that seemed unclear. Removed some phrases that said little. Broke up a run-on sentence. Etc. --- chapter09/usage.xml | 128 +++++++++++++++++++++++--------------------- 1 file changed, 66 insertions(+), 62 deletions(-) diff --git a/chapter09/usage.xml b/chapter09/usage.xml index 88c0296d6..ffbfc408a 100644 --- a/chapter09/usage.xml +++ b/chapter09/usage.xml @@ -19,25 +19,29 @@ How Do the System V 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. + This version of LFS uses a special booting facility named SysVinit, based on a + series of run levels. The boot procedure can be quite different from one + system to another; the fact that things worked one way in a particular Linux + distribution does not guarantee they will work the same way in LFS. LFS has its + own way of doing things, but it does respect generally accepted standards. + + There is an alternative boot procedure called systemd. We will + not discuss that boot process any further here. For a detailed description visit + . 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 in LFS: + uses a run levels scheme. There are seven run levels, numbered 0 to 6. + (Actually, there are more run levels, but the others are for special cases and are + generally not used. See init(8) for more details.) + Each one of the seven corresponds to actions the computer is supposed to + perform when it starts up or shuts down. The default run level is 3. Here are the + descriptions of the different run levels as they are implemented in LFS: 0: halt the computer 1: single-user mode -2: reserved for customization, otherwise does the same as 3 +2: reserved for customization, otherwise the same as 3 3: multi-user mode with networking -4: reserved for customization, otherwise does the same as 3 +4: reserved for customization, otherwise the same as 3 5: same as 4, it is usually used for GUI login (like GNOME's gdm or LXDE's lxdm) 6: reboot the computer @@ -45,9 +49,9 @@ Classically, run level 2 above was defined as "multi-user mode without networking", but this was only the case - many years ago when multiple users could log into a system connected via - serial ports. In today's environment it makes no sense and - we designate it now as "reserved". + many years ago when multiple users could connect to a system via + serial ports. In today's environment it makes no sense, and + we now say it is "reserved". @@ -65,8 +69,8 @@ /etc/inittab - During the kernel initialization, the first program that is run - is either specified on the command line or, by default + During kernel initialization, the first program that is run + (if not overridden on the command line) is init. This program reads the initialization file /etc/inittab. Create this file with: @@ -101,8 +105,8 @@ s1:1:respawn:/sbin/sulogin EOF An explanation of this initialization file is in the man page for - inittab. For LFS, the key command that is run is - rc. The initialization file above will instruct + inittab. In LFS, the key command is + rc. The initialization file above instructs rc to run all the scripts starting with an S in the /etc/rc.d/rcS.d directory followed by all the scripts starting with an S in the functions in /lib/lsb/init-functions. This library also reads an optional configuration file, /etc/sysconfig/rc.site. Any of the system - configuration file parameters described in subsequent sections can be - alternatively placed in this file allowing consolidation of all system + configuration parameters described in subsequent sections can be + placed in this file, allowing consolidation of all system parameters in this one file. As a debugging convenience, the functions script also logs all output to /run/var/bootlog. Since the /run directory is a tmpfs, this file is not - persistent across boots, however it is appended to the more permanent file + persistent across boots; however, it is appended to the more permanent file /var/log/boot.log at the end of the boot process. Changing Run Levels - Changing run-levels is done with init + Changing run levels is done with init <runlevel>, where - <runlevel> is the target run-level. For example, to + <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 @@ -136,15 +140,15 @@ EOF There are a number of directories under /etc/rc.d that look like rc?.d (where ? is the number of the run-level) and + class="directory">rc?.d (where ? is the number of the run level) and rcS.d, all containing a number of - symbolic links. Some begin with a K, the others begin with + symbolic links. Some links 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. + to 99—the smaller the number, the sooner tht script runs. When + init switches to another run level, the appropriate services + are either started or stopped, depending on the run level chosen. The real scripts are in /etc/rc.d/init.d. They do the actual work, and @@ -227,21 +231,21 @@ EOF The /etc/rc.d/init.d/udev initscript starts udevd, triggers any "coldplug" devices that have - already been created by the kernel and waits for any rules to complete. + already been created by the kernel, and waits for any rules to complete. The script also unsets the uevent handler from the default of /sbin/hotplug . This is done because the kernel no - longer needs to call out to an external binary. Instead + longer needs to call an external binary. Instead, udevd will listen on a netlink socket for uevents that the kernel raises. - The /etc/rc.d/init.d/udev_retry initscript takes + The /etc/rc.d/init.d/udev_retry script takes care of re-triggering events for subsystems whose rules may rely on - filesystems that are not mounted until the mountfs + file systems that are not mounted until the mountfs script is run (in particular, /usr and /var may cause this). This script runs after the mountfs script, so those rules (if re-triggered) should succeed the second time around. It is - configured from the /etc/sysconfig/udev_retry file; + configured by the /etc/sysconfig/udev_retry file; any words in this file other than comments are considered subsystem names to trigger at retry time. To find the subsystem of a device, use udevadm info --attribute-walk <device> where @@ -260,13 +264,13 @@ EOF configuring The setclock script reads the time from the hardware - clock, also known as the BIOS or the Complementary Metal Oxide Semiconductor + clock, also known as the BIOS or Complementary Metal Oxide Semiconductor (CMOS) clock. If the hardware clock is set to UTC, this script will convert the hardware clock's time to the local time using the /etc/localtime file (which tells the - hwclock program which timezone to use). There is no + hwclock program which time zone to use). There is no way to detect whether or not the hardware clock is set to UTC, so this - needs to be configured manually. + must be configured manually. The setclock program is run via udev when the kernel detects the hardware @@ -279,9 +283,9 @@ EOF 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 + the proper number of hours for the time zone 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 zone, which is also known as GMT -0700, add seven hours to the local time. Change the value of the UTC variable below @@ -325,7 +329,7 @@ EOF This section discusses how to configure the console bootscript that sets up the keyboard map, console font, and console kernel log level. If non-ASCII characters (e.g., the copyright sign, the British pound - sign and Euro symbol) will not be used and the keyboard is a U.S. one, much + sign, and the Euro symbol) will not be used and the keyboard is a U.S. one, much of this section can be skipped. Without the configuration file, (or equivalent settings in rc.site), the console bootscript will do nothing. @@ -333,11 +337,11 @@ EOF The console script reads the /etc/sysconfig/console file for configuration information. Decide which keymap and screen font will be used. Various - language-specific HOWTOs can also help with this, see . If still in doubt, look in the /usr/share/keymaps and /usr/share/consolefonts directories - for valid keymaps and screen fonts. Read loadkeys(1) and + for valid keymaps and screen fonts. Read the loadkeys(1) and setfont(8) manual pages to determine the correct arguments for these programs. @@ -358,7 +362,7 @@ EOF KEYMAP This variable specifies the arguments for the - loadkeys program, typically, the name of keymap + loadkeys program, typically, the name of the keymap to load, e.g., it. If this variable is not set, the bootscript will not run the loadkeys program, and the default kernel keymap will be used. Note that a few keymaps @@ -390,11 +394,11 @@ EOF name, -m, and the name of the application character map to load. E.g., in order to load the lat1-16 font together with the 8859-1 application character map - (as it is appropriate in the USA), + (appropriate in the USA), set this variable to lat1-16 -m 8859-1. - In UTF-8 mode, the kernel uses the application character map for - conversion of composed 8-bit key codes in the keymap to UTF-8, and thus + In UTF-8 mode, the kernel uses the application character map to + convert 8-bit key codes to UTF-8. Therefore the argument of the "-m" parameter should be set to the encoding of the composed key codes in the keymap. @@ -404,7 +408,7 @@ EOF UNICODE - Set this variable to 1, yes or + Set this variable to 1, yes, or true in order to put the console into UTF-8 mode. This is useful in UTF-8 based locales and harmful otherwise. @@ -522,7 +526,7 @@ EOF UTF-8 mode it is a problem; e.g., for the Greek language, where one sometimes needs to put an accent on the letter alpha. The solution is either to avoid the use of UTF-8, or to install the - X window system that doesn't have this limitation in its input + X window system, which doesn't have this limitation, in its input handling. @@ -531,7 +535,7 @@ EOF console cannot be configured to display the needed characters. Users who need such languages should install the X Window System, fonts that cover the necessary character ranges, and the proper input method (e.g., - SCIM, supports a wide variety of languages). + SCIM supports a wide variety of languages). @@ -565,7 +569,7 @@ EOF - Configuring the sysklogd Script + Configuring the Sysklogd Script sysklogd @@ -600,8 +604,8 @@ EOF console, and clock files in the /etc/sysconfig/ directory. If the associated variables are present in both these separate files and - rc.site, the values in the script specific files have - precedence. + rc.site, the values in the script-specific files take + effect. rc.site also contains parameters that can customize other aspects of the boot process. Setting the IPROMPT variable @@ -615,8 +619,8 @@ EOF Customizing the Boot and Shutdown Scripts The LFS boot scripts boot and shut down a system in a fairly - efficient manner, but there are a few tweaks that you can make in the - rc.site file to improve speed even more and to adjust messages according + efficient manner, but there are a few tweaks you can make in the + rc.site file to improve speed even more, and to adjust messages according to your preferences. To do this, adjust the settings in the /etc/sysconfig/rc.site file above. @@ -624,18 +628,18 @@ EOF During the boot script udev, there is a call to udev settle that requires some time to - complete. This time may or may not be required depending on devices present + complete. This time may or may not be required depending on the devices in the system. If you only have simple partitions and a single ethernet card, the boot process will probably not need to wait for this command. To skip it, set the variable OMIT_UDEV_SETTLE=y. The boot script udev_retry also runs - udev settle by default. This command is only needed by - default if the /var directory is - separately mounted. This is because the clock needs the file - /var/lib/hwclock/adjtime. Other customizations may + udev settle by default. This command is only needed + if the /var directory is + separately mounted, because the clock needs the + /var/lib/hwclock/adjtime file. Other customizations may also need to wait for udev to complete, but in many installations it is not - needed. Skip the command by setting the variable OMIT_UDEV_RETRY_SETTLE=y. + necessary. Skip the command by setting the variable OMIT_UDEV_RETRY_SETTLE=y. By default, the file system checks are silent. This can @@ -664,7 +668,7 @@ EOF During shutdown, the init program sends a TERM signal to each program it has started (e.g. agetty), waits for a set - time (default 3 seconds), and sends each process a KILL signal and waits + time (default 3 seconds), then sends each process a KILL signal and waits again. This process is repeated in the sendsignals script for any processes that are not shut down by their own scripts. The delay for init can be set by passing a parameter. For