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