System Startup, Init, and Service Management

System startup is the complete sequence of events that occurs between pressing the power button and seeing a login prompt. For a beginner, think of it as a chain of smaller programs that each hand off control to the next, like runners passing a baton in a relay race.

The very first thing that happens is the power supply sends a signal to the motherboard. The motherboard wakes up the BIOS (Basic Input/Output System) or its modern replacement, UEFI (Unified Extensible Firmware Interface). The BIOS or UEFI is firmware: a tiny operating system stored on a chip on the motherboard. Its job is to perform a POST (Power-On Self Test) to check that hardware like RAM and the CPU are working. If the POST fails, the system beeps or shows an error code. Once POST passes, the firmware looks for a bootable device: usually the first hard drive, but it could be a USB stick, a DVD, or a network card. It reads the first 512 bytes of that device, called the Master Boot Record (MBR) or the GUID Partition Table (GPT) header, depending on whether you use legacy BIOS or modern UEFI.

The next step is the bootloader. The bootloader is a small program that finds and loads the Linux kernel into memory. The most common bootloader on Linux systems is GRUB (GRand Unified Bootloader). GRUB presents a menu that lets you choose which kernel to boot or which operating system to run if you have a dual-boot setup. GRUB also lets you pass parameters to the kernel, like 'nomodeset' for driver issues or 'single' for single-user mode for recovery. Once you make your selection, GRUB loads the kernel and an initial RAM filesystem called initramfs (initial RAM filesystem). The initramfs is a tiny filesystem loaded into RAM that contains drivers and tools needed to mount the real root filesystem. The kernel starts executing and uses the initramfs to load drivers for your storage controller, filesystem types (like ext4 or XFS), and any other hardware needed to access the root filesystem.

Once the kernel can access the real root filesystem, it mounts it (makes it available at the '/' directory). Then the kernel looks for the first user-space process: the init process. The init process is always process ID 1 (PID 1), and it is the ancestor of every other process on the system. On older Linux systems, this was SysV init, which started services one at a time using shell scripts in '/etc/rc.d'. On modern systems, it is systemd, which starts services in parallel and manages them through units (files that describe a service, socket, mount point, or other resource).

The init process then reads its configuration to decide which services to start. Services include everything from the network manager (which gets your IP address) to a web server (like Apache or Nginx) to the SSH daemon that lets you log in remotely. The init system also handles dependencies: for example, it will not start the PostgreSQL database service until the network is running, because a database that cannot listen on a network port is useless.

The last step is to start a login manager or getty (a program that provides a terminal login prompt). At this point, the system is fully booted and ready for use.

Understanding this sequence matters because boot failures are common. The kernel might panic (crash) if it cannot find the root filesystem. The init might fail if a critical service like the filesystem mount is corrupt. A competent LPIC-2 candidate must know how to interrupt the boot process to drop into a recovery shell, how to repair GRUB, and how to switch from systemd back to SysV init if needed. You must also understand the different runlevels or targets that control which services run. In SysV init, runlevels are numbers (0 for halt, 1 for single-user, 3 for multi-user with network, 5 for graphical, 6 for reboot). In systemd, these are 'targets' like poweroff.target, rescue.target, multi-user.target, and graphical.target.

An IT professional working for a medium-sized e-commerce company gets a call at 2 AM: the payment processing server is not responding. Customers cannot check out. The professional first tries to ping the server: no response. They walk to the datacenter (or log in via a remote management card called IPMI or iLO) and see the server is powered on but stuck at a black screen with a blinking cursor. This is a classic boot failure.

The professional reboots the server and watches the console output. They see the POST pass. They see GRUB load. But then the screen fills with kernel panic messages: 'VFS: Unable to mount root fs on unknown-block(0,0)'. This means the kernel found its initramfs but could not mount the real root filesystem. The cause could be a corrupted initramfs, a wrong root= parameter in GRUB, or a filesystem error on the disk.

The professional presses 'e' at the GRUB menu to edit the boot parameters. They add 'single' to the end of the kernel line to boot into single-user mode (recovery mode). The system boots to a root shell. From here, they check the GRUB configuration file at '/boot/grub/grub.cfg' and confirm the root= parameter points to the correct partition, for example '/dev/sda2'. They then run 'fsck' (filesystem check) on that partition to repair any errors. After repair, they reboot and the server comes online normally.

In a different scenario, the professional is migrating an old server from CentOS 6 (which used SysV init) to CentOS 7 (which uses systemd). They must rewrite old init scripts as systemd unit files. They create a file 'myapp.service' in '/etc/systemd/system/' that looks like:

Then they run 'systemctl enable myapp.service' and 'systemctl start myapp.service'. They must also know how to migrate old 'chkconfig' commands to 'systemctl' and how to check the boot time of services using 'systemd-analyze blame'.

The professional also sets up a custom boot splash screen for the company's point-of-sale (POS) terminals, which run a stripped-down Linux. They modify the GRUB configuration to add a 'quiet' splash parameter, which hides kernel messages and shows a company logo. Later, when a POS terminal fails to boot, they remove the 'quiet' flag to see the actual error messages during boot, which speeds up troubleshooting.