Linux Boot Process: What You Should Know

Linux Boot Process Featured Code

Ever been curious about the different stages of Linux, an open-source operating system? Knowing the entire boot process can help you troubleshoot issues – especially if you’re the administrator.

What happens behind the scenes when you power your device on? Read on to find out.


The Basic Input/Output System (BIOS) is a piece of low-level firmware stored on a small memory chip in your computer’s motherboard. This firmware aids the start-up process and manages data flow between your machine and other connected devices, such as a mouse, printer and video adapter.

Linux Boot Process Bios

The primary function of BIOS, shown above, is to run the Power-On Self Test (POST). This test verifies the operability of system hardware and finds the boot sector, which contains the software necessary for the rest of the process. If the POST is successful, the BIOS will load the next step, the Stage One Boot Loader, into the system’s RAM.

If the POST isn’t successful, the BIOS will return a code you can use for troubleshooting.

Stage One Boot Loader

The first stage of the boot loader — called the Master Boot Record (MBR) or Guided Partition Table (GPT) — is designed to get the program online.

The MBR is a simple piece of software with no built-in understanding of file systems. As a result, you will always need to store the stage two boot loader between the MBR and the first partition on the hard drive.

Once the MBR detects the stage two boot loader, it hands over control.

Stage Two Boot Loader

The job of the stage two boot loader is to find the kernel and load it into memory.

Most Linux divisions will use one of three different boot loaders — GRUB, GRUB2 or LIL. You’ll most likely see GRUB2, depicted below, as it’s the newest.

Linux Boot Process Grub2

Once the boot loader has found a kernel and loaded it into RAM, it passes over control. It also sends an image of your device’s file system the kernel can use to find modules.


Because all kernels exist in a compressed format to save hard drive space, the first thing it will do once given control is self extract. Then it will mount the image version of the file system it received from the boot loader.

The kernel will detect the system’s hardware and swap over the image to the root file on disk.

init (systemd)

Next, the kernel will start the initialization (init) system – the first process which spawns all processes necessary for the booting process. On most systems, this will be systemd.

Systemd’s primary function is to launch all of the daemons – background processes and services – needed to run the system. These services will continue to run after initialization and manage essential system processes like logging various system messages, keeping track of devices and ensuring that the file system is synchronized with system memory.

If you’re curious about which services systemd is running, running the systemctl command by itself will return a full list.

You can also use systemd to start other services on boot by using a combination of the systemctl command and the service you want to start. For example, if you want the system to check the status of the NFS, you can type systemctl status nfs-server.service. You can also start, stop, enable or disable a service with a combination of systemctl and one of those commands.


The run level is a state of INIT, and your system defines what services are running. The standard Linux kernel supports seven different runlevels:

  • 0: System halt, ready to be powered off
  • 1: Single user mode
  • 2: Multiple user mode, no network file system
  • 3: Multiple user mode using the command life interface instead of the graphical user one
  • 4: User-defined
  • 5: Multiple user mode, using the graphic user interface that most Linux systems will boot into by default
  • 6: Reboot

Linux Boot Process Init Runlevel

If you need to change the runlevel for any reason, INIT will be responsible for altering it using the telinit command, shown above.

Breaking Down the Boot Process

This breakdown is merely an overview of the Linux boot process and leaves out some of the finer details. However, it should give you the information you need to troubleshoot any problems you may face.


  1. Hi Jenna
    Now in some distros (MX, etc) systemd are not used – could you clarify pro and cons other inits?
    A lot concerns about safety as I read.

  2. What about computers that do no not use BIOS but use UEFI system instead. You did not mention UEFI at all. It is a solely different what of Linux booting.
    I would like to know how my laptop boots using UEFI. I know it boots very fast (23.372-seconds).

    Startup finished in 4.707s (firmware) + 68ms (loader) + 13.315s (kernel) + 5.282s (userspace) = 23.372s reached after 5.157s in userspace

  3. No mention of the all important initramfs “initrd” before the rest of the kernel can be loaded.

  4. “Linux Boot Process: What You Should Know”
    The most important thing to know is:
    If you over write it or otherwise corrupt it, your system will not boot.
    Many people learn that the hard way!

  5. This article presents some really tragically outdated information.

    BIOS hasn’t been a thing for like a decade, replaced by UEFI, and the way this boot process works is not how it really works anymore because MBR and BIOS aren’t used by default.

    If one is researching the Linux boot process I would recommend looking elsewhere. This ain’t how it works anymore and hasn’t been for yeeaaars.

    1. It is how it works for me and many others. When I needed a new laptop, I purchased a reconditioned laptop, with BIOS rather than UEFI. There are many others like myself that will either use older hardware because it still works with Linux, or avoid an outsider like MS controlling our boot process. I may have to go to it someday, but I will hold off as long as possible. My hope is Linux hardware will be more economical by that time. Consider, maybe the author has another article ready to go on UEFI? MTE needs to print new stuff to stay relevant. Thanks Jenna!

      1. Microsoft has no control over anyone’s UEFI boot process. None . That’s blatant FUD that came out because of people going Chicken Little over the Secure Boot feature without doing a lick of research.

        You’ve been forcing yourself to use an inferior and obsolete standard because you fell for anti-Microsoft fear mongering. I’d rather use what works best, not what’s broken and needs to be replaced.

        The problem with this article is it doesn’t explicitly just say “this is the old legacy setup” which would be accurate. It’s presenting this information as if it’s the standard and it hasn’t been for a long time. Bad article.

Comments are closed.