Arguably the most important piece of an operating system is the kernel. The kernel manages hardware resources and software processes. The kernel is started by some tiny glue between the system BIOS (Basic Input/Output System) and the kernel, called the bootloader. The bootloader handles the complications that come with loading a specific (or less specific) kernel.

Most bootloader actually work in two stages. The first stage loader loads the second stage loader, that does the real work. The boot loader is divided in two stages on x86 machines, because the BIOS only loads one sector (the so-called boot sector) that is 512 bytes in size.

Slackware Linux uses the LILO (LInux LOader) boot loader. This bootloader has been in development since 1992, and is specifically written to load the Linux kernel. Lately LILO has been replaced by the GRUB (GRand Unified Bootloader) in most GNU/Linux distributions. GRUB is available as an extra package on the Slackware Linux distribution media.

# Start LILO global section
boot = /dev/sda 
#compact        # faster, but won't work on all systems.
prompt 
timeout = 50 
# Normal VGA console
vga = normal 
      

image = /boot/vmlinuz 
  root = /dev/sda5  
  label = Slack 
  read-only 
      

# lilo
Added Slack26 *
Added Slack
      

After the kernel is loaded and started, the kernel will start the init command. init is the parent of all processes, and takes care of starting the system initialization scripts, and spawning login consoles through agetty. The behavior of init is configured in /etc/inittab.

The /etc/inittab file is documented fairly well. It specifies what scripts the system should run for different runlevels. A runlevel is a state the system is running in. For instance, runlevel 1 is single user mode, and runlevel 3 is multi-user mode. We will have a short look at a line from /etc/inittab to see how it works:

rc:2345:wait:/etc/rc.d/rc.M
    

This line specifies that /etc/rc.d/rc.M should be started when the system switches to runlevel 2, 3, 4 or 5. The only line you probably ever have to touch is the default runlevel:

id:3:initdefault:
    

In this example the default runlevel is set to 3 (multiuser mode). You can set this to another runlevel by replacing 3 with the new default runlevel. Runlevel 4 can particularly be interesting on desktop machines, since Slackware Linux will try to start the GDM, KDM or XDM display manager (in this particular order). These display managers provide a graphical login, and are respectively part of GNOME, KDE and X11.

Another interesting section are the lines that specify what command should handle a console. For instance:

c1:1235:respawn:/sbin/agetty 38400 tty1 linux
    

This line specifies that agetty should be started on tty1 (the first virtual terminal) in runlevels 1, 2, 3 and 5. The agetty command opens the tty port, and prompts for a login name. agetty will then spawn login to handle the login. As you can see from the entries, Slackware Linux only starts one console in runlevel 6, namely tty6. One might ask what happened to tty0, tty0 certainly exists, and represents the active console.

Since /etc/inittab is the right place to spawn agetty instances to listen for logins, you can also let one or more agetties listen to a serial port. This is especially handy when you have one or more terminals connected to a machine. You can add something like the following line to start an agetty instance that listens on COM1:

s1:12345:respawn:/sbin/agetty -L ttyS0 9600 vt100
    

As explained in the init (Section 19.2, “init”) section, init starts some scripts that handle different runlevels. These scripts perform jobs and change settings that are necessary for a particular runlevel, but they may also start other scripts. Let's look at an example from /etc/rc.d/rc.M, the script that init executes when the system switches to a multi-user runlevel:

# Start the sendmail daemon:
if [ -x /etc/rc.d/rc.sendmail ]; then
  . /etc/rc.d/rc.sendmail start
fi
    

These lines say “execute /etc/rc.d/rc.sendmail start if /etc/rc.d/rc.sendmail is executable”. This indicates the simplicity of the Slackware Linux initialization scripts. Different functionality, for instance network services, can be turned on or off, by twiddling the executable flag on their initialization script. If the initialization script is executable, the service will be started, otherwise it will not. Setting file flags is described in Section 8.5.2, “Changing file permission bits”, but we will have a look at a quick example how you can enable and disable sendmail.

To start sendmail when the system initializes, execute:

# chmod +x /etc/rc.d/rc.sendmail
    

To disable starting of sendmail when the system initializes, execute:

# chmod -x /etc/rc.d/rc.sendmail
    

Most service-specific initialization scripts accept three parameters to change the state of the service: start, restart and stop. These parameters are pretty much self descriptive. For example, if you would like to restart sendmail, you could execute:

# /etc/rc.d/rc.sendmail restart
    

If the script is not executable, you have to tell the shell that you would like to execute the file with sh. For example:

# sh /etc/rc.d/rc.sendmail start
    

Slackware Linux has supported hotplugging since Slackware Linux 9.1. When enabled, the kernel passes notifications about device events to a userspace command. Since Slackware Linux 11.0, the udev set of utilities handle these notifications. udev manages the dynamic /dev directory as well.

The mode of operation of udev for handling hotplugging of devices is fairly simple. When a device is added to the system, the kernel notifies userspace hotplug event listeners. udev will receive the notification of the device being added, and looks whether there are any module mappings for the device. If there are, the appropriate device driver module for the device is automatically loaded. udev will remove the module when it is notified of a device removal, and no devices use the loaded module anymore.

The udev subsystem is initialized in /etc/rc.d/rc.S by executing /etc/rc.d/rc.udev start. As with most functionality, you can enable or disable udev by twiddling the executable flag of the /etc/rc.d/rc.udev script (see Section 19.3, “Initialization scripts”).

If udev automatically loads modules that you do not want to load, you can add a blacklist in your modprobe configuration in /etc/modprobe.d/blacklist. For example, if you would like to prevent loading of the 8139cp module, you can add the following line (actually, this module is already blacklisted in Slackware Linux):

blacklist 8139cp