initramfs 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. initramfs 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.

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 initramfs. After the modules are loaded, udev provides the initramfs 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 boot.udev with the command udevtrigger.

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 initramfs. This is done in the same way as with its predecessor, initrd—by calling mkinitrd. Calling mkinitrd without any argument creates an initramfs. Calling mkinitrd -R creates an initrd. In openSUSE®, the modules to load are specified by the variable INITRD_MODULES in /etc/sysconfig/kernel. After installation, this variable is automatically set to the correct value. The modules are loaded in exactly the order in which they appear in INITRD_MODULES. This is only important if you rely on the correct setting of the device files /dev/sd?. However, in current systems you also may use the device files below /dev/disk/ that are sorted in several subdirectories, named by-id, by-path and by-uuid, and always represent the same disk. This is also possible at install time by specifying the respective mount option.

	Updating initramfs or initrd
The boot loader loads initramfs or initrd in the same way as the Kernel. It is not necessary to reinstall GRUB after updating initramfs or initrd, because GRUB searches the directory for the right file when booting.

The main purpose of init on initramfs 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.

When init is called during the initial boot as part of the installation process, its tasks differ from those mentioned above:

In Linux, runlevels define how the system is started and what services are available in the running system. After booting, the system starts as defined in /etc/inittab in the line initdefault. Usually this is 3 or 5. See Table 17.1, “Available Runlevels”. 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.

	Avoid Runlevel 2 with a Partition Mounted via NFS
You should not use runlevel 2 if your system mounts a partition like /usr 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).

To change runlevels while the system is running, enter telinit 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.

Runlevel 5 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.

	Errors in /etc/inittab May Result in a Faulty System Boot
If /etc/inittab is damaged, the system may not boot properly. Therefore, be extremely careful while editing /etc/inittab. Always let init reread /etc/inittab with the command telinit q before rebooting the machine.

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:

When changing into the same runlevel as the current runlevel, init only checks /etc/inittab for changes and starts the appropriate steps, for example, for starting a getty on another interface. The same functionality may be achieved with the command telinit q.

There are two types of scripts in /etc/init.d:

All scripts are located in /etc/init.d. Scripts that are run at boot time are called through symbolic links from /etc/init.d/boot.d. Scripts for changing the runlevel are called through symbolic links from one of the subdirectories (/etc/init.d/rc0.d to /etc/init.d/rc6.d). 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 start and stop. The scripts also understand the restart, reload, force-reload, and status options. These different options are explained in Table 17.2, “Possible init Script Options”. Scripts that are run directly by init do not have these links. They are run independently from the runlevel when needed.

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 /usr/lib/lsb/install_initd, which is a script calling this program). See the insserv(8) man page for details.

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 chkconfig, described in the chkconfig(8) man page.

A short introduction to the boot and stop scripts launched first or last, respectively, follows as well as an explanation of the maintaining script.

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 init, init.d, chkconfig, and insserv. Additionally consult the man pages of startproc and killproc.

	Faulty init Scripts May Halt Your System
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 Section 17.2.1, “Runlevels”.

To create a custom init script for a given program or service, use the file /etc/init.d/skeleton 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.

The INIT INFO block at the top is a required part of the script and must be edited. See Example 17.1, “A Minimal INIT INFO Block”.

### 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

In the first line of the INFO block, after Provides:, specify the name of the program or service controlled by this init script. In the Required-Start: and Required-Stop: 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 Default-Start: and Default-Stop:, specify the runlevels in which the service should automatically be started or stopped. Finally, for Description:, provide a short description of the service in question.

To create the links from the runlevel directories (/etc/init.d/rc?.d/) to the corresponding scripts in /etc/init.d/, enter the command insserv new-script-name. The insserv program evaluates the INIT INFO header to create the necessary links for start and stop scripts in the runlevel directories (/etc/init.d/rc?.d/). 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 Section 17.2.3, “Configuring System Services (Runlevel) with YaST”.

If a script already present in /etc/init.d/ 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.

Do not set these links manually. If something is wrong in the INFO block, problems will arise when insserv is run later for some other service. The manually added service will be removed with the next run of insserv for this script.

After starting this YaST module with YaST+System+System Services (Runlevel), 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 Simple Mode or in Expert Mode. The default Simple Mode 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 Enable. The same steps apply to disable a service.

For detailed control over the runlevels in which a service is started or stopped or to change the default runlevel, first select Expert Mode. The current default runlevel or “initdefault” (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).

This YaST dialog allows the selection of one of the runlevels (as listed in Table 17.1, “Available Runlevels”) 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 (B, 0, 1, 2, 3, 5, 6, and S) 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.

	Faulty Runlevel Settings May Damage Your System
Faulty runlevel settings may make your system unusable. Before applying your changes, make absolutely sure that you know their consequences.

Figure 17.1. System Services (Runlevel)¶

With Start, Stop, or Refresh, decide whether a service should be activated. Refresh status checks the current status. Set or Reset lets you select whether to apply your changes to the system or to restore the settings that existed before starting the runlevel editor. Selecting OK saves the changed settings to disk.

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 sysconfig and restarting services.

	Modifying /etc/sysconfig/* Files Can Damage Your Installation
Do not modify the /etc/sysconfig files if you lack previous experience and knowledge. It could do considerable damage to your system. The files in /etc/sysconfig include a short comment for each variable to explain what effect they actually have.

Figure 17.2. System Configuration Using the sysconfig Editor¶

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 Finish. 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.

To manually change the system configuration, proceed as follows

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.

	Configuring Automated System Configuration
To disable the automated system configuration by SuSEconfig, set the variable ENABLE_SUSECONFIG in /etc/sysconfig/suseconfig to no. Do not disable SuSEconfig if you want to use the SUSE installation support. It is also possible to disable the autoconfiguration partially.