next up previous contents index
Next: Network Up: System Previous: Special Features of SuSE   Contents   Index

Subsections


The SuSE Linux Boot Concept

Booting and initializing a UNIX system can challenge even an experienced system administrator. This chapter gives a short overview of the SuSE Linux boot concept. The new implementation is compatible with the System Initialization section of the LSB specification (Version 1.3.x). Refer to 11 for more information about LSB.

The simple words Uncompressing Linux... signal that the kernel is taking control of your hardware. It checks and sets your console -- more precisely: the BIOS registers of graphics cards and output format -- to read BIOS settings and to initialize basic hardware interfaces. Next, your drivers ``probe'' existing hardware and initialize it accordingly. After checking the partitions and mounting the root file system, the kernel starts init, which ``boots'' (Unix jargon) the main system with all its programs and configurations. The kernel controls the entire system, including hardware access and the CPU time programs use.


The init ProgramThe init Program

The program init is the process responsible for initializing the system itself in the required way. All other processes are considered child processes of init.

init takes a special role. It 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.

init is centrally configured via the /etc/inittab file. Here, the ``runlevels'' are defined (see 12). It also specifies which services and daemons are available in each of the levels.

Depending on the entries in /etc/inittab, several scripts are run by init. For reasons of clarity, these scripts all reside in the directory /etc/init.d.

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 whose task it is to maintain all other processes and to adjust CPU time and hardware access according to requests from other programs.


Runlevels

In Linux, runlevels define how the system is started. After booting, the system starts as defined in /etc/inittab in the line initdefault. Usually this is 3 or 5 (see Table 12.1). An alternative to this is assigning a special runlevel at boot time (e.g. , at the boot prompt). The kernel passes any parameters it does not need directly to init.

To change runlevels while the system is running, enter init and the corresponding number as an argument. Only the system administrator is allowed to do this.

init 1 (or shutdown now) causes the system to change to single user mode, which is used for system maintenance and administration. After finishing his work, the administrator can switch back to the normal runlevel by entering init 3, which starts all the essential programs and allows regular users to log in and to work with the system. On the other hand, init 0 (or shutdown -h now) causes the system to halt. init 6 (or shutdown -r now) causes it to shut down with a subsequent reboot.


Note


[Runlevel 2 with a /usr/ Partition Mounted via NFS] You should not use runlevel 2 if your system mounts the /usr partition via NFS. The /usr directory holds important programs essential for the proper functioning of the system. Because the NFS service is not made available by runlevel 2 (local multiuser mode without remote network), the system would be seriously restricted in many aspects.


