Linux Boot Process - Chart

Discussion in 'General Linux' started by nixsavy, Sep 26, 2013.

  1. nixsavy

    nixsavy Member

    Messages:
    65
    Likes Received:
    17
    Trophy Points:
    8
    Last edited: May 2, 2014
    ryanvade likes this.
  2. ryanvade

    ryanvade Administrator Staff Member Staff Writer

    Messages:
    1,139
    Likes Received:
    383
    Trophy Points:
    83
  3. Codypy1

    Codypy1 Member

    Messages:
    85
    Likes Received:
    32
    Trophy Points:
    18
    Awesome! Thanks for sharing with us!!!
  4. nixsavy

    nixsavy Member

    Messages:
    65
    Likes Received:
    17
    Trophy Points:
    8

    GRUB stage 1.5 which is file system specific code used to find the operating system image on the /boot (/boot/grub/*.stage) file system.

    GRUB version 1

    BIOS code reads MBR from a disk (looks at last 2 bytes to verify if MBR).
    Starts executing bootloader code (GRUB stage 1).
    Bootloader jumps to location (sector num) of next stage. This sector num is stored at a particular location in the bootloader "code" at GRUB install time and usually points to a stage 1.5 located in the "DOS compat space" immediately after the MBR.

    Stage 1.5 knows about the boot file system so it opens the file system on the specified (at install time) partition. It looks for the stage 2 executable here and executes it. Note since stage 1.5 knows about the boot file system it gives much greater flexibility in upgrading stage 2 and the kernel etc. as their new locations don't need to be written to the earlier GRUB stages.

    Stage 2 contains most of the GRUB logic. It loads the menu.lst file and executes the statements, usually providing a menu to the user etc.

    When GRUB starts booting one of the entries, it reads the initial ramdisk and starts the kernel running telling it about the ramdisk.

    In the initial ramdisk, the nash shell is run to parse the /linuxrc file. It essentially finds the location of the file system it itself is on and passes that to the kernel as its root (/) file system. This allows for greater flexibility of the devices the kernel resides on.

    The kernel reads its root (/) file system and executes /bin/init by default. This in turn parses /etc/inittab which usually sets up the login consoles and starts executing the scripts in /etc/init.d

    These scripts start various subsystems, culminating in starting X. X in turn starts the display manager which gives a login prompt.

    Grub version 2


    The structure of GRUB images has changed quite a bit with version 2, (which is still in development at the time of writing). Instead of stage 1, stage 1.5 and stage 2 images it has a collection of modules that can be combined in different ways. To mirror the functionality the original GRUB's stages as described above, you would have for example:

    stage 1 = boot.img
    stage 1.5 = diskboot.img+kernel.img+pc.mod+ext2.mod (the core image)
    stage 2 = normal.mod+_chain.mod
    The boot process for GRUB 2 then would be:

    BIOS code reads MBR from a disk (looks at last 2 bytes to verify if MBR).

    Starts executing bootloader code (boot.img).

    This loads the first sector of the core image (diskboot.img), whose location was stored at a particular location in boot.img at GRUB install time and usually points to the core image located in the "DOS compat space" immediately after the MBR. diskboot.img in turn loads and executes the rest of the core image.

    These core image modules know about the boot file system and can open the file system on the specified (at install time) partition. It looks for and loads modules there, including normal.mod

    normal.mod loads the grub.cfg file and executes the statements, usually providing a menu to the user etc.
    ryanvade likes this.

Share This Page