Suse 9.x: The Boot process

The boot process of Suse 9 on the ia32 architecture follows the phases typical of every Linux:
- Bios POST a boot device selection (hard disk, in a normal installation). Depends on the hardware.
- Execution of the Linux loader on the Master Boot Record (grub or lilo, usually)
- Kernel loading
- Execution of init and startup of the various services.

Linux loader
SuSE 9 is based on grub as default Linux loader. It uses YaST2 to manage it [System - BootLoader Configuration], storing general configuration data in /etc/grub.conf and information about the booting options in /boot/grub/menu.lst.
The directory /boot/grub/ contains all the configuration files and the binaries.
It's possible to find a copy of the MBR present on the system before the SuSE installation in the file /boot/backup_mbr.
The always useful Memtest tool, which can be chosen as boot option, is placed in /boot/memtest.bin
The mapping of devices and their names is in /boot/grub/device.map.

Kernel
The defaut kernel is /boot/vmlinuz which actually is a link to a file named boot/vmlinuz-kernelversion. Similar symlinking is done for the /boot/initrd.
Kernel modules are placed in /lib/modules/kernelversion

Init
SuSe 9 conforms to the Linux Standard Base (LSB) for the whole initialization phase: the usual /etc/inittab defines what to execute at the different run-levels of the system, in /etc/init.d are stored all the startup and shutdown scripts for the various services, which are managed by the symlinks in the /etc/rc.d/rc.runlevel directories.
An useful sample file for building own startup scripts is /etc/init.d/skeleton which provides all the references and a base structure for a fully integrated script.
Once created a script you can generate all the rc symlinks structure with the command insserv or using YaST2's runlevel editor [System - Runlevel Editor].
The runlevels have common meanings: 0- halt, 1- single user mode, 3- multiuser with network, 5- multiuser with network and xdm graphical login, 6-reboot.
Most of the startup options can be set editing the files in /etc/sysconfig which can be also modified with YaST2 [System - /etc/sysconfig Editor]. Note that many important settings of the system (the typical ones you never know how are managed) can be easily be defined with this graphic interface or editing directly the files in /etc/sysconf.
When you manually edit them, sunce they can influence the creation of other system's configuration files, you should run SuSEconfig to validate and apply the new configurations (this is done automatically whenever you exit from YaST2).
Some scripts are always executed at the startup (except when operating in emergency mode), before entering any runlevel:
/etc/init.d/boot
- Exports the environment variables LINES COLUMNS CONSOLE;
- Sources the script /etc/rc.status which contains all the functions used in the boot script messages;
- Loads the (useful) boot configuration file /etc/sysconfig/boot where are defined variables that affect the boot sequence (prompt for user confirmation, pallalelizing of services statup, possibility to stop the boot process...)
- Mounts the /proc and /dev/pty file systems;
- Asks for interactive boot mode (if $PROMPT_FOR_CONFIRM=yes);
- Starts blogd wich logs the boot messages in /var/log/boot.msg;
- Checks the symlinks in the /etc/init.d/boot.d/ directory which point, with an elegant logic similar to the rc one (S for starting scripts, K for killing scripts), to various scripts which are executed in the following order (they are all started, by default):
/etc/init.d/boot.proc sets some /proc parameters as Magic SysRq Key according to what is configured in /etc/sysconfig/sysctl;
/etc/init.d/setserial provides serial ports configuration and has pre-set (commented) entries for various multiport boards;
/etc/init.d/boot.md handles the multiple devices (used for software Raid);
/etc/init.d/boot.lvm manages Logical Volumes (checking /etc/sysconfig/lvm for additional configuration);
/etc/init.d/boot.localfs checks and mounts the local file systems (here the boot can be interrupted if there's a file system check failure);
/etc/init.d/boot.crypto enables and mounts crypto file systems;
/etc/init.d/boot.loadmodules load modules required to be loaded in specific order;
/etc/init.d/boot.restore_permissions restores devices permissions after a crash;
/etc/init.d/boot.scpm manages System's Profiles with scpm, a nice SuSE GPL  utility that manages different profiles to be chosen at boot (typically network settings, but not only, since the user can decide what scripts have to be executed for each profile). It can be configured with YaST;
/etc/init.d/boot.swap enables swap partitions and the Shared Memory File System (SHM);
/etc/init.d/boot.clock sets CMOS clock;
/etc/init.d/boot.idedma activates DMA mode on IDE devices according to what is configured in /etc/sysconfig/hadware;
/etc/init.d/boot.ldconfig runs, if needed, ldconfig to rebuild links and caches of shared libraries;
/etc/init.d/boot.isapnp initializes Isa Plug and Play devices;
/etc/init.d/boot.localnet sets up hostname, loopback interface and YP bindings;
/etc/init.d/boot.sched sets kernel's scheduling timeslices according to what is configured in /etc/sysconfig/kernel
/etc/init.d/boot.ipconfig sets typical network settings as IP forwarding, TCP syncookies for syn-flood protection according to what is configured in /etc/sysconfig/sysctl (network IP settings are later defined when starting the /etc/init.d/network script, according to the selected runlevel) ;
/etc/init.d/boot.klog writes kernel boot messages to /var/log/boo.msg.
At its end, the /etc/init.d/boot script runs /etc/init.d/boot.local where the administrator can place custom scripts to run before entering into any runlevel.
What follows depend on the services installed and the decision to run them at the boot runlevel according to the rc directories in /etc/init.d. Note that there still exist a /etc/rc.d directory, but it's a simple symlink to /etc/init.d.

Services
To manage services it's possibile to invoke directly the relative script or use the rcservice commands. For example:
[root@vagante al]# rcsnmpd start
does the same (starting the SNMP daemon) of:
[root@vagante al]# /etc/init.d/snmpd start
since /usr/sbin/rcsnmpd is actually a symlink to /etc/init.d/snmpd.

Privacy Policy