Linux OS bootup sequence diagram

It would be really great if someone can confirm that the below steps are correct. I would like to know the exact correct steps.

  1. Power ON the computer.

  2. Basic I/O system (BIOS/UEFI). The first program that is executed which stored in ROM on the motherboard of the PC.

    • Firmware (BIOS/UEFI): A program that informs a device’s processor how to begin the startup process is considered firmware.
    • Firmware is installed directly onto a piece of hardware during manufacturing.
    • Computers, mobile phones, and tablets rely on firmware like BIOS and EFI to load their operating systems.
  3. perform POST (power-on self-test) to verify the H/W components are in working condition.

  4. Look for a bootable device. If found then handover CONTROL to the first sector of the device i.e. MBR

  5. Master Boot Record (MBR). 512 bytes, the first sector of any bootable device contains machine code instructions to boot a machine. it has the following info:

    • Boot loader info (446 bytes) — a small low-level code that points to a boot loader [where is the boot loader located?] /boot/grub2/grub.cfg
    • Partition table info (64 bytes) [where is the OS located in the filesystem?]
    • Error checking (2 bytes)
    • it will load the boot loader (GRUB2) into memory and handover CONTROL to it.
  6. GRand Unified Bootloader (GRUB2)

    • It's a program that loads the OS. It used to fit in MBR (446 bytes) but since the size is increasing the complexity of OS is increasing. It's not a single program, it allows the filesystem to be interpreted properly.
    • Loaded from /boot/grub2/grub.cfg into memory by MBR at boot time
    • user can see GUI asking to select different OS or kernels to boot from.
    • once selected the kernel, it locates the corresponding kernel executable.
      • /boot/vmlinuz-4.18.0-408.el8.x86_64
    • main job is to load kernel and initramfs [initramfs-4.18.0–408.el8.x86_64.img] into memory.
    • once the kernel is loaded into RAM, it passes CONTROL to it.
  7. Kernel:

    • Once the Linux kernel has control over the system (which it gets after being loaded by the boot loader), it prepares its memory structures and drivers (initializes hardware). The kernel is booting.
    • we can see a lot of messages, that can be suppressed through RHGB & quiet. [To enable messaging modify the parameter GRUB_CMDLINE_LINUX in /etc/default/grub; then run #grub2-mkconfig > /boot/grub2/grub.cfg and reboot]
    • Some Linux-based computer systems require an initramfs to boot properly. If present, then the kernel will execute /init script from the initramfs.
    • Systems with exotic drivers or setups, or encrypted file systems need initramfs so the Linux kernel is capable of handing over control to the init binary on their system.
  8. initramfs: ref-10

    • An initramfs is an initial ram file system based on tmpfs. It provides early userspace which can do things that kernel can’t do during boot time.
    • It contains the tools and scripts needed to mount the file systems before the init binary on the real root file system is called.
    • These tools can be decryption abstraction layers (for encrypted file systems), logical volume managers, software raid, bluetooth driver based file system loaders, etc.
    • At boot time, the kernel checks for the presence of the initramfs or the boot loader informs the Linux kernel that an initramfs is loaded.
    • If found, the Linux kernel will create a tmpfs file system, extract the contents of the archive on it, and then launch the /init script located in the root of the tmpfs file system.
      • [An initramfs contains at least one file called /init. This file is executed by the kernel as the main init process (PID 1). It has to do all the work.] ref-7
    • This script then mounts the real root file system under /sysroot (after making sure it can mount it, for instance by loading additional modules, preparing an encryption abstraction layer, etc.) as well as vital other file systems (such as /usr and /var ).
    • Once the root file system and the other vital file systems are mounted, the init script from the initramfs will switch the root towards the real root file system (remember it is switch_root operation NOT pivot_root).
      • [switch_root operation is to switch /sysroot into a real root filesystem, start executing stuff from there and then remove the initramfs from memory.]
    • finally call the /sbin/init (init -> /usr/lib/systemd/systemd) binary on that system’s real root filesystem as the main init process (PID 1 — inherited from initramfs /init, see exec details) to continue the boot process.
  9. systemd:

    • First service loaded with PID 1
    • mounting the filesystem from /etc/fstab.
    • start all required services and processes in parallel.
      • [/etc/systemd/system/default.target]
    • it starts looking for the file for the required dependencies to boot into the default target.
    • once the default target is up and the user can see the login prompt then we can say the system boot-up is successful.


1. https://opensource.com/article/20/5/systemd-startup
2. https://opensource.com/article/20/5/systemd-units
3. https://opensource.com/article/20/4/systemd
4. https://www.quora.com/What-is-chroot-Sysroot
5. https://blog.csdn.net/flynetcn/article/details/131828832
6. https://www.linfo.org/vmlinuz.html
7. https://wiki.gentoo.org/wiki/Custom_Initramfs
8. https://www.linuxfromscratch.org/blfs/view/svn/postlfs/initramfs.html
9. https://www.quora.com/What-exactly-is-the-initramfs-program-in-Linux-Is-it-a-script-binary-or-what
10. https://wiki.gentoo.org/wiki/Initramfs/Guide
11. https://wiki.ubuntu.com/Initramfs
12. https://www.youtube.com/watch?v=saovaEhA85g
13. https://www.youtube.com/watch?v=sOIOY6Ks0xA&t=423s
14. https://sourcemage.org/HowTo/initramfs
15. https://web.archive.org/web/20160730094856/http://wiki.sourcemage.org/HowTo(2f)Initramfs.html
16. https://tiebing.blogspot.com/2014/02/linux-switchroot-vs-pivotroot-vs-chroot.html
17. https://unix.stackexchange.com/questions/126217/when-would-you-use-pivot-root-over-switch-root
18. https://linux.die.net/man/8/pivot_root
19. https://linux.die.net/man/8/switch_root
20. https://en.wikipedia.org/wiki/Exec_(system_call)
21. https://www.baeldung.com/linux/exec-command-in-shell-script
22. https://eng.libretexts.org/Bookshelves/Computer_Science/Operating_Systems/Linux_-_The_Penguin_Marches_On_(McClanahan)/13%3A_Working_with_Bash_Scripts/3.09%3A_Positional_Parameters_exec_Command_source_Command#:~:text=The%20exec%20command%20in%20Linux,return%20to%20the%20calling%20process.
23. https://en.wikipedia.org/wiki/Overlay_(programming)
24. https://superuser.com/questions/782008/linux-boot-time-scrolling-messages
25. https://itnixpro.com/how-to-view-linux-boot-messages-using-dmesg-command/?utm_content=cmp-true
26. https://linux-audit.com/finding-boot-logs-in-systemd-journals/
27. https://www.loggly.com/ultimate-guide/using-journalctl/
  • 2
    Note that grub is not loaded from /boot/grub2/grub.cfg: grub is a program by itself that loads and reads this configuration file. Respectively, the Boot loader info (446 bytes) doesn't point to /boot/grub2/grub.cfg, it points to the location of the grub (executable, binary) program. Also notice that grub is the most popular boot loader, but there are others as well. I'm saying that to explain why the system by itself cannot use a plain text configuration file like grub.cfg as a boot loader - the system needs some real binary bootloader installed.
    – aviro
    Aug 18 at 9:45
  • @aviro thanks for the nice explanation. I will update the relevant step accordingly. Aug 18 at 10:00
  • Vendors still call UEFI as BIOS. My newer Dell is UEFI only (no CSM/BIOS/Legacy) but still uses BIOS in descriptions. Microsoft has required UEFI with gpt partitioning since 2012 and release of Windows 8. Many vendors starting in 2020 are now making UEFI only systems. Apple converted to UEFI when it changed to Intel chips before Microsoft converted. Arch often has good info: wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface
    – oldfred
    Aug 18 at 14:53

1 Answer 1


Well, you have the initramfs & systemd parts right, but the rest – not necessarily.

what are the exact correct steps?

The problem with such a question is that there is no single "exact correct steps" answer – there is a huge variety in each of those steps, depending on the hardware platform, on Linux distribution, and so forth.

Your description was correct at some point in time, for some specific Linux distribution on a specific PC platform (new-ish RHEL/Fedora on a 2010s PC?), but at the same time another PC might have used a different bootloader instead of GRUB, or might have used an entirely different bootstrap instead of a MBR sector – and yet both would be "correct".

  1. (Well, in between "Power on" and "BIOS", you could include the hidden processes that actually initialize the CPU when it's powered on – such as Intel's ME or AMD's PSP – which are literally a separate CPU that is the first to run, preparing the main CPU before executing the "BIOS". Although, since this is entirely invisible to user, it's fine to omit it and pretend that the BIOS is first.)

  2. Although "BIOS" could be a generic term, in practice it refers specifically to the IBM PC style of firmware, which most x86 PCs these days no longer use – nearly all of them use "UEFI" type firmware; UEFI would commonly include a compatibility module for BIOS interfaces but increasingly often no longer does.

    For other kinds of computers, it is even less accurate. Intel Macs always had EFI, as far as I know (no "BIOS"); Apple Silicon Macs have entirely custom system firmware; Chromebooks use Coreboot; various ARM64 computers might have UEFI – or might use something else.

    Generically, best to call it "system firmware".

  3. As far as PCs go (ignoring embedded devices for now), this was only accurate for the IBM PC BIOS boot process. Systems with UEFI, for example, do not use the boot code from the first sector at all; instead the firmware understands filesystems and stores the boot code as a regular file in a special partition.

  4. Again, accurate for IBM PC BIOS but not for UEFI.

    While the sector may still contain a partition table (though more commonly a GPT partition table from sectors 2+ is used), UEFI does not use the boot code from here but directly launches GRUB2 from a filesystem.

    (The ID of the "EFI System Partition" and path of the file are usually stored by the firmware itself in NVRAM, and there can be multiple of them – the firmware has its own boot menu.)

    For BIOS, though, there are broadly two kinds of bootsectors: a) ones which jump to the first sector of an "active" partition (aka the VBR), which is what happens with Syslinux and Windows among others; b) ones which jump to a fixed sector location defined at install time, which is what GRUB's MBR does.

    In either case, the boot code found in BIOS MBR is too small to understand grub.cfg. That's only used by the next stage that the MBR will launch.

  5. While GRUB2 is common, it is by no means universal. (Syslinux, for example, is fairly common, as is rEFInd and systemd-boot. These days – on UEFI systems specifically – the kernel image (vmlinuz) itself has a stub loader embedded, allowing the firmware to execute it directly.)

    Also, it never did fit in the MBR – neither GRUB2 nor GRUB0.x did. Even in MS-DOS, the MBR did little more but find the 'active' partition and jump to its VBR (which then loaded IO.SYS, and only that would finally load the DOS kernel). So although GRUB2 is indeed huge compared to other bootloaders, it's not anything new at all.

    (Finally, there are two grub.cfg's involved – a tiny "bootstrap" grub.cfg that is directly embedded into GRUB kernel image generated during grub-install, which points to the location of the "real" grub.cfg that you find in /boot/grub. So it wouldn't be accurate to say that GRUB is loaded "from" /boot/grub2/grub.cfg.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .