Boot processing in linux

Linux Boot Process Explained Step by Step in Detail

Table of Contents

In this article I will give you an step by step overview of Linux boot process with some flowchart diagrams which can help you understand better.

Stages of Linux Boot Process (flowchart)

• BIOS Stage
• Boot Loader Stage
• Kernel Stage

1. BIOS Stage

• When the machine is powered on BIOS is the first one to be called to verify if the hardware is present in the machine and if it is functioning.
• This is done by performing a Power On Self Test (POST)
• After a successful test, BIOS checks the MBR (Master Boot Record) in the hard disk to check if it refers to the location of the boot loader.

2. Boot Loader Stage

The boot loader will be installed if an operating system is installed on the system.

Two of the most common boot loaders are

• The boot loader will present the user with a list of menu entries, each of which corresponds to different operating system
• The boot loader will then start to boot the operating system
• When you select the the option to start Linux, it decompresses the Linux kernel in memory
• After that Linux kernel (which you selected to boot from) loads initrd (Initial ramdisk)
• The initrd is used by the Linux kernel as a temporary filesystem in the memory
• It contains tools and kernel modules which will continue the boot process including mounting a virtual root file system temporarily.
• Instead of using initrd, some Linux filesystem will also use initramfs.
• It serves the same purpose of initrd, it is just that it is a successor of initrd
• linuxrc is an executable file that is next spawn, it probes the mass storage hardware and finds a suitable kernel module to drive the mass storage hardware
• This is required to prepare the real root filesystem to be mounted by the Linux kernel

3. Kernel Stage

• In the kernel stage of the Linux boot sequence, the Linux kernel based on the result of linuxrc can then mount the real root file system
• The real root file system in Linux is referenced as «/» and it is where all other sub directory and files visible when Linux is running exist
• The kernel will then spawn the init process, this process always has the process identifier (PID) as «1» because it is the first background process or daemon started by the kernel upon boot
• All other background daemons are spawned from the init process
• So the init process will load other system daemons depending upon the configuration of different runlevel

For example:

• If the system boots into runlevel 3 then the init process will start all the daemons from this runlevel.

Lastly I hope the Linux Boot process explained using flowchart in this article was helpful. So, let me know your suggestions and feedback using the comment section.

Related Posts

Didn’t find what you were looking for? Perform a quick search across GoLinuxCloud

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

For any other feedbacks or questions you can either use the comments section or contact me form.

Thank You for your support!!

6 thoughts on “Linux Boot Process Explained Step by Step in Detail”

This is the best explanation I’ve ever seen in the Internet for the Linux boot process.

Hi there, I read your new stuff like every week.
Your story-telling style is awesome, keep doing what you’re doing!

Is the arrow from bootloader to initrd correct? You say “After that Linux kernel creates initrd”
So the arrow should go from kernel to initrd, shouldn’t it?

Thank you for highlighting, the text can be little confusing here so I reworded it. The flow chart is correct. The Linux kernel doesnot creates initrd, instead initrd is part of kernel whichcontains important binaries to load virtual file system and detect the hardware to proceed with the boot up.

Источник

A Basic Guide to Linux Boot Process

Every time you power on your Linux PC, it goes through a series of stages before finally displaying a login screen that prompts for your username or password. There are 4 distinct stages that every Linux distribution goes through in a typical boot-up process.

User Login Prompt

In this guide, we will highlight the various steps taken by the Linux OS from the time it is powered on to the time you log in. Kindly note that this guide only takes into consideration the GRUB2 bootloader and systemd init as they are currently in use by a vast majority of modern Linux distributions.

The booting process takes the following 4 steps that we will discuss in greater detail:

• BIOS Integrity check (POST)
• Loading of the Boot loader (GRUB2)
• Kernel initialization
• Starting systemd, the parent of all processes

1. The BIOS Integrity Check (POST)

The boot process is usually initialized when a user presses the power-on button – if the PC was already shut down – or reboots the system using either the GUI or on the command line.

When the Linux system powers up, the BIOS (Basic Input Output System) kicks in and performs a Power On Self Test (POST). This is an integrity check that performs a plethora of diagnostic checks.

The POST probes the hardware operability of components such as the HDD or SSD, Keyboard, RAM, USB ports, and any other piece of hardware. If some hardware device is not detected, or if there’s a malfunction in any of the devices such as a corrupt HDD or SSD, an error message is splashed on the screen prompting your intervention.

In some cases, a beeping sound will go off especially in the event of a missing RAM module. However, if the expected hardware is present and functioning as expected, the booting process proceeds to the next stage.

