I am interested to learn about how Linux deals with a separate boot partitions. I am not interested in actually doing this, but I would like to know how this works under-the-hood.

Consider a hard drive sda, which has two partitions sda1 and sda2. Let's say that sda2 is the root partition / which contains the Linux OS.

My understanding is that the bootloader GRUB2, is mounted to /boot. When the directory /boot is on a separate partition sda2, however, how is it that this can happen before / is actually mounted?

How does the interaction between the BIOS, the Master boot record and GRUB (or the files /boot) successfully happen in this case? Is it that the data in /boot is not actually mounted to the / filesystem at this early stage?

Note: this question deals with mounting the root partition, but does not discuss a separate boot partition.


3 Answers 3


Here is the problem in your understanding:

My understanding is that the bootloader GRUB2, is mounted to /boot.

GRUB is not "mounted" on boot. GRUB is installed to /boot, and is loaded from code in the Master Boot Record. Here is a simplified overview of the modern boot process, assuming a GNU/Linux distribution with an MBR/BIOS (not GPT/UEFI):

  1. The BIOS loads.
  2. The BIOS loads the small piece of code that is in the Master Boot Record.
  3. GRUB does not fit in 440 bytes, the size of the Master Boot Record. Therefore, the code that is loaded actually just parses the partition table, finds the /boot partition (which I believe is determined when you install GRUB to the Master Boot Record), and parses the filesystem information. It then loads Stage 2 GRUB. (This is where the simplification comes in.)
  4. Stage 2 GRUB loads everything it needs, including the GRUB configuration, then presents a menu (or not, depending on user configuration).
  5. A boot sequence is chosen. This could be by a timeout, by the user selecting a menu entry, or by booting a command list.
  6. The boot sequence starts executing. This can do a number of things - for example, loading a kernel, chainloading to another bootloader - but let's assume that the boot sequence is standard GNU/Linux.
  7. GRUB loads the Linux kernel.
  8. GRUB loads the initial ramdisk.
  9. The initial ramdisk mounts / under /new_root (possibly cryptographically unlocking it), starts udev, starts resume-from-swap, etc.
  10. The initial ramdisk uses the pivot_root utility to set /new_root as the real /.
  11. init starts. Partitions get mounted, daemons get started, and the system boots.

Notice how the kernel is only loaded at step 7. Because of this, there is no concept of mounting until step 7. This is why /boot has to be mounted again in step 9, even though GRUB has already used it.

It may also be of use to look at the GRUB 2 section of the Wikipedia page on GRUB.

  • You pinned down my confusion exactly. This is just what I was looking for. So initially /boot is not referring to a directory mounted on the root partition?
    – jII
    Jan 28, 2014 at 2:38
  • @jesterII awesome! in that case, would you mind accepting this answer by clicking the checkmark right below the vote arrows?
    – strugee
    Jan 28, 2014 at 2:40
  • 7
    The MBR code can't parse a filesystem. It loads the grub core image from the unused sectors following the MBR before the first partition, and that code understands how to find and mount the /boot partition to find the grub config files, additional modules, and your kernels. Also pivot_root was considered a dirty hack and has been replaced with run-init which deletes all of the files in the initramfs, and then chroots into the root file system.
    – psusi
    Jan 28, 2014 at 3:33
  • Modern boot process should now be Legacy boot process as UEFI getting more more and more popurlar ;-) @strugee
    – Kiwy
    Jan 28, 2014 at 9:10
  • 1
    @strugee, after discussion on the util-linux mailing list it seems that my recollection was slightly off: they stopped allowing pivot_root on the real rootfs, so that is why nobody uses it during boot any more. Systemd uses it on shutdown though, not to return to the original initrd ( which removes itself when switching to the real root ), but to switch to a freshly loaded one. See marc.info/?l=util-linux-ng&m=139100788306216&w=2
    – psusi
    Jan 30, 2014 at 15:46

Question #1

My understanding is that the bootloader GRUB2, is mounted to /boot. When the directory /boot is on separate partition sda2, however, how is it that this can happen before / is actually mounted?

I don't think you're understanding is quite right here. From the GNU GRUB Wikipedia page:


When a computer is turned on, the computer's BIOS finds the configured primary bootable device (usually the computer's hard disk) and loads and executes the initial bootstrap program from the master boot record (MBR). The MBR is the first sector of the hard disk, and has the number 0 (sectors counting starts at 0). For a long time, the size of a sector has been 512 bytes, but since 2009 there are hard disks available with a sector size of 4096 bytes, called Advanced Format disks. As of October 2013, such hard disks are still accessed in 512-byte sectors, by utilizing the 512e emulation.

In GRUB version 2 the following takes place:


Booting the Computer

