Understanding Linux Boot Process
Linux Boot Process Involves multiple Steps, let’s explore the entire boot process:
Step 1: Power on the Machine
Step 2: Run POST and Identify the boot Device
Step 3: Read the GRUB Boot loader from the MBR of Boot device
The Grand Unified Bootloader has become the default bootloader for Red Hat, Ubuntu, and many otherversions of Linux as well.
The bootloader can be used to boot into different operating systems (usually called a multiboot system), for system recovery, and to boot the kernel using special arguments.
Step 4: When GRUB loads, you are given a list of kernels and additional operating systems (if available) from which you can choose to boot
By default, there is a configurable 5-second timeout value that chooses the default kernel if you don’t make a selection and the timeout threshold is reached
Step 5: After GRUB loads the kernel, it passes control over to the kernel, which in turn begins to initialize and configure the computer’s hardware.
When the system’s drivers are in place, the kernel executes the /sbin/init program.
Note 1: During the boot process, everything is logged to the /var/log/dmesg file.
Note 2: You can also use the dmesg command to query information about the boot process after the system has booted.
Step 6: The init program is the first process created by the kernel. It is responsible for the rest of the boot process and setting up the environment for the user.
First, it consults the /etc/inittab file, which defines how the rest of the boot process will go. The /etc/inittab file lists the default runlevel to boot into and the system initialization script (/etc/rc.d/rc.sysinit).
Let’s look at the /etc/inittab file to see what the init process goes through:
# cat /etc/inittab
# inittab This file describes how the INIT process should set up
# the system in a certain run-level.
# Author: Miquel van Smoorenburg, <email@example.com>
# Modified for RHS Linux by Marc Ewing and Donnie Barnes
# Default runlevel. The runlevels used by RHS are:
# 0 – halt (Do NOT set initdefault to this)
# 1 – Single user mode
# 2 – Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 – Full multiuser mode
# 4 – unused
# 5 – X11
# 6 – reboot (Do NOT set initdefault to this)
# System initialization.
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
# When our UPS tells us power has failed, assume we have a few minutes
# of power left. Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have power installed and your
# UPS connected and working correctly.
pf::powerfail:/sbin/shutdown -f -h +2 “Power Failure; System Shutting Down”
# If power was restored before the shutdown kicked in, cancel it.
pr:12345:powerokwait:/sbin/shutdown -c “Power Restored; Shutdown Cancelled”
# Run gettys in standard runlevels
# Run xdm in runlevel 5
From ther above file, you can see that the default runlevel is set to 5, although six different runlevels are listed. This default runlevel is passed to the /etc/rc.d/rc script, which calls all the programs in the /etc/rc.d/rc#.d directory.
The /etc/inittab file also defines how to handle power failures and virtual terminals.
Step 7 : After the init process is done consulting the /etc/inittab file, the /etc/rc.d/rc.sysinit script is run, which handles setting the system clock, networking, setting up the user environment, and more.
Step 8 : The last thing that you should see is the login prompt.
If you have a desktop manager installed such as Gnome, you should see a GUI login screen where you can log in to the system; otherwise, you see a text mode login. This completes the boot process.
Understanding GRUB ( Version 1 ) and Working with it
1. How Grub Works
The GRUB bootloader is broken down into different stages.
- The code contained on the master boot record (MBR) is considered GRUB stage 1.It loads GRUB stage 1.5,
- Stage 1.5 which tries to identify the file system type (optional), or it can call GRUB stage 2 directly.
- Stage 2 is what calls the kernel and loads it into memory.
In stage 1, GRUB needs to search the MBR looking for an active partition from which to boot the kernel. GRUB has its own format for looking through hard disks.
The syntax of this format is
(xdn[,m]) where xd is the drive, n is the number of the disk, and m denotes the partition number.
This syntax is very useful when troubleshooting issues with GRUB because you need to know how GRUB searches for disk drives when trying to find the primary partition.
- When the primary partition is found, GRUB loads the kernel, which is where you move on to stage 2.
- Stage 2 is the place where you will tend to spend the most time troubleshooting boot issues with the system.
As stage 2 starts, it presents you with a list of kernels that you can boot from, along with a listing of options that you can use to modify the parameters passed to the kernel during bootup.
Now let’s look at how to edit those entries
Grub Boot Options:
- Press e Edit the commands before booting
- Press a Modify or append the kernel arguments before booting
- Press c Open the GRUB command line
Highlighting the Boot Entry from above image and and pressing the letter “e” will take take you to the screen, as shown in below figure.
from this screen you can modify each line to control you behavior . and the most common task that we normally do at this screen is changing the “kernel ….. ” line to boot the machine into any of the below running state for troubleshooting and other maintenance tasks.
you can modify kernel entry from the above image . Here are the different modes that you can boot into:
- Single-User Mode Used to perform maintenance tasks or if you forget the root password
- Runlevel 2 or 3 Used to load only partial services during the boot process
- Emergency Mode Used to perform tasks on an unbootable system
- Rescue Mode Used to fix boot issues or reinstall GRUB
2.GRUB Configuration File :
GRUB Boot loader works based on the configuration mentioned in /etc/grub.conf ( actually a link file to /boot/grub/grub.conf).
Sample grub.conf file
# cat grub.conf
title Red Hat Enterprise Linux (2.6.32-71.el6.x86_64)
kernel /vmlinuz-2.6.32-71.el6.x86_64 ro root=/dev/mapper/vg_rhel01-lv_root
rd_LVM_LV=vg_rhel01/lv_root rd_LVM_LV=vg_rhel01/lv_swap rd_NO_LUKS rd_NO_MD
rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc
KEYTABLE=us crashkernel=auto rhgb quiet
Explanation about the grub.conf file:
- In the preceding example, you can see that there is a single option to boot from, as defined by the title entry. This is also known as entry 0, so it becomes the default kernel to boot from.
- You can also see the version of the kernel that you are using and the place where the root partition will be mounted from during the boot process.
- If you want to add additional options to boot into, you could append another title with options for a second boot choice.
- This grub.conf file contains everything you need to make sure the boot process works smoothly.
- the file also defines additional options such as encryption, RAID, and use of the /dev/mapper for LVM management
3. GRUB Command line
One task that is common in the real world and also a possible exam question is how to repair a broken MBR. For this to happen, you need to make use of the rescue environment, which can be found by booting from the RHEL installation DVD. When you are in the rescue environment, you can repair your broken MBR.
Step 1. Load up the GRUB command line to find the disk and partition that contain the grub.conf file using the find command:
grub> find /grub/grub.conf
You could also run:
(hd0,0): Filesystem type is unknown, partition type 0x8e
Step 2. Install GRUB on the drive that is returned:
grub> setup (hd0)
Checking if “/boot/grub/stage1” exists… no
Checking if “/grub/stage1” exists… yes
Checking if “/grub/stage2” exists… yes
Checking if “/grub/e2fs_stage1_5” exists… yes
Running “embed /grub/e2fs_stage1_5 (hd0)”… 26 sectors are embedded.
Running “install /grub/stage1 (hd0) (hd0)1+26 p
Now that your MBR is fixed, you should be able to boot into the system once again.
The preceding example also shows where the boot partition is located (partition 0 on disk 0), as well as the file system type. It is important that you also back up the grub.conf file in case something happens to your system; that way, you can easily restore it.
Shutting Down a Linux System for routine maintenance Tasks
Let’s look at some examples for a better understanding the procedure of System Shutdown
you can use the shutdown command to bring the system to a powered-off state or reboot the system. The shutdown command also has options to alert users on the system when it is going down and to set up a shutdown at a particular time.
Syntax: shutdown [options] time
-k Doesn’t shut down; just warns
-h Halts the system after shutdown
-r Reboots instead of turning off the system
-F Forces a file system check on reboot
-n Kills all processes quickly (not recommended)
-t SECS Sends a shutdown message but delays shutdown by x seconds
1. Command to Just turn off the system
# shutdown -h now
2. This time instead of a complete power off, reboot the system as follows:
# shutdown -r now
3. You could also use the reboot command to achieve the same effect:
4. As a final example, delay the shutdown by 2 minutes:
# shutdown -h 120
Similar to the shutdown command is the halt command. The halt command brings the system to a powered-off state like shutdown.
5. To turn off the system, you use this command:
# shutdown now
You could also use
Coinciding with the halt command are poweroff and reboot. The reason these commands all go hand in hand is that poweroff and reboot are actually both links to the halt command. You can verify this by using the following example:
# cd /sbin
# ll | grep halt
-rwxr-xr-x 1 root root 16152 Jan 21 2009 halt
lrwxrwxrwx 1 root root 4 Jul 22 2010 poweroff -> halt
lrwxrwxrwx 1 root root 4 Jul 22 2010 reboot -> halt
The difference is that each one calls the halt command with a different argument, yielding different results. The poweroff command, like halt, stops the system, whereas the reboot command restarts the system…obviously.