2. The Bootloader (GRUB2)

Once the POST is complete and the coast is clear, the BIOS probes the MBR (Master Boot Record) for the bootloader and disk partitioning information.

The MBR is a 512-byte code that is located on the first sector of the hard drive which is usually /dev/sda or /dev/hda depending on your hard drive architecture. Note, however, that sometimes the MBR can be located on a Live USB or DVD installation of Linux.

There are 3 main types of bootloaders in Linux: LILO, GRUB, and GRUB2. The GRUB2 bootloader is the latest and primary bootloader in modern Linux distributions and informs our decision to leave out the other two which have become antiquated with the passage of time.

GRUB2 stands for GRand Unified Bootloader version 2. Once the BIOS locates the grub2 bootloader, it executes and loads it onto the main memory (RAM).

The grub2 menu allows you to do a couple of things. It allows you to select the Linux kernel version that you’d want to use. If you have been upgrading your system a couple of times, you might see different kernel versions listed. Additionally, it gives you the ability to edit some kernel parameters by pressing a combination of keyboard keys.

Select Kernel Version

Also, in a dual-boot setup where you have multiple OS installations, the grub menu allows you to select which OS to boot into. The grub2 configuration file is the /boot/grub2/grub2.cfg file. GRUB’s main objective is to load the Linux kernel onto the main memory.

3. Kernel Initialization

The kernel is the core of any Linux system. It interfaces the PC’s hardware with the underlying processes. The kernel controls all the processes on your Linux system. Once the selected Linux kernel is loaded by the bootloader, it must self extract from its compressed version before undertaking any task. Upon self-extracting, the selected kernel mounts the root file system and initializes the /sbin/init program commonly referred to as init.

Kernel Initialization Process

Init is always the first program to be executed and is assigned the process ID or PID of 1. It’s the init process that spawns various daemons & mounts all partitions that are specified in the /etc/fstab file.

The kernel then mounts the initial RAM disk (initrd) which is a temporary root filesystem until the real root filesystem is mounted. All kernels are located in the /boot directory together with the initial RAM disk image.

4.Starting Systemd

The kernel finally loads Systemd, which is the replacement of the old SysV init. Systemd is the mother of all Linux processes and manages among other things mounting of file systems, starting and stopping services to mention just a few.

Systemd uses the /etc/systemd/system/default.target file to determine the state or target that the Linux system should boot into.

• For a desktop workstation (with a GUI) the default target value is 5 which is the equivalent of run level 5 for the old SystemV init.
• For a server, the default target is multi-user.target which corresponds to run level 3 in SysV init.

Here’s a breakdown of the systemd targets:

• poweroff.target (runlevel 0): Poweroff or Shutdown the system.
• rescue.target (runlevel 1): launches a rescue shell session.
• multi-user.target (runlevel 2,3,4): Configures the system to a non-graphical (console) multi-user system.
• graphical.target (runlevel 5): Set the system to use a graphical multi-user interface with network services.
• reboot.target (runlevel 6): reboots the system.

To check the current target on your system, run the command:

Check Run Level

You can switch from one target to another by running the following command on the terminal:

For example, init 3 configures the system to a non-graphical state.

The init 6 command reboots your system and init 0 powers off the system. Be sure to invoke sudo command when you want to switch to these two targets.

The booting process ends once systemd loads all the daemons and sets the target or run level value. It’s at this point you are prompted for your username and password upon which you gain entry to your Linux system.

If You Appreciate What We Do Here On TecMint, You Should Consider:

TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.

If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.

We are thankful for your never ending support.

Источник

Linux Boot Process Explained in Simple Steps

This tutorial describes the Linux booting process in detail, such as the stages involved, which scripts are run, which configuration files are read and their order, since the time of turning on the system till getting the login prompt.

1) BIOS Initialization

BIOS or the Basic Input Output System is a firmware program that performs a very basic level of interaction with the hardware. This is the first program that takes control when the computer is switched on. The BIOS performs a test on all the hardware components and peripherals called POST or the “Power On Self Test”. It initializes the required hardware for booting.

After POST executes successfully, the BIOS looks for a boot device from a list of devices. Modern BIOS allow you to configure the order of these devices (sometimes called boot preference) that BIOS checks for booting. These boot devices can either be a floppy drive, CDROM, hard drive, a network interface or other removable media (such as USB flash drive).

The BIOS checks for the boot sector on the bootable device. Boot sector is the first physical sector on the storage device, and contains the code required for booting the machine.

2) The Master Boot Record

