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 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.
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.
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.
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:
Note |
The names of the stop scripts always begin with `K' for kill. Start scripts begin with `S' for start. |
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).
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.
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.
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.
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.
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 started or stopped, respectively, before the service itself is started or stopped.
This information is used later to generate the numbering of script names, as found in the runlevel directories. Under Default-Start: and Default-Stop:, specify the runlevels in which the service should automatically be started or stopped. Finally, under Description:, provide a short description of the service in question.
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.
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.
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.
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:
Note |
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.
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.