{"id":787,"date":"2009-04-29T14:14:32","date_gmt":"2009-04-29T18:14:32","guid":{"rendered":"http:\/\/www.databook.bz\/?page_id=787"},"modified":"2023-11-20T06:21:33","modified_gmt":"2023-11-20T11:21:33","slug":"the-linux-boot-process","status":"publish","type":"page","link":"http:\/\/www.linux-databook.info\/?page_id=787","title":{"rendered":"Bootup and Linux startup"},"content":{"rendered":"\n

Understanding the boot and Linux startup processes is important to being able to both configure Linux and to resolving startup issues. This article presents an overview of the bootup sequence using the GRUB2 bootloader<\/a> and the startup sequence as performed by the systemd initialization system<\/a>. <\/p>\n\n\n\n

Overview<\/h2>\n\n\n\n

In reality there are two sequences of events that are required to\nboot a Linux computer and make it usable: boot and startup. The Boot\nsequence starts when the computer is turned on, and is completed when\nthe kernel is initialized and systemd is launched. The Startup\nprocess then takes over and finishes the task of getting the Linux\ncomputer into an operational state. \n<\/p>\n\n\n\n

Overall the Linux boot and startup process is fairly simple to\nunderstand. It is comprised of the following steps which will be\ndescribed in more detail in the following sections.<\/p>\n\n\n\n

    \n
  1. BIOS POST<\/li>\n\n\n\n
  2. \n\tBoot loader \u2013 GRUB2<\/li>\n\n\n\n
  3. \n\tKernel initialization<\/li>\n\n\n\n
  4. \n\tStart systemd, the mother of all processes. \n\t<\/li>\n<\/ol>\n\n\n\n

    \n\n\t\n\tNote that this article covers GRUB2 and systemd because they are the\n\tcurrent boot loader and initialization software for many\n\tdistributions. \n\t\n<\/p>\n\n\n\n

    \nThe Boot process<\/h2>\n\n\n\n

    The boot process can be initiated in one of a couple ways. First,\nif power is turned off, turn on the power to begin the boot process.\nIf the computer is already running a local user, including root as\nwell as unprivileged users, can programmatically initiate the boot\nsequence by using the GUI or command line to initiate a reboot. A\nreboot will first do a shutdown and then restart the computer.<\/p>\n\n\n\n

    BIOS POST<\/h3>\n\n\n\n

    The first step of the Linux boot process really has nothing\nwhatever to do with Linux. This is the hardware portion of the boot\nprocess and is the same for any operating system. When power is first\napplied to the computer it runs the Power On Self Test (POST) which\nis part of BIOS. BIOS stands for Basic I\/O System and POST stands for\nPower On Self-Test.<\/p>\n\n\n\n

    When IBM designed the first PC back in 1981, BIOS was designed to\ninitialize the hardware components. POST is the part of BIOS whose\ntask is to ensure that the computer hardware functioned correctly. If\nPOST fails, the computer may not be usable and so the boot process\ndoes not continue.<\/p>\n\n\n\n

    BIOS POST checks basic operability of the hardware and then it\nissues a BIOS interrupt, INT 13H, which locates the boot sectors on\nany attached bootable devices. The first boot sector it finds that\ncontains a valid boot record is loaded into RAM and control is then\ntransferred to the code that was loaded from the boot sector.<\/p>\n\n\n\n

    The boot sector is really stage 1 of the boot loader. There are\nthree boot loaders used by most Linux distributions, GRUB, GRUB2 and\nLILO. GRUB2 is the newest and is used much more frequently these\ndays.<\/p>\n\n\n\n

    GRUB2<\/h3>\n\n\n\n

    GRUB2 stands for \u201cGRand Unified Bootloader \u2013 version 2\u201d and\nit is now the primary bootloader for most current Linux\ndistributions. GRUB2 is the program which makes the computer just\nsmart enough to find the operating system kernel and load it into\nmemory. Because it is easier to write and say GRUB than GRUB2, I may\nuse the term GRUB in this document but I will be referring to GRUB2\nunless specified otherwise.<\/p>\n\n\n\n

    GRUB has been designed to be compatible with the multiboot\nspecification<\/a> which allows GRUB to boot many versions of Linux\nand other free operating systems; it can also chain load the boot\nrecord of proprietary operating systems.<\/p>\n\n\n\n

    GRUB can also allow the user to choose to boot from among several\ndifferent kernels for any given Linux distribution. This affords the\nability to boot to a previous kernel version if an updated one fails\nsomehow or is incompatible with an important piece of software. GRUB\ncan be configured using the \/boot\/grub\/grub.conf file.<\/p>\n\n\n\n

    GRUB1 is now considered to be legacy and has been replaced in most\nmodern distributions with GRUB2, which is a rewrite of GRUB1. Red Hat\nbased distros upgraded to GRUB2 around Fedora 15 and CentOS\/RHEL 7.\nGRUB2 provides the same boot functionality as GRUB1 but GRUB2 is also\na mainframe-like command-based pre-OS environment and allows more\nflexibility during the pre-boot phase. GRUB2 is configured with\n\/boot\/grub2\/grub.cfg.<\/p>\n\n\n\n

    The primary function of either GRUB is to get the Linux kernel\nloaded into memory and running. Both versions of GRUB work\nessentially the same way and have the same three stages, but I will\nuse GRUB2 for this discussion of how GRUB does its job. The\nconfiguration of GRUB or GRUB2, and the use of GRUB2 commands is\noutside the scope of this article.<\/p>\n\n\n\n

    Although GRUB2 does not officially use the stage notation for the\nthree … well … stages of GRUB2, it is convenient to refer to them\nin that way. So I will.<\/p>\n\n\n\n

    Stage 1<\/h4>\n\n\n\n

    As mentioned in the BIOS POST section, at the end of POST, BIOS\nsearches the attached disks for a boot record, usually located in the\nMaster Boot Record (MBR), it loads the first one it finds into\nmemory, and then starts execution of the boot record. The bootstrap\ncode, i.e., GRUB2 stage 1, is very small because it must fit into the\nfirst 512 byte sector on the hard drive along with the partition\ntable. The total amount of space allocated for the actual bootstrap\ncode in a Classic\nGeneric MBR<\/a> is 446 bytes. The 446 Byte file for stage 1 is named\nboot.img and does not contain the partition table which is added to\nthe boot record separately. \n<\/p>\n\n\n\n

    Because the boot record must be so small, it is also not very\nsmart and does not understand filesystem structures. Therefore the\nsole purpose of stage 1 is to locate and load stage 1.5. In order to\naccomplish this, stage 1.5 of GRUB must be located in the space\nbetween the boot record itself and the first partition on the drive. \nAfter loading GRUB stage 1.5 into RAM, stage 1 turns control over to\nstage 1.5.<\/p>\n\n\n\n

    Stage 1.5<\/h4>\n\n\n\n

    As mentioned above, stage 1.5 of GRUB must be located in the space\nbetween the boot record itself and the first partition on the disk\ndrive. This space was left unused historically for technical reasons.\nThe first partition on the hard drive begins at sector 63 and with\nthe MBR in sector 0, that leaves 62 512-byte sectors \u2014\n31,744 bytes \u2014 in which\nto store the core.img file which is stage 1.5 of GRUB. The core.img\nfile is 25,389 Bytes so there is plenty of space available between\nthe MBR and the first disk partition in which to store it.<\/p>\n\n\n\n

    Because of the larger amount of code that can be accommodated for\nstage 1.5, it can have enough code to contain a few common filesystem\ndrivers, such as the standard EXT and other Linux filesystems, FAT,\nand NTFS. The GRUB2 core.img is much more complex and capable than\nthe older GRUB1 stage 1.5. This means that stage 2 of GRUB2 can be\nlocated on a standard EXT filesystem but\nit cannot be located on a logical volume. So\nthe standard location for the stage 2 files is in the \/boot\nfilesystem, specifically \/boot\/grub2. \n<\/p>\n\n\n\n

    Note that the \/boot directory\nmust be located on a filesystem that is supported by GRUB. Not all\nfilesystems are. The\nfunction of stage 1.5 is to begin execution with\nthe filesystem drivers\nnecessary to locate the\nstage 2 files in the \/boot filesystem and\nload the needed drivers. \n<\/p>\n\n\n\n

    Stage 2<\/h4>\n\n\n\n

    All of the files for GRUB stage 2 are located in the \/boot\/grub2\ndirectory and several subdirectories. GRUB2 does not have an image\nfile like stages 1 and 2. Instead it consists mostly of runtime\nkernel modules that are loaded as needed from the \/boot\/grub2\/i386-pc\ndirectory.<\/p>\n\n\n\n

    The function of GRUB2 stage 2 is to locate and load a Linux kernel\ninto RAM and turn control of the computer over to the kernel. The\nkernel and its associated files are located in the \/boot directory.\nThe kernel files are identifiable as they are all named starting with\nvmlinuz. You can list the contents of the \/boot directory to see the\ncurrently installed kernels on your system.<\/p>\n\n\n\n

    GRUB2, like GRUB1, supports booting from one of a selection of\nLinux kernels. The Red Hat package manager, DNF, supports keeping\nmultiple versions of the kernel so that if a problem occurs with the\nnewest one, an older version of the kernel can be booted. By default,\nGRUB provides a pre-boot menu of the installed kernels, including a\nrescue option and, if configured, a recovery option. \n<\/p>\n\n\n\n

    Stage 2 of GRUB2 loads the selected kernel into memory and turns\ncontrol of the computer over to the kernel.<\/p>\n\n\n\n

    Kernel<\/h3>\n\n\n\n

    All of the kernels are in a self-extracting, compressed format to\nsave space. The kernels are located in the \/boot directory, along\nwith an initial RAM disk image, and device maps of the hard drives. \n<\/p>\n\n\n\n

    After the selected kernel is loaded into memory and begins\nexecuting, it must first extract itself from the compressed version\nof the file before it can perform any useful work. Once the kernel\nhas extracted itself, it loads systemd, which is the replacement for\nthe old SysV init program, and turns control over to it. \n<\/p>\n\n\n\n

    This is the end of the boot process. At this point the Linux\nkernel and systemd are running but unable to perform any productive\ntasks for the end user because nothing else is running.<\/p>\n\n\n\n

    The Startup Process<\/h2>\n\n\n\n

    The Startup process follows the boot process and brings the Linux\ncomputer up to an operational state in which it is usable for\nproductive work.<\/p>\n\n\n\n

    systemd<\/h3>\n\n\n\n

    systemd<\/a>\nis the mother of all processes and it is responsible for bringing the\nLinux host up to a state in which productive work can be done. Some\nof it’s functions, which is far more extensive than the old init\nprogram, are to manage many aspects of a running Linux host,\nincluding mounting filesystems, and starting and managing system\nservices required to have a productive Linux host. Any of systemd’s\ntasks that are not related to the startup sequence are outside the\nscope of this article.<\/p>\n\n\n\n

    First systemd mounts the filesystems as defined by \/etc\/fstab,\nincluding any swap files or partitions. At this point it can access\nthe configuration files located in \/etc, including its own. It uses\nits configuration file, \/etc\/systemd\/system\/default.target, to\ndetermine which state or target, into which it should boot the host.\nThe default.target file is only a symbolic link to the true target\nfile. For a desktop workstation, this is typically going to be the\ngraphical.target, which is equivalent to runlevel 5 in SystemV. For a\nserver, the default is more likely to be the multi-user.target which\nis like runlevel 3 in SystemV. The emergency.target is similar to\nsingle user mode. \n<\/p>\n\n\n\n

    Note that targets and services are systemd units. \n<\/p>\n\n\n\n

    Table 1, below, is a comparison of the systemd targets with the\nold SystemV startup runlevels. The systemd target aliases<\/strong>\nare provided by systemd for backward compatibility. The\ntarget aliases allow scripts \u2014\nand many sysadmins like myself \u2014\nto use SystemV\ncommands like init\n3<\/strong>\nto change runlevels. Of\ncourse the SystemV commands are forwarded to systemd for\ninterpretation and execution.<\/p>\n\n\n\n

    \n\t\t\tSystemV Runlevel<\/strong>\n\t\t<\/td>\n\t\t\tsystemd target<\/strong>\n\t\t<\/td>\n\t\t\tsystemd target aliases<\/strong>\n\t\t<\/td>\n\t\t\tDescription<\/strong>\n\t\t<\/td><\/tr>
    \n\t\t\t
    \n\n\t\t\t\n\t\t<\/td>    		\n\t\t\thalt.target\n\t\t<\/td>\n\t\t\t
    \n\n\t\t\t\n\t\t<\/td>    		\n\t\t\tHalts the system without powering it down.\n\t\t<\/td><\/tr>
    \n\t\t\t0\n\t\t<\/td>\n\t\t\tpoweroff.target\n\t\t<\/td>\n\t\t\trunlevel0.target\n\t\t<\/td>\n\t\t\tHalts the system and turns the power off.\n\t\t<\/td><\/tr>
    \n\t\t\tS\n\t\t<\/td>\n\t\t\temergency.target\n\t\t<\/td>\n\t\t\t
    \n\n\t\t\t\n\t\t<\/td>    		\n\t\t\tSingle user mode. No services are running; filesystems are not\n\t\t\tmounted. This is the most basic level of operation with only an\n\t\t\temergency shell running on the main console for the user to\n\t\t\tinteract with the system.\n\t\t<\/td><\/tr>
    \n\t\t\t1\n\t\t<\/td>\n\t\t\trescue.target\n\t\t<\/td>\n\t\t\trunlevel1.target\n\t\t<\/td>\n\t\t\tA base system including mounting the filesystems with only the\n\t\t\tmost basic services running and a rescue shell on the main\n\t\t\tconsole.\n\t\t<\/td><\/tr>
    \n\t\t\t2\n\t\t<\/td>\n\t\t\t
    \n\n\t\t\t\n\t\t<\/td>    		\n\t\t\trunlevel2.target\n\t\t<\/td>\n\t\t\tMultiuser, without NFS but all other non-GUI services running.\n\t\t<\/td><\/tr>
    \n\t\t\t3\n\t\t<\/td>\n\t\t\tmulti-user.target\n\t\t<\/td>\n\t\t\trunlevel3.target\n\t\t<\/td>\n\t\t\tAll services running but command line interface (CLI) only.\n\t\t<\/td><\/tr>
    \n\t\t\t4\n\t\t<\/td>\n\t\t\t
    \n\n\t\t\t\n\t\t<\/td>    		\n\t\t\trunlevel4.target\n\t\t<\/td>\n\t\t\tUnused.\n\t\t<\/td><\/tr>
    \n\t\t\t5\n\t\t<\/td>\n\t\t\tgraphical.target\n\t\t<\/td>\n\t\t\trunlevel5.target\n\t\t<\/td>\n\t\t\tmulti-user with a GUI.\n\t\t<\/td><\/tr>
    \n\t\t\t6\n\t\t<\/td>\n\t\t\treboot.target\n\t\t<\/td>\n\t\t\trunlevel6.target\n\t\t<\/td>\n\t\t\tReboot\n\t\t<\/td><\/tr>
    \n\t\t\t
    \n\n\t\t\t\n\t\t<\/td>    		\n\t\t\tdefault.target\n\t\t<\/td>\n\t\t\t
    \n\n\t\t\t\n\t\t<\/td>    		\n\t\t\tThis target is always aliased with a symbolic link to either\n\t\t\tmulti-user.target or graphical.target. systemd always uses the\n\t\t\tdefault.target to start the system. The default.target should\n\t\t\tnever be aliased to halt.target, poweroff.target, or\n\t\t\treboot.target.\n\t\t<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

    \nTable\n1: Comparison of SystemV runlevels with systemd targets and some\ntarget aliases.<\/em><\/p>\n\n\n\n

    Each target has a set of dependencies described in its\nconfiguration file. systemd starts the required dependencies. These\ndependencies are the services required to run the Linux host at a\nspecific level of functionality. When all of the dependencies listed\nin the target configuration files are loaded and running, the system\nis running at that target level. \n<\/p>\n\n\n\n

    systemd also looks at the legacy SystemV init directories to see\nif any startup files exist there. If so, systemd used those as\nconfiguration files to start the services described by the files. The\ndeprecated network service is a good example of one of those that\nstill use SystemV startup files in Fedora.<\/p>\n\n\n\n

    Figure 1, below, is copied directly from the bootup<\/strong> man\npage. It shows the general sequence of events during systemd startup\nand the basic ordering requirements to ensure a successful startup. \n<\/p>\n\n\n\n

    The sysinit.target and basic.target targets can be considered as\ncheckpoints in the startup process. Although systemd has as one of\nits design goals to start system services in parallel, there are\nstill certain services and functional targets that must be started\nbefore other services and targets can be started. These checkpoints\ncannot be passed until all of the services and targets required by\nthat checkpoint are fulfilled. \n<\/p>\n\n\n\n

    So the sysinit.target is reached when all of the units on which it\ndepends are completed. All of those units, mounting filesystems,\nsetting up swap files, starting udev, setting the random generator\nseed, initiating low-level services, and setting up cryptographic\nservices if one or more filesystems are encrypted, must be completed,\nbut within the sysinit.target those tasks can be performed in\nparallel. \n<\/p>\n\n\n\n

    The sysinit.target starts up all of the low level services and\nunits required for the system to be marginally functional and that\nare required to enable moving on to the basic.target.<\/p>\n\n\n\n

      \n\n                              cryptsetup-pre.target veritysetup-pre.target\n                                                   |\n (various low-level                                v\n API VFS mounts:             (various cryptsetup\/veritysetup devices...)\n  mqueue, configfs,                                |    |\n  debugfs, ...)                                    v    |\n  |                                  cryptsetup.target  |\n  |  (various swap                                 |    |    remote-fs-pre.target\n  |   devices...)                                  |    |     |        |\n  |    |                                           |    |     |        v\n  |    v                       local-fs-pre.target |    |     |  (network file systems)\n  |  swap.target                       |           |    v     v                 |\n  |    |                               v           |  remote-cryptsetup.target  |\n  |    |  (various low-level  (various mounts and  |  remote-veritysetup.target |\n  |    |   services: udevd,    fsck services...)   |             |              |\n  |    |   tmpfiles, random            |           |             |    remote-fs.target\n  |    |   seed, sysctl, ...)          v           |             |              |\n  |    |      |                 local-fs.target    |             | _____________\/\n  |    |      |                        |           |             |\/\n  \\____|______|_______________   ______|___________\/             |\n                              \\ \/                                |\n                               v                                 |\n                        sysinit.target                           |\n                               |                                 |\n        ______________________\/|\\_____________________           |\n       \/              |        |      |               \\          |\n       |              |        |      |               |          |\n       v              v        |      v               |          |\n  (various       (various      |  (various            |          |\n   timers...)      paths...)   |   sockets...)        |          |\n       |              |        |      |               |          |\n       v              v        |      v               |          |\n timers.target  paths.target   |  sockets.target      |          |\n       |              |        |      |               v          |\n       v              \\_______ | _____\/         rescue.service   |\n                              \\|\/                     |          |\n                               v                      v          |\n                           basic.target         rescue.target    |\n                               |                                 |\n                       ________v____________________             |\n                      \/              |              \\            |\n                      |              |              |            |\n                      v              v              v            |\n                  display-    (various system   (various system  |\n              manager.service     services        services)      |\n                      |         required for        |            |\n                      |        graphical UIs)       v            v\n                      |              |            multi-user.target<\/span>\n emergency.service    |              |              |\n         |            \\_____________ | _____________\/\n         v                          \\|\/\n emergency.target                    v\n                              graphical.target<\/span><\/pre>\n\n\n\n
    \n\tFigure\n\t1: The systemd startup map.<\/em>
    After the sysinit.target is fulfilled,\nsystemd next starts the basic.target, starting all of the units\nrequired to fulfill it. The basic target provides some additional\nfunctionality by starting units that re required for the next target.\nThese include setting up things like paths to various executable\ndirectories, communication sockets and timers. \n\n<\/p>\n\n\n\n
    Finally, the user-level targets, multi-user.target or\ngraphical.target can be initialized. Notice that the\nmulti-user.target must be reached before the graphical target\ndependencies can be met. \n<\/p>\n\n\n\n
    The underlined targets in Figure 1, are the usual startup targets.\nWhen one of these targets is reached, then startup has completed. If\nthe multi-user.target is the default, then you should see a text mode\nlogin on the console. If graphical.target is the default, then you\nshould see a graphical login; the specific GUI login screen you see\nwill depend upon the default display\nmanager<\/a>.<\/p>\n\n\n\n
    Conclusions<\/h1>\n\n\n\n
    GRUB2 and the systemd init system are the key components in the\nboot and startup phases of most modern Linux distributions. Despite\nthe fact that there has been controversy surrounding systemd\nespecially, these two components work together smoothly to first load\nthe kernel and then to start up all of the system services required\nto produce a functional GNU\/Linux system. \n<\/p>\n\n\n\n
    Although I do find both GRUB2 and systemd more complex than their\npredecessors, they are also just as easy to learn and manage. The man\npages have a great deal of information about systemd, and\nfreedesktop.org has the complete set of systemd\nman pages<\/a> on line. Refer to the Resources section, below, for\nmore links. \n<\/p>\n\n\n\n
    Resources<\/h1>\n\n\n\n