In case of hard disks and many other mass storage media, the boot sector is MBR. MBR consists of 512 bytes at the first sector of the hard disk. It is important to note that MBR is not located inside any partition. MBR precedes the first partition. The layout of MBR is as follows:

• First 446 bytes contain bootable code.
• Next 64 bytes contain partition information for 4 partitions (16×4). That is why the hard disks can have only 4 primary partitions as the MBR can store information for 4 partitions only. So if you need more than 4 partitions on the hard disk, one of the primary partition has to be extended, and out of these extended partitions, logical partitions are created.
• The last 2 bytes are for MBR signature, also called magic number. (Thus total of 446 + 64 + 2 = 512 bytes).

The first 446 bytes of MBR contains the code that locates the partition to boot from. The rest of the booting process take place from that partition. This partition contains a software program called the ‘bootloader’ for booting the system.

3) About GRUB

According to gnu.org, «a bootloader is the first software program that runs when a computer starts». GRUB or GRand Unified Bootloader is the bootloading program for Linux like operating systems. There are two main versions of Grub that are available (Grub version 1 and 2). Presently, most Linux distros have started using grub version 2. One main feature of grub is that it can be installed using Linux image and there is no need for running the operating system.

Grub is a multi-stage bootloader (Stage1, Stage 1.5 and Stage 2). The 3 stages for grub version 1 and version 2 are explained below.

Grub Version 1 stages

Stage 1 can load Stage 2 directly, but it is normally set up to load Stage 1.5. GRUB Stage 1.5 is located in the first 30 kilobytes of hard disk immediately following the MBR and before the first partition. If this space is not available (Unusual partition table, special disk drivers, GPT or LVM disk), the installation of Stage 1.5 will fail. The stage 1.5 image contains file system drivers. This enables stage 1.5 to directly load stage 2 from any known location in the filesystem, for example from /boot/grub. Stage 2 will then load the default configuration file and any other modules needed.

Grub Version 2 stages

Stage 1 -> boot.img is stored in the MBR (or optionally in any of the volume boot records) and addresses the next Stage by an LBA48 address (the 1024 cylinder boundary of GRUB legacy is omitted) , and at the time of installation, it is configured to load the first sector of core.img

Stage 1.5 -> core.img is by default written to the sectors between the MBR and the first partition, when these sectors are free and available. For legacy reasons, the first partition of a hard disc does not begin at sector 1 (counting begins with 0) but at sector 63 leaving a gap of 63 sectors of empty space, that is not a part of any partition of the file system and therefore, not prone to any problems related with it. Once executed, core.img will load its configuration file and any other modules needed, particularly file system drivers. At the time of installation, it is generated from diskboot.img and configured to load stage 2.

Refer to the bottom of this page for boot process using grub version 2

Stage 2 -> files belonging to stage 2 are held in the /boot/grub-directory, which is a sub-directory of /boot/ directory.

Grub Boot Stage Errors

Here is a sample of grub.conf:

GRUB allows you to choose from a list of available operating systems. The different OS’s have different title in grub.conf. Corresponding to this configuration file, the user at GRUB menu will be asked to choose from two options: Red Hat Enterprise Linux Server (2.6.18-238.el5), and Windows XP Pro. The commands following the title are the commands that run in the background when an entry is selected from the GRUB menu. For example, when the user selects the first option of Red Hat Enterprise Linux, following three commands execute:

Corresponding to this menu entry, the first command, i.e. «root (hd0,0)» specifies the partition on which a compressed kernel image and initrd file are located.

The second command i.e. «kernel /vmlinuz-2.6.18-238.el5 ro root=/dev/VolGroup00/LogVol00» tells which kernel image to use (in this case vmlinuz-2.6.18-238.el5). The arguments to this command are ‘ro’ and ‘root’. ‘root’ specifies the device on which root directory of the filesystem (i.e. / directory) is located; ‘ro’ means that this partition is to be mounted in read only mode (i.e. the kernel mounts the root partition in read only mode). Note that the partition for root filesystem and the partition on which this kernel image resides (i.e. boot partition) are different.

The third command is the location of initrd. Before going into the details of what initrd is, let’s look at a problem caused at the boot time.

The Chicken/Egg Module Problem and initrd

The kernel needs to mount the root filesystem (as specified in the second command above). This filesystem may be on some partition with one of the following capabilities:

The Linux kernel does not have these features compiled into it. But they are present as modules. So, the kernel needs to load these modules in order to mount the root filesystem. These modules are present under /lib/modules/ directory, which is present on the root filesystem itself. But this root filesystem is not mounted yet (that is what we have been trying to do so far). So, how can kernel access the modules for mounting a filesystem which are present on the filesystem itself (without mounting it)?

