Grub_Legacy

BIOS = Basic INPUT\OUTPUT system executes MBR

MBR = Master Boot Record executes GRUB

GRUB = Grand Unified Bootloader executes kernel

Kernel = kernel executes /sbin/init

init = init executes run level program

Run level = run level are program executes from /etc/rc. d/rc*. d/

BIOS

In a PC, booting Linux begins in the BIOS at address 0xFFFF0.

1.      The first step of the BIOS is the power-on self-test (POST). The job of the POST is to perform a check of the hardware.

2.      The second step of the BIOS is local device enumeration (எண்ணுகிறது or mention (a number of things) one by one) and initialization.

3.      To boot an operating system, the BIOS runtime searches for devices that are both active and bootable in the order of preference defined by the CMOS settings.

MBR

The Master Boot Record (MBR) contains the primary boot loader. The MBR is a 512-byte sector, located in the first sector on the disk (sector 1 of cylinder 0, head 0). After the MBR is loaded into RAM, the BIOS yields control to it.

The primary boot loader that resides in the MBR is a 512-byte image containing both program code and a small partition table

8 bits = 1 byte

1,024 bytes = 1 kilobyte

1,024 kilobytes = 1 megabyte

1,024 megabytes = 1 gigabyte

1,024 gigabytes = 1 terabyte

Extracting the MBR

Here are the steps to take backup of you MBR and keep it in safe place to restore your system if it get corrupted.

# dd if=/dev/hdx of=/file_name bs=512 count=1    (bs= block size)

# file file-name

# od -xa mbr.bin

The od command prints the binary file in hex and ASCII formats.

Backup and Restore MBR

Backup

# dd if=/dev/sdX of=/tmp/sda-mbr.bin bs=512 count=1

Restore

# dd if= sda-mbr.bin of=/dev/sdX bs=1 count=64 skip=446 seek=446

MBR Details 446+64+2=512

446 bytes (Primary Boot loader)

Primary boot loader code provides bootloader information and location details of actual boot loader code on the HDD. This is helpful for CPU to load second stage boot loader

The first 446 bytes are the primary boot loader, which contains both executable code and error message text.

64 bytes (Partition table)

16+16+16+16=64

This 64 bytes of data which stores partition table information such as what is the start and end of each partition, type of partition (whatever it is primary or secondary etc…),Due to this HDD support only 4 partition.

For a partition to present in MBR it required 16 bytes of space in it

2bytes (Magic Numbers)

             Magic number (0xAA55). The magic number serves as a validation check of the MBR. If MBR gets corrupted this magic number is used to retrieve it

GRUB

The /boot/grub directory contains the stage1, stage1.5, and stage2 boot loaders, as well as a number of alternate loaders (for example, CR-ROMs use the iso9660_stage_1_5).

GRUB includes knowledge of Linux file systems. GRUB can load a Linux kernel from an ext2 or ext3 file system. It does this by making the two-stage boot loader into a three-stage boot loader.

Stage 1

The job of the primary boot loader is to find and load the secondary boot loader (stage 2). It does this by looking through the partition table for an active partition. When it finds an active partition, it scans the remaining partitions in the table to ensure that they're all inactive. When this is verified, the active partition's boot record is read from the device into RAM and executed.

An Un-amended copy of stage1 code can be found in the file /boot/grub/stage1

# file stage1

stage1: x86 boot sector, code offset 0x48

Stage1 code is stored in MBR. This code contains a block list that points to the next stage of GRUB

Stage 1.5

Stage 1 (MBR) boots a stage 1.5 boot loader that understands the particular file system containing the Linux kernel image. Examples include reiserfs_stage1_5 (to load from a Reiser journaling file system) or e2fs_stage1_5 (to load from an ext2 or ext3 file system). When the stage 1.5 boot loader is loaded and running, the stage 2 boot loader can be loaded.

Note :-

Ext4 file system does not require GRUB stage1.5

Now how the GRUB access those files without file system driver?

Stage 1.5 located in MBR GAP (sector 1 to 63 before the beginning of the first partition) basically contains the drivers for reading file systems.

Grub stage 1 will load grub stage1.5 to the RAM and it pass control to it

[root@localhost grub]# pwd

/boot/grub

[root@localhost grub]# ls -lrth *stage1_5

-rw-r--r-- 1 root root 8.7K Sep 21 09:59 xfs_stage1_5

-rw-r--r-- 1 root root 6.2K Sep 21 09:59 vstafs_stage1_5

-rw-r--r-- 1 root root 7.0K Sep 21 09:59 ufs2_stage1_5

-rw-r--r-- 1 root root 9.1K Sep 21 09:59 reiserfs_stage1_5

-rw-r--r-- 1 root root 6.8K Sep 21 09:59 minix_stage1_5

-rw-r--r-- 1 root root 8.1K Sep 21 09:59 jfs_stage1_5

-rw-r--r-- 1 root root 6.6K Sep 21 09:59 iso9660_stage1_5

-rw-r--r-- 1 root root 6.6K Sep 21 09:59 ffs_stage1_5

-rw-r--r-- 1 root root 7.3K Sep 21 09:59 fat_stage1_5

-rw-r--r-- 1 root root 7.5K Sep 21 09:59 e2fs_stage1_5

[root@localhost grub]#

Now GRUB stage 1.5 will load the file system drivers and once the file system drivers are loaded, it can now access /boot/grub/grub.conf file which contains other details about kernel path and initrd path …etc…