\begin{longtable}
% latex2html id marker 17823{p{.17\linewidth}p{.77\linewidt...
...M \\
6 & System reboot \\
& \\
\caption{Available Runlevels}
\end{longtable}

Runlevel 5 is the default runlevel in all SuSE Linux standard installations. Users are prompted for login directly under a graphical interface.

If you have already installed and configured the X Window System properly as described in 5) and want users to log in via a graphical user interface, change the runlevel to 5. Try it first by typing init 5 to see whether the system works as expected. If it does, use YaST to set the default runlevel to 5.


Caution


[Modifying /etc/inittab] If /etc/inittab is damaged, the system might not boot properly. Therefore, be extremely careful while editing /etc/inittab and always keep a backup of an intact version. To repair damage, try entering init=/bin/sh after the kernel name at the boot prompt to boot directly into a shell. After that, replace /etc/inittab with your backup version using the cp command.


Changing Runlevels

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 will be 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 (e.g. , for starting a getty on another interface).


Init Scripts

Scripts in /etc/init.d are divided into two sections:

All scripts are located in /etc/init.d. Scripts for changing the runlevel are also found there, but are called via symbolic links from one of the subdirectories (/etc/init.d/rc0.d to /etc/init.d/rc6.d). This is just for clarity reasons and avoids duplicate scripts (e.g. , 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 understand, in addition, the ``restart'', ``reload'', ``force-reload'', and ``status'' options. These different options are explained in Table12.2.


\begin{longtable}
% latex2html id marker 17920{p{.27\linewidth}p{.67\linewidt...
...tus of service. \\
& \\
\caption{Possible init Script Options}
\end{longtable}

Links in each runlevel-specific subdirectory make it possible to associate scripts with different runlevels. When installing or uninstalling packages, such 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 [8]insserv for details.

Below is a short introduction to the boot and stop scripts launched first (or last, respectively) as well as an explanation of the maintaining script.

boot
Executed while starting the system directly using init. It is independent of the chosen runlevel and is only executed once. Here, the proc and pts file systems are mounted and the 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.

The blogd daemon is a service started by the boot and by the rc scripts before any other one. It is stopped after the actions triggered by the above scripts are completed (e.g., after running a number of subscripts). The blogd daemon writes any screen output to the log file /var/log/boot.msg -- but only if and when /var is mounted read-write. Otherwise, blogd buffers all screen data until /var becomes available. Further information about blogd can be obtained with man blogd.

The script boot is also responsible for starting all the scripts in /etc/init.d/boot.d with a name that starts with `S'. 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. Last executed is the script boot.local.

boot.local
Here, enter additional commands to execute at boot before changing into a runlevel. It can be compared to AUTOEXEC.BAT on DOS systems.

boot.setup
This script is executed when changing from single user mode to any other runlevel and is responsible for a number of basic settings, namely for the keyboard layout and for initializing the virtual consoles.
halt
This script is only executed while changing into runlevel 0 or 6. Here, it is executed either as halt or as reboot. Whether the system shuts down or reboots depends on how halt is called.
rc
This script calls the appropriate stop scripts of the current runlevel and the start scripts of the newly selected runlevel.


Adding init Scripts

You can create your own scripts and easily integrate them into the scheme described above. For instructions about the formatting, naming, and organization of your custom scripts, refer to the specifications of the LSB and to the man pages of init, init.d, and insserv. Additionally consult the man pages of startproc and killproc.


Caution


[Creating Your Own init Scripts] Faulty init scripts may freeze your machine. Edit such scripts with great care and, if possible, subject them to heavy testing in the multiuser environment. Some useful information about init scripts can be found in 12.

On the other hand, 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, either 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 will be started automatically.


The YaST Runlevel Editor

After starting this YaST module, it displays overview listing all the available services and the current status of each service -- whether they are enabled or not. With the radio buttons, decide whether to use the module in ` Simple Mode' or in ` Expert Mode'. The default ` Simple Mode' should be sufficient for most purposes. The leftmost column shows the name of the service, the center column indicates its current status, and the right-hand 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 tabl then select ` Enable'. The same steps apply to disable a service.

Figure 12.1: YaST: Runlevel Editor
\includegraphics[width=.7\linewidth]{yast2_runlevel}

For detailed control over the runlevels in which a service is started or stopped or to change the default runlevel, first select ` Expert Mode'. This mode displays the current default runlevel or ``initdefault'', which means the runlevel into which the system boots by default. Normally, the default runlevel of a SuSE Linux system is runlevel 5 (full multiuser mode with network and XDM). A suitable alternative might be runlevel 3 (full multiuser mode with network).

This YaST dialog allows selection of one of the runlevels (as listed in Table 12.1) 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, tells 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 where the selected service or daemon should be running. Runlevel 4 is always undefined to allow for the creation of a custom runlevel. Finally, a brief description of the currently selected service or daemon is provided just below the table overview.

With ` Start' and ` Stop', decide whether a server should be implemented. Check the current status is checked via ` Update', if this has not already been done automatically. ` Reset to Default Value' restores the settings to their default state. ` Activate Service' only appears if the service is currently disabled. ` Finish' saves the system configuration.


Caution


[Changing Runlevel Settings]Faulty runlevel settings may render a system unusable. Before applying your changes, make absolutely sure you know about their consequences.


SuSEconfig and /etc/sysconfig

The main configuration of SuSE Linux can be done via the configuration files in /etc/sysconfig. Former versions of SuSE Linux relied on /etc/rc.config for system configuration, but it became obsolete in previous versions. /etc/rc.config will not be created at installation time, as all system configuration is controlled via /etc/sysconfig. However, if /etc/rc.config exists at the time of a system update, it will remain intact.

The individual files in /etc/sysconfig are only read by the scripts to which they are relevant. This ensures that network settings, for instance, need to be parsed only by network-related scripts. Apart from that, there are many other system configuration files that are generated according to the settings in /etc/sysconfig. This task is performed by SuSEconfig. For example, if you change the network configuration, SuSEconfig is likely to make changes to the file /etc/host.conf as well, as this is one of the files relevant for the network configuration.

If you change anything in these files manually, run /sbin/SuSEconfig afterwards to make sure all the necessary changes are made in all the relevant places. If you change the configuration using the YaST sysconfig editor, all changes are applied automatically -- YaST automatically starts SuSEconfig to update the configuration files as needed.

This concept enables you to make basic changes to your configuration without needing to reboot the system. BEcause some changes are rather complex, some programs must be restarted for the changes to take effect. For instance, changes to the network configuration may require a restart of the network programs concerned. This can be achieved by entering the commands rcnetwork stop and rcnetwork start.

The recommended way to change the system configuration includes the following steps:

This procedure is mainly relevant if you have changed system-wide settings (such as network configuration). It is not necessary to go into single user mode for small changes, but it ensures all relevant programs are correctly restarted.


Tip

To disable the automatic configuration of 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.


The YaST sysconfig Editor

The files where the most important SuSE Linux settings are stored are located in the /etc/sysconfig directory. The sysconfig editor presents the settings options in an easy-to-read manner. The values can be modified and subsequently added to the individual configuration files in this directory. In general, it is not necessary to edit them manually, however, because these files are automatically adjusted when installing a package or configuring a service.


Caution


[Modifications of /etc/sysconfig/ files] 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.

The YaST sysconfig dialog is split into three parts. The left part of the dialog window shows a tree view of all configurable variables. As soon as you have selected 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 asks you to confirm your changes and informs you which scripts will be executed after leaving the dialog by selecting ` Finish'. Also select the services and scripts to skip for now, so they are started later.


next up previous contents index
Next: Network Up: System Previous: Special Features of SuSE   Contents   Index
root 2003-11-05