The kernel and GRUB provide a solution through initrd, the initial RAM disk. It contains the modules needed to mount the filesystem, and only modules needed for that filesystem are included.

GRUB also supports chainloading, the method used to pass control to other bootloader. Chainloading is used by GRUB to boot operating systems like windows. This can be checked in the above configuration file, under the title Windows XP Pro.

4) Kernel Initialization

After GRUB stage 2, the location of the kernel and necessary modules through initrd are known. Now the kernel is loaded into memory and initialized. The initrd image is compiled and mounted into the memory. It serves as a temporary root file system and helps kernel to boot properly without mounting any root file system. Now that all the drivers are loaded into memory, and kernel has booted, kernel mounts the root filesystem in read only mode, and starts the first process.

5) The init Process

The ‘init’ is the first process started by kernel (initialization process). It is the parent of all processes. The PID (Process ID) of init process is always 1. This process persists till the computer halts. It is responsible for the whole state of system. The settings for this process are stored in its configuration file, /etc/inittab (system initialization table). Before diving deeper into the details of this file and proceeding any further with the boot process, let’s discuss runlevels.

6) Runlevels

Runlevel is the state in which a system boots. It can boot in a single user mode, multi-user mode, with networking, and with graphics etc. The following are the default runlevels defined by Linux:

There are some additional runlevels, which are rarely used such as:

Summarizing runlevels: Runlevel 1 is used for maintenance purpose, because this is a very limited runlevel. Only the minimum scripts run in this runlevel. Only root user can log in. No other user can log into this runlevel. Runlevel 2 is more relaxed than runlevel 1. Here, all the users can login, but networking service is not running. Runlevel 3 provides a full working environment. All users can log in, networking is enabled. Runlevel 4 is for experiment purpose only. In runlevel 5, graphical console is available. Runlevel ‘0’ is the halt state of system, and switching to runlevel 6 will reboot the system.

Now that we are clear about runlevels, let’s continue our discussion about init process and its configuration file, ‘inittab’.

‘inittab’ file from RHEL is:

The general format of entries in this file is:

Now, let’s look at some entries in this file. The first uncommented line, i.e. «id:3:initdefault:» specifies the default runlevel in which the system will boot. According to this file, the system will boot into runlevel 3 by default. One more important line is system initialization line (the one with id: si)

This line tells init process to execute «/etc/rc.d/rc.sysinit» script. This is the first script executed by init during booting process.

7) Script rc.sysinit

When this script executes, it asks the user for interactive setup (Press ‘I’ to enter interactive startup). This script performs a lot of functions for the system that include:

• Setting hostname
• It checks and mounts filesystems (/proc, /sys, and others in /etc/fstab).
• Enables SWAP
• Sets SELinux
• Configures kernel parameters from sysctl.conf
• Sets system clock
• Loads required modules
• Setting a minimal path
• Initializes required serial and other ports
• Enables RAID and LVM
• And the root filesystem, which was mounted read-only earlier (as specified in GRUB configuration file), is checked and remounted read-write.

After this script has been executed, the runlevel specific files are run, according to «/etc/inittab». In our file, the default runlevel was 3. So the line corresponding to this runlevel is:

There are directories corresponding to each runlevel under «/etc/rc.d» directory. According to this line, the scripts in /etc/rc.d/rc3.d directory are run. Let’s list the files in this directory. (Other directories like rc1.d, rc2.d . have similar files in them).

Some files in this directory start with ‘S’ and others with ‘K’. The files starting with ‘S’ correspond to the scripts that have to be ‘started’ in that particular runlevel, and the ones with ‘K’ correspond to the ones that are to be ‘killed’. These files are just soft links to scripts under «/etc/rc.d/init/d» directory (One soft link points to «/etc/rc.local» which itself is a soft link to «/etc/rc.d/rc/local»). The scripts in «/etc/rc.d/init.d/» are daemons. Daemons are the processes that run in the background and provide some kind of service. For instance, http daemon (httpd) provides web service.

The «/etc/rc.local» script runs after all these scripts have been executed. If there is a command or script that you want to be executed at system startup, you can put it in this script.

Now that all these scripts have been executed successfully, login prompt appears.

Bootloader Grub Version 2 Break Down Linux Boot Process Steps

Conclusion

Thanks for reading and please provide your suggestions on the below comment section. You can also download linux boot process pdf version for future reference.

Источник