Now this is the point where you are presented with a beautiful TUI, where you can select your operating system kernel and press enter to boot it

Stage 2

The stage 2 code is stored in the file /boot/grub/grub.conf

[root@localhost grub]# file stage2

stage2: data

[root@localhost grub]#

With stage 2 loaded, GRUB can, upon request, display a list of available kernels (defined in /etc/grub.conf, with soft links from /etc/grub/menu.lst and /etc/grub.conf). You can select a kernel and even amend it with additional kernel parameters. Optionally, you can use a command-line shell for greater manual control over the boot process.

With the second-stage boot loader in memory, the file system is consulted, and the default kernel image and initrd image are loaded into memory. With the images ready, the stage 2 boot loader invokes the kernel image.

Kernel

With the kernel image in memory and control given from the stage 2 boot loader, the kernel stage begins.

The kernel image isn't so much an executable kernel, but a compressed kernel image. Typically this is a zImage (compressed image, less than 512KB) or a bzImage (big compressed image, greater than 512KB), that has been previously compressed with zlib.

At the head of this kernel image is a routine that does some minimal amount of hardware setup and then decompresses the kernel contained within the kernel image and places it into high memory. If an initial RAM disk image is present, this routine moves it into memory and notes it for later use. The routine then calls the kernel and the kernel boot begins.

When the bzImage (for an i386 image) is invoked, you begin at ./arch/i386/boot/head.S in the start assembly routine. This routine does some basic hardware setup and invokes the startup_32 routine in ./arch/i386/boot/compressed/head.S. This routine sets up a basic environment (stack, etc.) and clears the Block Started by Symbol (BSS). The kernel is then decompressed through a call to a C function called decompress_kernel (located in ./arch/i386/boot/compressed/misc.c). When the kernel is decompressed into memory, it is called. This is yet another startup_32 function, but this function is in ./arch/i386/kernel/head.S.

In the new startup_32 function (also called the swapper or process 0), the page tables are initialized and memory paging is enabled. The type of CPU is detected along with any optional floating-point unit (FPU) and stored away for later use. The start_kernel function is then invoked (init/main.c), which takes you to the non-architecture specific Linux kernel. This is, in essence, the main function for the Linux kernel.

With the call to start_kernel, a long list of initialization functions are called to set up interrupts, perform further memory configuration, and load the initial RAM disk. In the end, a call is made to kernel_thread (in arch/i386/kernel/process.c) to start the init function, which is the first user-space process. Finally, the idle task is started and the scheduler can now take control (after the call to cpu_idle). With interrupts enabled, the pre-emptive scheduler periodically takes control to provide multitasking.

During the boot of the kernel, the initial-RAM disk (initrd) that was loaded into memory by the stage 2 boot loader is copied into RAM and mounted. This initrd serves as a temporary root file system in RAM and allows the kernel to fully boot without having to mount any physical disks. Since the necessary modules needed to interface with peripherals can be part of the initrd, the kernel can be very small, but still support a large number of possible hardware configurations. After the kernel is booted, the root file system is pivoted(மையம்(the center point)) (via pivot_root) where the initrd root file system is unmounted and the real root file system is mounted.

The initrd function allows you to create a small Linux kernel with drivers compiled as loadable modules. These loadable modules give the kernel the means to access disks and the file systems on those disks, as well as drivers for other hardware assets. Because the root file system is a file system on a disk, the initrd function provides a means of bootstrapping to gain access to the disk and mount the real root file system. In an embedded target without a hard disk, the initrd can be the final root file system, or the final root file system can be mounted via the Network File System (NFS).

Manual boot in GRUB

From the GRUB command-line, you can boot a specific kernel with a named initrd image as follows:

grub> kernel /bzImage-2.6.14.2
  [Linux-bzImage, setup=0x1400, size=0x29672e]

grub> initrd /initrd-2.6.14.2.img
  [Linux-initrd @ 0x5f13000, 0xcc199 bytes]

grub> boot

Uncompressing Linux... Ok, booting the kernel.

If you don't know the name of the kernel to boot, just type a forward slash (/) and press the Tab key. GRUB will display the list of kernels and initrd images.

decompress_kernel output

The decompress_kernel function is where you see the usual decompression messages emitted to the display:

Uncompressing Linux... Ok, booting the kernel.

Initrd is available in the form of image similar to the kernel image file

#cd /boot

#mount –t sysfs initrd.-xx.img /mount-point

Init

After the kernel is booted and initialized, the kernel starts the first user-space application. This is the first program invoked that is compiled with the standard C library. Prior to this point in the process, no standard C applications have been executed.

In a desktop Linux system, the first application started is commonly /sbin/init. But it need not be. Rarely do embedded systems require the extensive initialization provided by init (as configured through /etc/inittab). In many cases, you can invoke a simple shell script that starts the necessary embedded applications

The Kernel boot parameters that were last used to boot a system are recorded in /proc/cmdline

[root@www boot]# cat /proc/cmdline

ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 crashkernel=128M rd_LVM_LV=VolGroup/lv_root  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet

[root@www boot]#

The Hard disk sector are counted from 0 to the last sector. Sector0 contain grub stage 1. Normally partition will not start before sector number 63. Partition will start from sector number 63. Hence we have free sectors from 1-63 this space is used for starting GRUB stage 1.5.This free space between MBR and the beginning of the partition is called as MBR GAP