ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 16. Booting and Configuring a Linux System</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.reference.system.html" title="Part IV. System"><link rel="prev" href="cha.64bit.html" title="Chapter 15. 32-Bit and 64-Bit Applications in a 64-Bit System Environment"><link rel="next" href="cha.grub.html" title="Chapter 17. The Boot Loader GRUB"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.opensuse.reference.html">Reference</a><span class="breadcrumbs-sep"> > </span><a href="part.reference.system.html">System</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 15. 32-Bit and 64-Bit Applications in a 64-Bit System Environment" href="cha.64bit.html"><span>◀</span></a> <a accesskey="n" title="Chapter 17. The Boot Loader GRUB" href="cha.grub.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 16. Booting and Configuring a Linux System"><div class="titlepage"><div><div><h2 class="title"><a name="cha.boot"></a>Chapter 16. Booting and Configuring a Linux System<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.boot">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.boot.html#sec.boot.proc">16.1. The Linux Boot Process</a></span></dt><dt><span class="sect1"><a href="cha.boot.html#sec.boot.init">16.2. The init Process</a></span></dt><dt><span class="sect1"><a href="cha.boot.html#sec.boot.sysconfig">16.3. System Configuration via /etc/sysconfig</a></span></dt></dl></div><a class="indexterm" name="id459874"></a><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>
Booting a Linux system involves different components. The hardware itself
is initialized by the BIOS, which starts the Kernel by means of a boot
loader. After this point, the boot process with init and the runlevels is
completely controlled by the operating system. The runlevel concept
enables you to maintain setups for everyday usage as well as to perform
maintenance tasks on the system.
</p></div><div class="sect1" title="16.1. The Linux Boot Process"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.boot.proc"></a>16.1. The Linux Boot Process<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.boot.proc">¶</a></span></h2></div></div></div><p>
The Linux boot process consists of several stages, each represented by a
different component. The following list briefly summarizes the boot
process and features all the major components involved.
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li><p title="BIOS"><b>BIOS. </b>
After turning on the computer, the BIOS initializes the screen and
keyboard and tests the main memory. Up to this stage, the machine does
not access any mass storage media. Subsequently, the information about
the current date, time, and the most important peripherals are loaded
from the CMOS values. When the first hard disk and its geometry are
recognized, the system control passes from the BIOS to the boot
loader.
</p></li><li><p title="Boot Loader"><b>Boot Loader. </b>
The first physical 512-byte data sector of the first hard disk is
loaded into the main memory and the <span class="emphasis"><em>boot loader</em></span>
that resides at the beginning of this sector takes over. The commands
executed by the boot loader determine the remaining part of the boot
process. Therefore, the first 512 bytes on the first hard disk
are referred to as the <span class="emphasis"><em>Master Boot Record</em></span> (MBR).
The boot loader then passes control to the actual operating system, in
this case, the Linux Kernel. More information about GRUB, the Linux
boot loader, can be found in <a class="xref" href="cha.grub.html" title="Chapter 17. The Boot Loader GRUB">Chapter 17, <i>The Boot Loader GRUB</i></a>.
</p></li><li><p title="Kernel and initramfs"><b>Kernel and <code class="filename">initramfs</code>. </b>
To pass system control, the boot loader loads both the Kernel and an
initial RAM–based file system (<code class="filename">initramfs</code>)
into memory. The contents of the <code class="filename">initramfs</code> can be
used by the Kernel directly. <code class="filename">initramfs</code> contains a
small executable called init that handles the mounting of the real
root file system. If special hardware drivers are needed before the
mass storage can be accessed, they must be in
<code class="filename">initramfs</code>. For more information about
<code class="filename">initramfs</code>, refer to
<a class="xref" href="cha.boot.html#sec.boot.initrd" title="16.1.1. initramfs">Section 16.1.1, “<code class="filename">initramfs</code>”</a>.
</p></li><li><p title="init on initramfs"><b>init on <code class="filename">initramfs</code>. </b>
This program performs all actions needed to mount the proper root file
system, like providing Kernel functionality for the needed file system
and device drivers for mass storage controllers with <code class="systemitem">udev</code>. After the
root file system has been found, it is checked for errors and mounted.
If this is successful, the <code class="filename">initramfs</code> is cleaned
and the init program on the root file system is executed. For more
information about init, refer to
<a class="xref" href="cha.boot.html#sec.boot.linuxrc" title="16.1.2. init on initramfs">Section 16.1.2, “init on <code class="filename">initramfs</code>”</a>. Find more information about
<code class="systemitem">udev</code> in <a class="xref" href="cha.udev.html" title="Chapter 19. Dynamic Kernel Device Management with udev">Chapter 19, <i>Dynamic Kernel Device Management with <code class="systemitem">udev</code></i></a>.
</p></li><li><p title="init"><b>init. </b>
init handles the actual booting of the system through several
different levels providing different functionality. init is described
in <a class="xref" href="cha.boot.html#sec.boot.init" title="16.2. The init Process">Section 16.2, “The init Process”</a>.
</p></li></ol></div><div class="sect2" title="16.1.1. initramfs"><div class="titlepage"><div><div><h3 class="title"><a name="sec.boot.initrd"></a>16.1.1. <code class="filename">initramfs</code><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.boot.initrd">¶</a></span></h3></div></div></div><p>
<code class="filename">initramfs</code> is a small cpio archive that the Kernel
can load to a RAM disk. It provides a minimal Linux environment that
enables the execution of programs before the actual root file system is
mounted. This minimal Linux environment is loaded into memory by BIOS
routines and does not have specific hardware requirements other than
sufficient memory. <code class="filename">initramfs</code> must always provide an
executable named init that should execute the actual init program on the
root file system for the boot process to proceed.
</p><p>
Before the root file system can be mounted and the operating system can
be started, the Kernel needs the corresponding drivers to access the
device on which the root file system is located. These drivers may
include special drivers for certain kinds of hard drives or even network
drivers to access a network file system. The needed modules for the root
file system may be loaded by init on <code class="filename">initramfs</code>.
After the modules are loaded, <code class="systemitem">udev</code> provides the
<code class="filename">initramfs</code> with the needed devices. Later in the
boot process, after changing the root file system, it is necessary to
regenerate the devices. This is done by <code class="filename">boot.udev</code>
with the command <span class="command"><strong>udevtrigger</strong></span>.
</p><a class="indexterm" name="id460126"></a><a class="indexterm" name="id460135"></a><a class="indexterm" name="id460143"></a><p>
If you need to change hardware (for example, hard disks) in an installed
system and this hardware requires different drivers to be present in the
Kernel at boot time, you must update <code class="filename">initramfs</code>.
This is done in the same way as with its predecessor,
<code class="filename">initrd</code>—by calling
<span class="command"><strong>mkinitrd</strong></span>. Calling <span class="command"><strong>mkinitrd</strong></span> without
any argument creates an <code class="filename">initramfs</code>. Calling
<span class="command"><strong>mkinitrd <code class="option">-R</code></strong></span> creates an
<code class="filename">initrd</code>. In openSUSE®, the modules to load
are specified by the variable <code class="systemitem">INITRD_MODULES</code> in
<code class="filename">/etc/sysconfig/kernel</code>. <a class="indexterm" name="id460197"></a> After installation, this variable is automatically set to
the correct value. The modules are loaded in exactly the order in which
they appear in <code class="systemitem">INITRD_MODULES</code>. This is only
important if you rely on the correct setting of the device files
<code class="filename">/dev/sd?</code>. However, in current systems you also may
use the device files below <code class="filename">/dev/disk/</code> that are
sorted in several subdirectories, named <code class="filename">by-id</code>,
<code class="filename">by-path</code> and <code class="filename">by-uuid</code>, and
always represent the same disk. This is also possible at install time by
specifying the respective mount option.
</p><div class="important"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Important: Updating initramfs or initrd"><tr class="head"><td width="32"><img alt="[Important]" src="admon/important.png"></td><th align="left">Updating <code class="filename">initramfs</code> or <code class="filename">initrd</code></th></tr><tr><td colspan="2" align="left" valign="top"><p>
The boot loader loads <code class="filename">initramfs</code> or
<code class="filename">initrd</code> in the same way as the Kernel. It is not
necessary to reinstall GRUB after updating
<code class="filename">initramfs</code> or <code class="filename">initrd</code>, because
GRUB searches the directory for the right file when booting.
</p></td></tr></table></div></div><div class="sect2" title="16.1.2. init on initramfs"><div class="titlepage"><div><div><h3 class="title"><a name="sec.boot.linuxrc"></a>16.1.2. init on <code class="filename">initramfs</code><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.boot.linuxrc">¶</a></span></h3></div></div></div><p>
The main purpose of init on <code class="filename">initramfs</code> is to prepare
the mounting of and access to the real root file system. Depending on
your system configuration, init is responsible for the following tasks.
</p><div class="variablelist"><dl><dt><span class="term">Loading Kernel Modules</span></dt><dd><p>
Depending on your hardware configuration, special drivers may be
needed to access the hardware components of your computer (the most
important component being your hard drive). To access the final root
file system, the Kernel needs to load the proper file system drivers.
</p></dd><dt><span class="term">Providing Block Special Files</span></dt><dd><p>
For each loaded module, the Kernel generates device events. <code class="systemitem">udev</code>
handles these events and generates the required block special files
on a RAM file system in <code class="filename">/dev</code>. Without those
special files, the file system and other devices would not be
accessible.
</p></dd><dt><span class="term">Managing RAID and LVM Setups</span></dt><dd><p>
If you configured your system to hold the root file system under RAID
or LVM, init sets up LVM or RAID to enable access to the root file
system later. Find information about RAID and LVM in
<a class="xref" href="cha.advdisk.html" title="Chapter 2. Advanced Disk Setup">Chapter 2, <i>Advanced Disk Setup</i></a>.
</p></dd><dt><a name="ve.net"></a><span class="term">Managing Network Configuration</span></dt><dd><p>
If you configured your system to use a network-mounted root file
system (mounted via NFS), init must make sure that the proper network
drivers are loaded and that they are set up to allow access to the
root file system.
</p></dd></dl></div><p>
When init is called during the initial boot as part of the installation
process, its tasks differ from those mentioned above:
</p><div class="variablelist"><dl><dt><span class="term">Finding the Installation Medium</span></dt><dd><p>
As you start the installation process, your machine loads an
installation Kernel and a special <code class="filename">initrd</code> with
the YaST installer on the installation medium. The YaST
installer, which is run in a RAM file system, needs to have
information about the location of the installation medium to access
it and install the operating system.
</p></dd><dt><span class="term">Initiating Hardware Recognition and Loading Appropriate Kernel Modules</span></dt><dd><p>
As mentioned in <a class="xref" href="cha.boot.html#sec.boot.initrd" title="16.1.1. initramfs">Section 16.1.1, “<code class="filename">initramfs</code>”</a>, the boot process
starts with a minimum set of drivers that can be used with most
hardware configurations. init starts an initial hardware scanning
process that determines the set of drivers suitable for your hardware
configuration. The names of the modules needed for the boot process
are written to <code class="systemitem">INITRD_MODULES</code> in
<code class="filename">/etc/sysconfig/kernel</code>. These names are used to
generate a custom <code class="filename">initramfs</code> that is needed to
boot the system. If the modules are not needed for boot but for
coldplug, the modules are written to
<code class="filename">/etc/sysconfig/hardware/hwconfig-*</code>. All devices
that are described with configuration files in this directory are
initialized in the boot process.
</p></dd><dt><span class="term">Loading the Installation System or Rescue System</span></dt><dd><p>
As soon as the hardware is properly recognized, the appropriate
drivers are loaded, and <code class="systemitem">udev</code> creates the special device files, init
starts the installation system with the actual YaST installer, or
the rescue system.
</p></dd><dt><span class="term">Starting YaST</span></dt><dd><p>
Finally, init starts YaST, which starts package installation and
system configuration.
</p></dd></dl></div></div></div><div class="sect1" title="16.2. The init Process"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.boot.init"></a>16.2. The init Process<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.boot.init">¶</a></span></h2></div></div></div><a class="indexterm" name="idx.init"></a><a class="indexterm" name="id460515"></a><a class="indexterm" name="id460523"></a><p>
The program init is the process with process ID 1. It is responsible for
initializing the system in the required way. init is started directly by
the Kernel and resists signal 9, which normally kills processes. All
other programs are either started directly by init or by one of its child
processes.
</p><p>
init is centrally configured in the <code class="filename">/etc/inittab</code>
file where the <span class="emphasis"><em>runlevels</em></span> are defined (see
<a class="xref" href="cha.boot.html#sec.boot.runlevel" title="16.2.1. Runlevels">Section 16.2.1, “Runlevels”</a>). The file also specifies which
services and daemons are available in each of the runlevels. Depending on
the entries in <code class="filename">/etc/inittab</code>, several scripts are run
by init. By default, the first script that is started after booting is
<code class="filename">/etc/init.d/boot</code>. Once the system initialization
phase is finished, the system changes the runlevel to its default
runlevel with the <code class="filename">/etc/init.d/rc</code> script. For reasons
of clarity, these scripts, called <span class="emphasis"><em>init scripts</em></span>, all
reside in the directory <code class="filename">/etc/init.d</code> (see
<a class="xref" href="cha.boot.html#sec.boot.init.skripte" title="16.2.2. Init Scripts">Section 16.2.2, “Init Scripts”</a>). <a class="indexterm" name="id460581"></a>
</p><p>
The entire process of starting the system and shutting it down is
maintained by init. From this point of view, the Kernel can be considered
a background process to maintain all other processes and adjust CPU time
and hardware access according to requests from other programs.
</p><a class="indexterm" name="id460598"></a><div class="sect2" title="16.2.1. Runlevels"><div class="titlepage"><div><div><h3 class="title"><a name="sec.boot.runlevel"></a>16.2.1. Runlevels<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.boot.runlevel">¶</a></span></h3></div></div></div><a class="indexterm" name="idx.runlevels"></a><a class="indexterm" name="id460624"></a><p>
In Linux, <span class="emphasis"><em>runlevels</em></span> define how the system is
started and what services are available in the running system. After
booting, the system starts as defined in
<code class="filename">/etc/inittab</code> in the line
<code class="literal">initdefault</code>. Usually this is <code class="literal">3</code> or
<code class="literal">5</code>. See <a class="xref" href="cha.boot.html#tab.boot.runlevel" title="Table 16.1. Available Runlevels">Table 16.1, “Available Runlevels”</a>. As an
alternative, the runlevel can be specified at boot time (by adding the
runlevel number at the boot prompt, for instance). Any parameters that
are not directly evaluated by the Kernel itself are passed to init. To
boot into runlevel 3, just add the single number 3 to the boot prompt.
</p><div class="table"><a name="tab.boot.runlevel"></a><p class="title"><b>Table 16.1. Available Runlevels</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#tab.boot.runlevel">¶</a></span></p><div class="table-contents"><table summary="Available Runlevels" border="1"><colgroup><col><col></colgroup><thead><tr><th>
<p>
Runlevel
</p>
</th><th>
<p>
Description
</p>
</th></tr></thead><tbody><tr><td>
<p>
0
</p>
</td><td>
<p>
System halt
</p>
</td></tr><tr><td>
<p>
S or 1
</p>
</td><td>
<p>
Single user mode
</p>
</td></tr><tr><td>
<p>
2
</p>
</td><td>
<p>
Local multiuser mode without remote network (NFS, etc.)
</p>
</td></tr><tr><td>
<p>
3
</p>
</td><td>
<p>
Full multiuser mode with network
</p>
</td></tr><tr><td>
<p>
4
</p>
</td><td>
<p>
<span class="guimenu">User Defined</span>, this is not used unless the
administrator configures this runlevel.
</p>
</td></tr><tr><td>
<p>
5
</p>
</td><td>
<p>
Full multiuser mode with network and X display manager—KDM,
GDM, or XDM
</p>
</td></tr><tr><td>
<p>
6
</p>
</td><td>
<p>
System reboot
</p>
</td></tr></tbody></table></div></div><br class="table-break"><div class="important"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Important: Avoid Runlevel 2 with a Partition Mounted via NFS"><tr class="head"><td width="32"><img alt="[Important]" src="admon/important.png"></td><th align="left">Avoid Runlevel 2 with a Partition Mounted via NFS</th></tr><tr><td colspan="2" align="left" valign="top"><p>
You should not use runlevel 2 if your system mounts a partition
like <code class="filename">/usr</code> via NFS. The system might behave
unexpectedly if program files or libraries are missing because the NFS
service is not available in runlevel 2 (local multiuser mode
without remote network).
</p></td></tr></table></div><p>
To change runlevels while the system is running, enter
<span class="command"><strong>telinit</strong></span> and the corresponding number as an argument.
Only the system administrator is allowed to do this. The following list
summarizes the most important commands in the runlevel area.
</p><div class="variablelist"><dl><dt><span class="term"><span class="command"><strong>telinit 1</strong></span> or <span class="command"><strong>shutdown now</strong></span>
</span></dt><dd><p>
The system changes to <span class="emphasis"><em>single user mode</em></span>. This
mode is used for system maintenance and administration tasks.
</p></dd><dt><span class="term"><span class="command"><strong>telinit 3</strong></span>
</span></dt><dd><p>
All essential programs and services (including network) are started
and regular users are allowed to log in and work with the system
without a graphical environment.
</p></dd><dt><span class="term"><span class="command"><strong>telinit 5</strong></span>
</span></dt><dd><p>
The graphical environment is enabled. Usually a display manager like
XDM, GDM or KDM is started. If autologin is enabled, the local user
is logged in to the preselected window manager (GNOME or KDE or any
other window manager).
</p></dd><dt><span class="term"><span class="command"><strong>telinit 0</strong></span> or <span class="command"><strong>shutdown -h now</strong></span>
</span></dt><dd><p>
The system halts.
</p></dd><dt><span class="term"><span class="command"><strong>telinit 6</strong></span> or <span class="command"><strong>shutdown -r now</strong></span>
</span></dt><dd><p>
The system halts then reboots.
</p></dd></dl></div><p>
Runlevel <code class="literal">5</code> is the default runlevel in all
openSUSE standard installations. Users are prompted for login with
a graphical interface or the default user is logged in automatically.
</p><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning: Errors in /etc/inittab May Result in a Faulty System Boot"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left">Errors in /etc/inittab May Result in a Faulty System Boot</th></tr><tr><td colspan="2" align="left" valign="top"><p>
<a class="indexterm" name="id461001"></a> If <code class="filename">/etc/inittab</code> is damaged, the
system may not boot properly. Therefore, be extremely careful while
editing <code class="filename">/etc/inittab</code>. Always let init reread
<code class="filename">/etc/inittab</code> with the command <span class="command"><strong>telinit
<code class="option">q</code></strong></span> before rebooting the machine.
</p></td></tr></table></div><a class="indexterm" name="idx.runlevels_changing"></a><p>
Generally, two things happen when you change runlevels. First, stop
scripts of the current runlevel are launched, closing down some programs
essential for the current runlevel. Then start scripts of the new
runlevel are started. Here, in most cases, a number of programs are
started. For example, the following occurs when changing from runlevel 3
to 5:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li><p>
The administrator (<code class="systemitem">root</code>)
requests init to change to a different runlevel by entering
<span class="command"><strong>telinit <code class="option">5</code></strong></span>.
</p></li><li><p>
<a class="indexterm" name="id461084"></a> <a class="indexterm" name="id461096"></a> init checks the current runlevel
(<span class="command"><strong>runlevel</strong></span>) and determines it should start
<code class="filename">/etc/init.d/rc</code> with the new runlevel as a
parameter.
</p></li><li><p>
Now <span class="command"><strong>rc</strong></span> calls the stop scripts of the current
runlevel for which there is no start script in the new runlevel. In
this example, these are all the scripts that reside in
<code class="filename">/etc/init.d/rc3.d</code> (the old runlevel was 3) and
start with a <code class="literal">K</code>. The number following
<code class="literal">K</code> specifies the order to run the scripts with the
<code class="systemitem">stop</code> parameter, because there are some
dependencies to consider.
</p></li><li><p>
The last things to start are the start scripts of the new runlevel. In
this example, these are in <code class="filename">/etc/init.d/rc5.d</code> and
begin with an <code class="literal">S</code>. Again, the number that follows the
<code class="literal">S</code> determines the sequence in which the scripts are
started.
</p></li></ol></div><p>
When changing into the same runlevel as the current runlevel, init only
checks <code class="filename">/etc/inittab</code> for changes and starts the
appropriate steps, for example, for starting a <span class="command"><strong>getty</strong></span>
on another interface. The same functionality may be achieved with the
command <span class="command"><strong>telinit q</strong></span>.
</p><a class="indexterm" name="id461187"></a><a class="indexterm" name="id461193"></a></div><div class="sect2" title="16.2.2. Init Scripts"><div class="titlepage"><div><div><h3 class="title"><a name="sec.boot.init.skripte"></a>16.2.2. Init Scripts<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.boot.init.skripte">¶</a></span></h3></div></div></div><a class="indexterm" name="idx.init_scripts"></a><a class="indexterm" name="idx.scripts_init.d"></a><p>
There are two types of scripts in <code class="filename">/etc/init.d</code>:
</p><div class="variablelist"><dl><dt><span class="term">Scripts Executed Directly by init </span></dt><dd><p>
<span> This is the case
only during the boot process or if an immediate system shutdown is
initiated (power failure or a user pressing <span class="keycap">Ctrl</span>+<span class="keycap">Alt</span>+<span class="keycap">Del</span>).</span> The execution of these
scripts is defined in <code class="filename">/etc/inittab</code>.
</p></dd><dt><span class="term">Scripts Executed Indirectly by init </span></dt><dd><p>
<a class="indexterm" name="id461302"></a> These are run when changing the runlevel and always call
the master script <span class="command"><strong>/etc/init.d/rc</strong></span>, which guarantees
the correct order of the relevant scripts.
</p></dd></dl></div><p>
All scripts are located in <code class="filename">/etc/init.d</code>. Scripts
that are run at boot time are called through symbolic links from
<code class="filename">/etc/init.d/boot.d</code>. Scripts for changing the
runlevel are called through symbolic links from one of the
subdirectories (<code class="filename">/etc/init.d/rc0.d</code> to
<code class="filename">/etc/init.d/rc6.d</code>). This is just for reasons of
clarity and avoids duplicate scripts if they are used in several
runlevels. Because every script can be executed as both a start and a
stop script, these scripts must understand the parameters
<code class="option">start</code> and <code class="option">stop</code>. The scripts also
understand the <code class="option">restart</code>, <code class="option">reload</code>,
<code class="option">force-reload</code>, and <code class="option">status</code> options.
These different options are explained in
<a class="xref" href="cha.boot.html#tab.boot.initscript.opt" title="Table 16.2. Possible init Script Options">Table 16.2, “Possible init Script Options”</a>. Scripts that are run
directly by init do not have these links. They are run independently
from the runlevel when needed.
</p><div class="table"><a name="tab.boot.initscript.opt"></a><p class="title"><b>Table 16.2. Possible init Script Options</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#tab.boot.initscript.opt">¶</a></span></p><div class="table-contents"><table summary="Possible init Script Options" border="1"><colgroup><col><col></colgroup><thead><tr><th>
<p>
Option
</p>
</th><th>
<p>
Description
</p>
</th></tr></thead><tbody><tr><td>
<p>
<code class="option">start</code>
</p>
</td><td>
<p>
Start service.
</p>
</td></tr><tr><td>
<p>
<code class="option">stop</code>
</p>
</td><td>
<p>
Stop service.
</p>
</td></tr><tr><td>
<p>
<code class="option">restart</code>
</p>
</td><td>
<p>
If the service is running, stop it then restart it. If it is not
running, start it.
</p>
</td></tr><tr><td>
<p>
<code class="option">reload</code>
</p>
</td><td>
<p>
Reload the configuration without stopping and restarting the
service.
</p>
</td></tr><tr><td>
<p>
<code class="option">force-reload</code>
</p>
</td><td>
<p>
Reload the configuration if the service supports this. Otherwise,
do the same as if <code class="option">restart</code> had been given.
</p>
</td></tr><tr><td>
<p>
<code class="option">status</code>
</p>
</td><td>
<p>
Show the current status of service.
</p>
</td></tr></tbody></table></div></div><br class="table-break"><p>
Links in each runlevel-specific subdirectory make it possible to
associate scripts with different runlevels. When installing or
uninstalling packages, these links are added and removed with the help
of the program insserv (or using
<code class="filename">/usr/lib/lsb/install_initd</code>, which is a script
calling this program). See the insserv(8) man page for details.
</p><p>
All of these settings may also be changed with the help of the YaST
module. If you need to check the status on the command line, use the
tool <code class="systemitem">chkconfig</code>, described in the chkconfig(8)
man page.
</p><p>
A short introduction to the boot and stop scripts launched first or
last, respectively, follows as well as an explanation of the maintaining
script.
</p><div class="variablelist"><dl><dt><span class="term"><code class="filename">boot</code>
</span></dt><dd><p>
<a class="indexterm" name="id461602"></a> Executed while starting the system directly using init.
It is independent of the chosen runlevel and is only executed once.
Here, the <code class="filename">/proc</code> and
<code class="filename">/dev/pts</code> file systems are mounted and blogd
(boot logging daemon) is activated. If the system is booted for the
first time after an update or an installation, the initial system
configuration is started.
</p><p>
The blogd daemon is a service started by boot and rc before any other
one. It is stopped after the actions triggered by these scripts
(running a number of subscripts, for example, making block special
files available) are completed. blogd writes any screen output to the
log file <code class="filename">/var/log/boot.msg</code>, but only if and when
<code class="filename">/var</code> is mounted read-write. Otherwise, blogd
buffers all screen data until <code class="filename">/var</code> becomes
available. Get further information about blogd on the blogd(8) man
page.
</p><p>
The <code class="filename">boot</code> script is also responsible for starting
all the scripts in <code class="filename">/etc/init.d/boot.d</code> with names
that start with <code class="literal">S</code>. There, the file systems are
checked and loop devices are configured if needed. The system time is
also set. If an error occurs while automatically checking and
repairing the file system, the system administrator can intervene
after first entering the root password. The last executed script is
<span class="command"><strong>boot.local</strong></span>.
</p></dd><dt><span class="term"><code class="filename">boot.local</code>
</span></dt><dd><p>
<a class="indexterm" name="id461685"></a> Here, enter additional commands to execute at boot
before changing into a runlevel. It can be compared to
<code class="filename">AUTOEXEC.BAT</code> on DOS systems.
</p></dd><dt><span class="term"><code class="filename">halt</code>
</span></dt><dd><p>
<a class="indexterm" name="id461722"></a> This script is only executed while changing into
runlevel 0 or 6. Here, it is executed either as
<code class="literal">halt</code> or as <code class="literal">reboot</code>. Whether the
system shuts down or reboots depends on how <code class="filename">halt</code>
is called. If special commands are needed during the shutdown, add
these to the <code class="literal">halt.local</code> script.
</p></dd><dt><span class="term"><code class="filename">rc</code>
</span></dt><dd><p>
<a class="indexterm" name="id461771"></a> This script calls the appropriate stop scripts of the
current runlevel and the start scripts of the newly selected
runlevel. Like the <code class="filename">/etc/init.d/boot</code> script, this
script is called from <code class="filename">/etc/inittab</code> with the
desired runlevel as parameter.
</p></dd></dl></div><a class="indexterm" name="id461799"></a><p>
You can create your own scripts and easily integrate them into the
scheme described above. For instructions about formatting, naming and
organizing custom scripts, refer to the specifications of the LSB and to
the man pages of <code class="systemitem">init</code>,
<code class="systemitem">init.d</code>, <code class="systemitem">chkconfig</code>, and
<code class="systemitem">insserv</code>. Additionally consult the man pages of
<code class="systemitem">startproc</code> and
<code class="systemitem">killproc</code>.
</p><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning: Faulty init Scripts May Halt Your System"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left">Faulty init Scripts May Halt Your System</th></tr><tr><td colspan="2" align="left" valign="top"><p>
Faulty init scripts may hang your machine up. Edit such scripts with
great care and, if possible, subject them to heavy testing in the
multiuser environment. Find useful information about init scripts in
<a class="xref" href="cha.boot.html#sec.boot.runlevel" title="16.2.1. Runlevels">Section 16.2.1, “Runlevels”</a>.
</p></td></tr></table></div><p>
To create a custom init script for a given program or service, use the
file <code class="filename">/etc/init.d/skeleton</code> as a template. Save a
copy of this file under the new name and edit the relevant program and
filenames, paths and other details as needed. You may also need to
enhance the script with your own parts, so the correct actions are
triggered by the init procedure.
</p><p>
The <code class="literal">INIT INFO</code> block at the top is a required part of
the script and must be edited. See
<a class="xref" href="cha.boot.html#aus.boot.init.skripte.add.initinfo" title="Example 16.1. A Minimal INIT INFO Block">Example 16.1, “A Minimal INIT INFO Block”</a>.
</p><div class="example"><a name="aus.boot.init.skripte.add.initinfo"></a><p class="title"><b>Example 16.1. A Minimal INIT INFO Block</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#aus.boot.init.skripte.add.initinfo">¶</a></span></p><div class="example-contents"><pre class="screen">### BEGIN INIT INFO
# Provides: FOO
# Required-Start: $syslog $remote_fs
# Required-Stop: $syslog $remote_fs
# Default-Start: 3 5
# Default-Stop: 0 1 2 6
# Description: Start FOO to allow XY and provide YZ
### END INIT INFO</pre></div></div><br class="example-break"><p>
In the first line of the <code class="literal">INFO</code> block, after
<code class="literal">Provides:</code>, specify the name of the program or service
controlled by this init script. In the
<code class="literal">Required-Start:</code> and <code class="literal">Required-Stop:</code>
lines, specify all services that need to be still running when the service
itself is stopped. This information is used later
to generate the numbering of script names, as found in the runlevel
directories. After <code class="literal">Default-Start:</code> and
<code class="literal">Default-Stop:</code>, specify the runlevels in which the
service should automatically be started or stopped. Finally, for
<code class="literal">Description:</code>, provide a short description of the
service in question.
</p><p>
To create the links from the runlevel directories
(<code class="filename">/etc/init.d/rc?.d/</code>) to the corresponding scripts
in <code class="filename">/etc/init.d/</code>, enter the command <span class="command"><strong>insserv
<em class="replaceable"><code>new-script-name</code></em></strong></span>. The insserv
program evaluates the <code class="literal">INIT INFO</code> header to create the
necessary links for start and stop scripts in the runlevel directories
(<code class="filename">/etc/init.d/rc?.d/</code>). The program also takes care
of the correct start and stop order for each runlevel by including the
necessary numbers in the names of these links. If you prefer a graphical
tool to create such links, use the runlevel editor provided by YaST,
as described in <a class="xref" href="cha.boot.html#sec.boot.runlevel.edit" title="16.2.3. Configuring System Services (Runlevel) with YaST">Section 16.2.3, “Configuring System Services (Runlevel) with YaST”</a>.
</p><p>
If a script already present in <code class="filename">/etc/init.d/</code> should
be integrated into the existing runlevel scheme, create the links in the
runlevel directories right away with insserv or by enabling the
corresponding service in the runlevel editor of YaST. Your changes are
applied during the next reboot—the new service is started
automatically.
</p><p>
Do not set these links manually. If something is wrong in the
<code class="literal">INFO</code> block, problems will arise when
<span class="command"><strong>insserv</strong></span> is run later for some other service. The
manually added service will be removed with the next run of
<span class="command"><strong>insserv</strong></span> for this script.
</p><a class="indexterm" name="id461987"></a><a class="indexterm" name="id461992"></a></div><div class="sect2" title="16.2.3. Configuring System Services (Runlevel) with YaST"><div class="titlepage"><div><div><h3 class="title"><a name="sec.boot.runlevel.edit"></a>16.2.3. Configuring System Services (Runlevel) with YaST<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.boot.runlevel.edit">¶</a></span></h3></div></div></div><a class="indexterm" name="id462009"></a><a class="indexterm" name="id462017"></a><p>
After starting this YaST module with <span class="guimenu">YaST</span>+<span class="guimenu">System</span>+<span class="guimenu">System Services (Runlevel)</span>, it displays an overview
listing all the available services and the current status of each
service (disabled or enabled). Decide whether to use the module in
<span class="guimenu">Simple Mode</span> or in <span class="guimenu">Expert Mode</span>. The
default <span class="guimenu">Simple Mode</span> should be sufficient for most
purposes. The left column shows the name of the service, the center
column indicates its current status and the right column gives a short
description. For the selected service, a more detailed description is
provided in the lower part of the window. To enable a service, select it
in the table then select <span class="guimenu">Enable</span>. The same steps apply
to disable a service.
</p><p>
For detailed control over the runlevels in which a service is started or
stopped or to change the default runlevel, first select <span class="guimenu">Expert
Mode</span>. The current default runlevel or
<span class="quote">“<span class="quote">initdefault</span>”</span> (the runlevel into which the system boots by
default) is displayed at the top. Normally, the default runlevel of a
openSUSE system is runlevel 5 (full multiuser mode with
network and X). A suitable alternative might be runlevel 3 (full
multiuser mode with network).
</p><p>
This YaST dialog allows the selection of one of the runlevels (as
listed in <a class="xref" href="cha.boot.html#tab.boot.runlevel" title="Table 16.1. Available Runlevels">Table 16.1, “Available Runlevels”</a>) as the new default.
Additionally, use the table in this window to enable or disable
individual services and daemons. The table lists the services and
daemons available, shows whether they are currently enabled on your
system and, if so, for which runlevels. After selecting one of the rows
with the mouse, click the check boxes representing the runlevels
(<span class="guimenu">B</span>, <span class="guimenu">0</span>, <span class="guimenu">1</span>,
<span class="guimenu">2</span>, <span class="guimenu">3</span>, <span class="guimenu">5</span>,
<span class="guimenu">6</span>, and <span class="guimenu">S</span>) to define the runlevels
in which the selected service or daemon should be running.
Runlevel 4 is undefined to allow creation of a custom runlevel. A
brief description of the currently selected service or daemon is
provided below the table overview.
</p><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning: Faulty Runlevel Settings May Damage Your System"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left">Faulty Runlevel Settings May Damage Your System</th></tr><tr><td colspan="2" align="left" valign="top"><p>
Faulty runlevel settings may make your system unusable. Before applying
your changes, make absolutely sure that you know their consequences.
</p></td></tr></table></div><div class="figure"><a name="fig.yast2.runlevel"></a><p class="title"><b>Figure 16.1. System Services (Runlevel)</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.runlevel">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_runlevel.png" width="100%" alt="System Services (Runlevel)"></td></tr></table></div></div></div><br class="figure-break"><p>
With <span class="guimenu">Start, Stop, or Refresh</span>, decide whether a
service should be activated. <span class="guimenu">Refresh status</span> checks
the current status. <span class="guimenu">Set or Reset</span> lets you select
whether to apply your changes to the system or to restore the settings
that existed before starting the runlevel editor. Selecting
<span class="guimenu">OK</span> saves the changed settings to disk.
</p></div></div><div class="sect1" title="16.3. System Configuration via /etc/sysconfig"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.boot.sysconfig"></a>16.3. System Configuration via /etc/sysconfig<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.boot.sysconfig">¶</a></span></h2></div></div></div><a class="indexterm" name="id462217"></a><a class="indexterm" name="idx.scripts_SuSEconfig"></a><a class="indexterm" name="idx.configuration_files_sysconfig"></a><p>
The main configuration of openSUSE is controlled by the
configuration files in <code class="filename">/etc/sysconfig</code>. The
individual files in <code class="filename">/etc/sysconfig</code> are only read by
the scripts to which they are relevant. This ensures that network
settings, for example, only need to be parsed by network-related scripts.
</p><p>
There are two ways to edit the system configuration. Either use the
YaST sysconfig Editor or edit the configuration files manually.
</p><div class="sect2" title="16.3.1. Changing the System Configuration Using the YaST sysconfig Editor"><div class="titlepage"><div><div><h3 class="title"><a name="sec.boot.sysconfig.edit"></a>16.3.1. Changing the System Configuration Using the YaST sysconfig Editor<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.boot.sysconfig.edit">¶</a></span></h3></div></div></div><a class="indexterm" name="id462281"></a><p>
The YaST sysconfig editor provides an easy-to-use front-end for system
configuration. Without any knowledge of the actual location of the
configuration variable you need to change, you can just use the built-in
search function of this module, change the value of the configuration
variable as needed and let YaST take care of applying these changes,
updating configurations that depend on the values set in
<code class="filename">sysconfig</code> and restarting services.
</p><div class="warning"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Warning: Modifying /etc/sysconfig/* Files Can Damage Your Installation"><tr class="head"><td width="32"><img alt="[Warning]" src="admon/warning.png"></td><th align="left">Modifying <code class="filename">/etc/sysconfig/*</code> Files Can Damage Your Installation</th></tr><tr><td colspan="2" align="left" valign="top"><p>
Do not modify the <code class="filename">/etc/sysconfig</code> files if you lack
previous experience and knowledge. It could do considerable damage to
your system. The files in <code class="filename">/etc/sysconfig</code> include a
short comment for each variable to explain what effect they actually
have.
</p></td></tr></table></div><div class="figure"><a name="fig.yast2.sysconfig"></a><p class="title"><b>Figure 16.2. System Configuration Using the sysconfig Editor</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.sysconfig">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_sysconfig.png" width="100%" alt="System Configuration Using the sysconfig Editor"></td></tr></table></div></div></div><br class="figure-break"><p>
The YaST sysconfig dialog is split into three parts. The left part of
the dialog shows a tree view of all configurable variables. When you
select a variable, the right part displays both the current selection
and the current setting of this variable. Below, a third window displays
a short description of the variable's purpose, possible values, the
default value and the actual configuration file from which this variable
originates. The dialog also provides information about which
configuration script is executed after changing the variable and which
new service is started as a result of the change. YaST prompts you to
confirm your changes and informs you which scripts will be executed
after you leave the dialog by selecting <span class="guimenu">Finish</span>. Also
select the services and scripts to skip for now, so they are started
later. YaST applies all changes automatically and restarts any
services involved for your changes to take an effect.
</p></div><div class="sect2" title="16.3.2. Changing the System Configuration Manually"><div class="titlepage"><div><div><h3 class="title"><a name="sec.boot.sysconfig.man"></a>16.3.2. Changing the System Configuration Manually<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.boot.sysconfig.man">¶</a></span></h3></div></div></div><p>
To manually change the system configuration, proceed as follows
</p><div class="procedure"><ol class="procedure" type="1"><li><p>
Become <code class="systemitem">root</code>.
</p></li><li><p>
Bring the system into single user mode (runlevel 1) with
<span class="command"><strong>telinit <code class="option">1</code></strong></span>.
</p></li><li><p>
Change the configuration files as needed with an editor of your
choice.
</p><p>
If you do not use YaST to change the configuration files in
<code class="filename">/etc/sysconfig</code>, make sure that empty variable
values are represented by two quotation marks
(<code class="systemitem">KEYTABLE=</code><code class="literal">""</code>) and that
values with blanks in them are enclosed in quotation marks. Values
consisting of one word only do not need to be quoted.
</p></li><li><p>
Execute <span class="command"><strong>SuSEconfig</strong></span> to make sure that the changes
take effect.
</p></li><li><p>
Bring your system back to the previous runlevel with a command like
<span class="command"><strong>telinit
<em class="replaceable"><code>default_runlevel</code></em></strong></span>. Replace
<em class="replaceable"><code>default_runlevel</code></em> with the default runlevel
of the system. Choose <code class="literal">5</code> if you want to return to
full multiuser with network and X or choose <code class="literal">3</code> if
you prefer to work in full multiuser with network.
</p></li></ol></div><p>
This procedure is mainly relevant when changing systemwide settings,
such as the network configuration. Small changes should not require
going into single user mode, but you may still do so to make absolutely
sure that all the programs concerned are correctly restarted.
</p><div class="tip"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Tip: Configuring Automated System Configuration"><tr class="head"><td width="32"><img alt="[Tip]" src="admon/tip.png"></td><th align="left">Configuring Automated System Configuration</th></tr><tr><td colspan="2" align="left" valign="top"><p>
<a class="indexterm" name="id462525"></a> <a class="indexterm" name="id462540"></a> To disable the automated system configuration by
SuSEconfig, set the variable <code class="systemitem">ENABLE_SUSECONFIG</code>
in <code class="filename">/etc/sysconfig/suseconfig</code> to
<code class="literal">no</code>. Do not disable SuSEconfig if you want to use
the SUSE installation support. It is also possible to disable the
autoconfiguration partially.
</p></td></tr></table></div><a class="indexterm" name="id462565"></a><a class="indexterm" name="id462571"></a></div></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.opensuse.reference.html">Reference</a><span class="breadcrumbs-sep"> > </span><a href="part.reference.system.html">System</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 15. 32-Bit and 64-Bit Applications in a 64-Bit System Environment" href="cha.64bit.html"><span>◀</span></a> <a accesskey="n" title="Chapter 17. The Boot Loader GRUB" href="cha.grub.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018