When power is turned on, the following happens:

  • The hardware initializes, sets the CPU to real mode (no virtual memory) and jumps to fixed location 0xFFFF0 (hardwired in the CPU circuits)
  • BIOS code stored in a ROM or flash-memory mapped to that location is therefore executed.
  • The BIOS code looks at the BIOS config data to see which is the boot device. This BIOS config data can usually be edited by pressing some special key-sequence just after turning the power on, causing the BIOS configuration program to run. Among other things, the boot device can usually be selected here.
  • The BIOS code loads the MBR of the boot device into RAM. Remember that an MBR is just 512 bytes! The loaded data is of course the program & data that grub-install dynamically created and wrote there when the grub-install program was executed.
  • The BIOS code jumps to the start address of the loaded MBR (ie Grub code executes for the first time since power-on).
  • Grub’s MBR code loads a single sector whose address is hard-wired into the MBR block. It then loops over the (address,len) pairs in that sector loading all that data from the disk into memory (ie loads the contents of file /boot/grub/core.img, or its “embedded” copy). The MBR code then jumps to the loaded code, ie “executes” the program in core.img.
  • As described in the “Installing Grub” section, this trick of embedding the raw disk block addresses makes it possible to store core.img in space that is not in a partition, and that has never been formatted as a filesystem at all (“embedding”). And in this case, if core.img is modified, as long as the new version is “embedded” at the same location, the MBR code does not need to be updated.
  • Alternatively, it is possible for the core.img to be inside a real filesystem, and for Grub to read the core.img file contents without having a driver for that filesystem. However in this case, if core.img is modified then the first block of the file may well be given a new address on disk; if this happens then the MBR must be updated to point to this new location. Nevertheless, as core.img is usually updated by running grub-install, this is not usually a problem.
  • Note that theoretically, if core.img is on a different device than the MBR, and new hardware is added then the Grub-generated MBR record might not be able to correctly load the core.img file; the device-id on which the first sector of core.img is to be found is hard-wired into the MBR, not searched for. However there is no solution for this; there is no way to embed the equivalent of the Grub “search” command into the 512-byte MBR. This problem is not likely though; normally the core.img is embedded on the same device as the MBR. And once core.img has been loaded it can use search.mod to find all further /boot/grub files, and is therefore immune to hardware rearrangements.
  • The executed core.img code now initializes all the modules that are built into it (linked into core.img); one of these modules will be a filesystem driver capable of reading the filesystem on which directory /boot/grub lives.
  • It also registers a set of built-in commands: set, unset, ls, insmod.
  • If a “config file” has been linked into core.img, this is then passed to a very simple build-in script parser for processing. Scripting commands in the config file can only invoke built-in or linked-in commands. Simple scenarios (eg booting a typical desktop computer from a local drive) need no config file; this facility is used for things like booting via pxe, remote nfs or when /boot/grub is on an LVM device.
  • Core.img now loads file “/boot/grub/normal.mod” dynamically from disk, and jumps to its entry function. Note that this step requires the appropriate filesystem driver to be set up (ie built-in).

     ss of boot process

NOTE: When you see the typical GRUB2 menu where you select which OS/Kernel to boot, you're referencing the system's /boot/grub directory at this point.

                                         ss of grub tui


  • Someone should correct that wikipedia entry because it is wrong. Stage 1/1.5/2 are only applicable to legacy grub. They were completely done away with in the grub2 rewrite and you will not find any reference to those terms in the official grub 2 documentation.
    – psusi
    Jan 28, 2014 at 3:39
  • @psusi - thanks for clarifying. I was a bit confused when I saw them mentioned there too, since I'd heard the same, that 1/1.5/2 were gone. I wouldn't know who to ask to edit Wikipedia articles, I wouldn't feel qualified to edit such a post. Perhaps alerting the GRUB2 team would be the next best thing?
    – slm
    Jan 28, 2014 at 3:45
  • @psusi - here's the ref. to stages being eliminated in off. docs for GRUB2: gnu.org/software/grub/manual/grub.html... "The image files (see Images) that make up GRUB have been reorganised; Stage 1, Stage 1.5, and Stage 2 are no more."
    – slm
    Jan 28, 2014 at 3:47

Linux (the kernel) does not care how many boot partitions you have. Loading the kernel from disk is the job of the bootloader (e.g. grub, grub2, lilo) and these tools also do not care about the number of locations a kernel might be located. They only care about the specific location.

As an example, my boot partition is /dev/md1, which is a mdadm RAID mirror backed by the physical partitions /dev/sde1 and /dev/sdf1. I can mount these individually if I wanted and as such this technically counts as having two boot partitions, though they should contain the same data.

Having two partitions for /boot for me is an availability issue, but they could equally be different /boot partitions. The next step to is how does the bootloader know? Here is how:

menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
        initrd /boot/initrd-3.10.17-g

menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3 
        initrd /boot/initrd-3.10.17-g

This is an excerpt from a grub2 configuration and you'll note that the only differences are root=hd0,1 and root=hd1,1 which establish which boot partition that entry references.

Now to walk you though a boot so you can understand what is going on here.

  • The BIOS reads the MBR from the boot volume and jumps to the bootloader
  • The bootloader (e.g. grub2) is configured to know which device and partition contains your kernel. Grub2 accesses this partition directly and loads your kernel into memory.
  • Your bootloader then jumps into the kernel and the kernel boots your machine.

The bootloader doesn't care how many boot partitions you have, it only cares where they are and you must tell it that information.

The kernel doesn't care how many boot partitions you have, because it never needs to see them (you only need to have it available to add new kernels for example).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.