Linux System Startup and Shutdown

This post is about the Linux boot process and initrd (initial RAM disk). The Linux boot process works in this order:

· BIOS/UEFI

· MBR

· GRUB

· Initrd

· Linux Kernel

· Running system

BIOS (Basic Input/Output System) and UEFI (Unified Extensible Firmware Interface) deal with the hardware and probe which hardware onboard devices are present in the system. The BIOS displays the POST (Power On Self Test) screen which contains necessary information regarding the devices and whether an error is encountered during the booting process. The POST screen is usually hidden in modern systems, so it is recommended that you configure the BIOS to display the POST screen. The BIOS/UEFI activates the onboard hardware. When the BIOS/UEFI finishes loading, it passes control over to the MBR (Master Boot Record).

The MBR is contained in the first 512 bytes of the first HD sector. This is where control is passed from the BIOS/UEFI. The traditional BIOS way is to pass the control over to MBR which usually contains a bootloader, GRUB (Grand Unified Bootloader) in the case of Linux, and partition information. As the MBR resides in a very small area, only the bare minimum information about where the kernel of the OS is loaded can be stored in it.

GRUB or now GRUB2 supersedes LILO (Linux Loader) which was the original Linux bootloader. GRUB runs from MBR but it can access the hard disk to load additional boot related information like additional devices. This way control can be redirected to other partitions making GRUB2 a versatile choice for modern systems. The GRUB2 passed control over to the Linux Kernel or the initrd portion of the Linux Kernel.

Initrd loads utilities in the RAM (Random Access Memroy) which enables a user to troubleshoot the system should a problem arise. The initrd also probes the hardware devices attached and loads the relevant modules or drivers in the Linux Kernel. This solves the problem of ‘kitchen sink’ kernels where initrd acts as a minimal Linux Kernel, which simply detects what kernel modules to load, then hands off control to the main Kernel. Initrd can mount hard disks. The control is then passed to the actual Linux Kernel which boots either in the CLI, command-line interface, or the GUI, graphical user interface.

Kernel loads and starts a program called init. Linux init is a program which starts all other programs which will run on the Linux system. The PID, process identification number, of init is always 1. When loading the Linux Kernel, additional commands can be passed which can modify the behavior of the Linux Kernel.

Single user mode is like a safe mode of Microsoft Windows OS. It enables the user to troubleshoot the system in case of an error, run diagnostics and perform system maintenance. Single user mode is CLI mode. A user in a single user mode can change root user account password. This is why for a secure Linux installation, a GRUB2 password disallowing changes to the arguments passed to the loading kernel and installing an encrypted filesystem is always a recommended practice.

Task: How to get into single user mode, or disable USB (Universal Serial Bus) devices etc

Reboot the system and when the GRUB2 menu is displayed, hit a key. Press ‘a’. Locate the line where the ‘vmlinuz’ loads and type ‘single’ at the end of the line and press enter. The Linux Kernel will boot in single user mode. This is not persistent and will switch to default behavior on the next system reboot. Reboot and see that this is not pervasive. Various other arguments can also be passed like the ‘single’ argument. Read the relevant system documentation to see what options are available.

Now we come to the init system itself. Traditionally the system which was incorporated in the Linux Kernel was the SysVinit system. Ubuntu introduced a system called Upstart. The current trend for all major distribution is to switch to a system called Systemd.

As Linux has its roots from BSD systems, it is important to learn how BSD init process works.

The BSD init process contains a lot of .sh scripts. The init system works like a Microsoft Windows Startup folder. This approach is not very flexible.

The following table lists a comparative analysis of the 3 Linux init systems:

SysVinit

Upstart

Systemd

Runlevels

Ubuntu uses this

Most distributions now use this

Numbered order of loading programs

Faster startup

Faster

Lots of symlinks

Start order is not just numerical

Start order not just numerical

Not overly efficient start time (one program starts and then the other)

Backward compatible

Not as compatible

init.d folder contains all the scripts

Uses binary code, not just scripts

Runlevels explained, changing runlevels and default runlevel

Runlevels are the states a Linux Kernel can be in and the services which a particular state offers. Historically 7 runlevels, from 0–6, are available. A comparison chart for Debian vs. CentOS is given below:

Debian/Ubuntu

CentOS/SUSE

0

Halt

0

Halt

1

Single-user mode

1

Single-user mode

2

Full, multi-user, GUI if installed

2

Multi-user without net

3–5

Nothing

3

Multi-user with net — servers usually use this

6

Reboot

4

Nothing

5

Multi-user GUI

6

Reboot

Manage runlevels using SysVinit

Managing runlevels with SysVinit is easy. We just have to issue a single command and the system will change its state.

Changing runlevels

Two commands can be used for this purpose: telinit and init. Init is not standard and it actually calls telinit which changes the runlevel.

Telinit 0 # Makes the system go to halt or power off state

Telinit 6 # Reboots the system

Runlevel commands tell us which runlevel we are in. It shows the previous and current runlevels as the output. If telinit is used, the changes are not persistent and the system will reboot to the default configuration. If the default is to be changed then we must edit the /etc/inittab file.

Changing Default runlevel

vi /etc/inittab

Modify initdefault argument.

Systemd Boot Targets

Boot targets vs. runlevels

Switching targets

Default targets

Runlevel

Boot Target

0

Power off

1

Rescue

2

Multi-user

3

Multi-user

4

Nothing

5

Graphical

6

Reboot

boot targets are just names and can be anything

Systemd Tools

Systemctl enable

Systemstl start

manageing system boot targets

systemctl isolate multi-user.target

systemctl get-default

systemctl set-default graphical.target

Boot Target Locations

/etc/system/system/

/usr/lib/system/system

Boot targets can be guessed by the name. Understanding the equivalents with runlevels is important.

Proper way to reboot and halt system

The following commands can reboot or shutdown the system.

reboot, poweroff, halt

shutdown & wall

telinit 0

systemctl isolate poweroff.target

telinit 6

systemctl isolate reboot.target

Optional Tools

halt sometimes doesn’t power off

poweroff ACPI power off

reboot reboots

reboot –f NO! (killing of processes)

The first 3 rely on the underlying init system to shutdown properly

shutdown | wall

echo “message: | wall (sends to all the terminals)

shutdown –r now

shutdown –h +2

shutdown –P 13:26

shutdown –P +3 “Alas, the end is near!” (wall built-in)