List of Topics
1) Steps involved in Linux Booting
2) List of process in Booting
a) BIOS
b) Boot Loader
c) Kernel
d) Init
e) Runlevel
3) Sample Boot (GRUB) Configuration file
4) Boot loader restoration
1) Steps involved in Linux Booting
Linux Booting involves following five steps. BIOS,
BOOT LOADER, KERNEL, INIT and RUNLEVEL. Below diagram is the exact procedure
how Linux OS is booting. In the following sections we will see about the below processes the in
detail.
When a boot device is found, the first-stage boot
loader is loaded into RAM and executed. This boot loader is less than 512 bytes
in length (a single sector), and its job is to load the second-stage boot
loader.
When the second-stage boot loader is in RAM and
executing, a splash screen is commonly displayed, and Linux and an optional
initial RAM disk (temporary root file system) are loaded into memory. When the
images are loaded, the second-stage boot loader passes control to the kernel
image and the kernel is decompressed and initialized. At this stage, the
second-stage boot loader checks the system hardware, enumerates the attached
hardware devices, mounts the root device, and then loads the necessary kernel
modules. When complete, the first user-space program (init) starts, and
high-level system initialization is performed.
2) List of process in Detail
a) BIOS
BIOS stands for Basic Input/Output System. BIOS is the 1st step of booting process and it performs Power-On Self-Test (POST). POST performs some integrity test and checks the status of hardware status and its functionality.
After POST, then BIOS Searches, loads, and executes the boot loader
program. It looks for boot loader in the selected bootable media eg: floppy, cd-rom, or hard drive. Once the boot
loader program is detected and loaded into the memory, BIOS gives the control
to it. So, in simple BIOS loads and executes the boot loader which resides in MBR.
a.2) MBR
MBR stands for Master Boot Record. It is located in the 1st sector of the bootable disk. (eg /dev/hda, or /dev/sda ). MBR is less than 512 bytes in size. This has three
components
a) primary
boot loader info in 1st 446 bytes
Located in the final two
bytes of the MBR (511-512), this section must contain the hex value AA55, which
officially classifies this as a valid MBR. An invalid magic number indicates a
corrupt or missing MBR, therefore these bytes are critical to booting or using
the disk.
Also, please keep in mind
that the Magic Number is a hexadecimal number and is often represented as
0xAA55 or AA55h, but when viewed in a hex or disk editor it would be displayed
as: "55 AA"
So, in simple terms MBR loads and executes the boot loader.
b) Boot Loader (GRUB)
In Linux We have two types of Boot loader LILO and GRUB. LILO is the old one. At present GRUB is used majorly in the field. GRUB means Grand Unified Boot Loader. Grub will display the list of kernels which is installed in your system. The screen which shows the list of installed kernels is called as splash image. From the displaying list we can choose anyone of the kernel which has to be executed. If nothing is selected then it will select the default one. All these parameter's are configured in /boot/grub/grub.conf and can be changed as per the requirement.
As per the image in the first section GRUB has three stages Stage 1, Stage 1.5 and Stage 2. We can check the stage 1.5 files just by listing under /boot/grub/ directory. If there are files with name 1_5 (eg: jfs_stage1_5) then stage 1.5 is there if no files with 1_5 then there is no stage 1.5
Let us see what will happen in the stages of GRUB
Stage 1 - Primary boot
loader is read into memory by the BIOS from the MBR. The primary boot loader
exists on less than 512 bytes of disk space within the MBR and is capable of
loading either the Stage 1.5 or Stage 2 boot loader.
Stage 1.5 - Boot loader is
read into memory by the Stage 1 boot loader, if necessary. Some hardware
requires an intermediate step to get to the Stage 2 boot loader. This is
sometimes true when the /boot/ partition is above the 1024 cylinder head of the
hard drive or when using LBA mode. The Stage 1.5 boot loader is found either on
the /boot/ partition or on a small part of the MBR and the /boot/ partition.
Stage 2 - Secondary
boot loader is read into memory. The secondary boot loader displays the GRUB
menu and command environment. This interface allows selection of the kernel or
operating system to boot, pass arguments to the kernel, or look at system parameters.
The secondary boot loader
reads the operating system or kernel and initrd into memory. Once GRUB
determines which operating system to start, it loads it into memory and
transfers control of the machine to that operating system.
The secondary, or second-stage, boot loader could be
more aptly called the kernel loader. The task at this stage is to load the
Linux kernel and optional initial RAM disk.
Why GRUB uses three stage Boot Loader
GRUB uses three stage boot loader to load the kernel from either ext2, 3 or 4 filesystem Instead of using raw sectors on the disk, as
LILO. For this purpose it makes the two-stage boot loader into a three-stage boot loader.
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.
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.
c) Kernel
Mounts the root file system as specfied in grub.conf root=" ". Then executes /sbin/init program. initrd stands for initial RAM disk. initrd is used by kernel as temporary root file system until kernel is booted and the real root file system is mounted. It also contains necessary drivers compiled inside which helps to access the hard drive partitions and other hardware.
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 (see Figure 3
for the major flow). 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.
Figure 3. Major functions flow for the Linux kernel
i386 boot
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 (via pivot_root) where the initrd root file system is
unmounted and the real root file system is mounted.
The decompress_kernel function is where you see the
usual decompression messages emitted to the display:
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).
https://www.ibm.com/developerworks/library/l-linuxboot/index.html
d) Init
Init is the first process to be started and it is the parent process for all the process in linux. PID of init process is 1. Then it looks for the default runlevel configured in /etc/inittab. Post identifying the default run level it starts the respective program for that particular run level. Following are the available run levels
0 – halt
e) Runlevel programs
When the Linux system is booting, you can see various services getting started. For example, it might show “starting SSHD …. OK”. Those are the programs, executed from the run level directory as defined by you.
/etc/rc.d/init.d - has the scripts which will be used by the files /etc/rc.d/rc[0-6].d/
Depending on your default init level setting, the system will execute the programs from one of the following directories. Run level 0 – /etc/rc.d/rc*.d/ . [* -Run level - 0- 6 ]
Please note that there are also symbolic links available for these directory under /etc directly. So, /etc/rc0.d is linked to /etc/rc.d/rc0.d.
Under the /etc/rc.d/rc*.d/ directories, you would see programs that start with S and K.
Programs starts with S are used during startup. S for startup. Programs starts with K are used during shutdown. K for kill.
There are numbers right next to S and K in the program names. Those are the sequence number in which the programs should be started or killed. For example, S12syslog is to start the syslog deamon, which has the sequence number of 12. S80sendmail is to start the sendmail daemon, which has the sequence number of 80. So, syslog program will be started before sendmail.
2) List of process in Booting
a) BIOS
b) Boot Loader
c) Kernel
d) Init
e) Runlevel
3) Sample Boot (GRUB) Configuration file4) Boot loader restoration
1) Steps involved in Linux Booting
Linux Booting involves following five steps. BIOS, BOOT LOADER, KERNEL, INIT and RUNLEVEL. Below diagram is the exact procedure how Linux OS is booting. In the following sections we will see about the below processes the in detail.
a) BIOS
BIOS stands for Basic Input/Output System. BIOS is the 1st step of booting process and it performs Power-On Self-Test (POST). POST performs some integrity test and checks the status of hardware status and its functionality. After POST, then BIOS Searches, loads, and executes the boot loader program. It looks for boot loader in the selected bootable media eg: floppy, cd-rom, or hard drive. Once the boot loader program is detected and loaded into the memory, BIOS gives the control to it. So, in simple BIOS loads and executes the boot loader which resides in MBR.
a.2) MBR
MBR stands for Master Boot Record. It is located in the 1st sector of the bootable disk. (eg /dev/hda, or /dev/sda ). MBR is less than 512 bytes in size. This has three
components
a) primary
boot loader info in 1st 446 bytes
b) partition
table info in next 64 bytes
c) mbr
validation check in last 2 bytes.
Located in the final two
bytes of the MBR (511-512), this section must contain the hex value AA55, which
officially classifies this as a valid MBR. An invalid magic number indicates a
corrupt or missing MBR, therefore these bytes are critical to booting or using
the disk.
Also, please keep in mind
that the Magic Number is a hexadecimal number and is often represented as
0xAA55 or AA55h, but when viewed in a hex or disk editor it would be displayed
as: "55 AA"
So, in simple terms MBR loads and executes the boot loader.
b) Boot Loader (GRUB)
In Linux We have two types of Boot loader LILO and GRUB. LILO is the old one. At present GRUB is used majorly in the field. GRUB means Grand Unified Boot Loader. Grub will display the list of kernels which is installed in your system. The screen which shows the list of installed kernels is called as splash image. From the displaying list we can choose anyone of the kernel which has to be executed. If nothing is selected then it will select the default one. All these parameter's are configured in /boot/grub/grub.conf and can be changed as per the requirement.
b) Boot Loader (GRUB)
In Linux We have two types of Boot loader LILO and GRUB. LILO is the old one. At present GRUB is used majorly in the field. GRUB means Grand Unified Boot Loader. Grub will display the list of kernels which is installed in your system. The screen which shows the list of installed kernels is called as splash image. From the displaying list we can choose anyone of the kernel which has to be executed. If nothing is selected then it will select the default one. All these parameter's are configured in /boot/grub/grub.conf and can be changed as per the requirement.
As per the image in the first section GRUB has three stages Stage 1, Stage 1.5 and Stage 2. We can check the stage 1.5 files just by listing under /boot/grub/ directory. If there are files with name 1_5 (eg: jfs_stage1_5) then stage 1.5 is there if no files with 1_5 then there is no stage 1.5
Let us see what will happen in the stages of GRUB
Stage 1 - Primary boot
loader is read into memory by the BIOS from the MBR. The primary boot loader
exists on less than 512 bytes of disk space within the MBR and is capable of
loading either the Stage 1.5 or Stage 2 boot loader.
Stage 1.5 - Boot loader is
read into memory by the Stage 1 boot loader, if necessary. Some hardware
requires an intermediate step to get to the Stage 2 boot loader. This is
sometimes true when the /boot/ partition is above the 1024 cylinder head of the
hard drive or when using LBA mode. The Stage 1.5 boot loader is found either on
the /boot/ partition or on a small part of the MBR and the /boot/ partition.
Stage 2 - Secondary
boot loader is read into memory. The secondary boot loader displays the GRUB
menu and command environment. This interface allows selection of the kernel or
operating system to boot, pass arguments to the kernel, or look at system parameters.
The secondary boot loader
reads the operating system or kernel and initrd into memory. Once GRUB
determines which operating system to start, it loads it into memory and
transfers control of the machine to that operating system.
The secondary, or second-stage, boot loader could be more aptly called the kernel loader. The task at this stage is to load the Linux kernel and optional initial RAM disk.
Why GRUB uses three stage Boot Loader
GRUB uses three stage boot loader to load the kernel from either ext2, 3 or 4 filesystem Instead of using raw sectors on the disk, as
LILO. For this purpose it makes the two-stage boot loader into a three-stage boot loader.
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.
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.
Mounts the root file system as specfied in grub.conf root=" ". Then executes /sbin/init program. initrd stands for initial RAM disk. initrd is used by kernel as temporary root file system until kernel is booted and the real root file system is mounted. It also contains necessary drivers compiled inside which helps to access the hard drive partitions and other hardware.
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.
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 (see Figure 3 for the major flow). 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.
Figure 3. Major functions flow for the Linux kernel i386 boot
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 (via pivot_root) where the initrd root file system is unmounted and the real root file system is mounted.
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.
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).
d) Init
Init is the first process to be started and it is the parent process for all the process in linux. PID of init process is 1. Then it looks for the default runlevel configured in /etc/inittab. Post identifying the default run level it starts the respective program for that particular run level. Following are the available run levels
0 – halt
1 – Single user mode
2 – Multiuser, without NFS
3 – Full multiuser mode
4 – unused
5 – X11
6 – reboot
e) Runlevel programs
When the Linux system is booting, you can see various services getting started. For example, it might show “starting SSHD …. OK”. Those are the programs, executed from the run level directory as defined by you.
Depending on your default init level setting, the system will execute the programs from one of the following directories. Run level 0 – /etc/rc.d/rc*.d/ . [* -Run level - 0- 6 ]
Please note that there are also symbolic links available for these directory under /etc directly. So, /etc/rc0.d is linked to /etc/rc.d/rc0.d.
Under the /etc/rc.d/rc*.d/ directories, you would see programs that start with S and K.
Programs starts with S are used during startup. S for startup. Programs starts with K are used during shutdown. K for kill.
There are numbers right next to S and K in the program names. Those are the sequence number in which the programs should be started or killed. For example, S12syslog is to start the syslog deamon, which has the sequence number of 12. S80sendmail is to start the sendmail daemon, which has the sequence number of 80. So, syslog program will be started before sendmail.
3) Sample Boot (GRUB) Configuration file
########################################################
#boot=/dev/sda
default=0
initrd /boot/initrd-2.6.18-194.el5PAE.img
########################################################
4) Boot Loader restoration
Case 1) Steps to re-install grub
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-194.el5PAE)
root
(hd0,0)
kernel /boot/vmlinuz-2.6.18-194.el5PAE
ro root=LABEL=/
initrd /boot/initrd-2.6.18-194.el5PAE.img
########################################################
4) Boot Loader restoration
Case 1) Steps to re-install grub
install grub stage 1
grub> setup
Case 2) Steps executed for /boot recovery if
deleted
grub> setup
Case 2) Steps executed for /boot recovery if deleted
install grub stage 1 grub> setup command
reinstall kernel package.
first remove it then re-install it
Then create grub.conf file
Reboot the server and check it
https://www.ibm.com/developerworks/library/l-initrd/
The boot loader is responsible for loading both the
kernel image and the initrd image into memory. They both will be in memory,
before the boot loader hands control over to the kernel.
The kernel will receive the address where the initrd
is in memory; it will just "interpret" it as if it were a full
filesystem, in RAM. (The kernel does actually decompress it first. CPIO is
used, because it is simple and robust to implement, requires not too much code,
and has all the features needed.
https://www.ibm.com/developerworks/library/l-initrd/
The boot loader is responsible for loading both the
kernel image and the initrd image into memory. They both will be in memory,
before the boot loader hands control over to the kernel.
The kernel will receive the address where the initrd
is in memory; it will just "interpret" it as if it were a full
filesystem, in RAM. (The kernel does actually decompress it first. CPIO is
used, because it is simple and robust to implement, requires not too much code,
and has all the features needed.
No comments:
Post a Comment