2. Exam Objectives
Key Knowledge Areas
Provide common commands to the boot loader and options to the kernel at boot time.
Demonstrate knowledge of the boot sequence from BIOS to boot completion.
Check boot events in the log files.
Objective 1: System Architecture
Boot the system Weight: 3
Terms and Utilities
/var/log/messages
dmesg
BIOS
bootloader
kernel
init
2
3. Boot the system
Boot process for PCs:
Boot overview
1. When PC is turned on, BIOS (Basic Input Output Service) performs a selftest;
2. When machine passes self test, BIOS loads Master Boot Record;
usually from first 512-byte sector of the boot drive.
This is usually the 1st hard drive on system, may also be diskette, CD, USB key.
3. For a hard drive, MBR loads a stage 1 boot loader;
Which is either LILO or GRUB stage1 boot loader on a Linux system.
This is another 512-byte, single-sector record.
4. stage 1 boot loader loads a sequence of records called stage 2 boot loader
(or sometimes the stage 1.5 loader).
5. stage 2 loader loads the operating system.
For Linux, this is the kernel, and possibly an initial RAM disk (initrd).
3
4. Boot the system
When BIOS has finished starting up, it loads first sector of boot disk into memory,
and runs the code it finds there.
On a floppy disk, boot sector is the first sector, and that‘s the whole story.
Boot with floppy
4
Floppy disk boot sector (“logical” layout)Ex:
5. Boot the system
For hard disks, the first sector of the disk (/dev/hda) is the partition sector.
•This usually contains a program that loads the boot sector from the “active” partition.
•This first sector is known as MBR (Master boot record).
Boot with disk
5
Each partition on a hard disk has its own boot sector.Ex:
MSoft operating systems (FDISK /MBR in MSDOS) install a partition sector loader to do the following:
• Check which partition is marked as “active”.
• Load the sector from the start of that partition and run it.
6. Boot the system
Linux boot loaders have characteristics in common:
boot loaders characteristics
6
The code stored on the boot sector or the partition sector is just the first stageloader.
This means that its not responsible for loading the operating system, but only for loading boot loader into memory.
•The boot loader can be configured to load other operating systems.
- When loading other operating systems, the boot loader may load them into
memory,
- or call that operating system's own boot loader.
•Interactively enter options to be passed to the kernel to be loaded.
- Kernel options are used, to indicate where the root filesystem is (root=/dev/hda3),
- and can be used for debugging (init=/bin/sh).
Chain loading
Occurs when the boot manager that is located in the master boot record (MBR)
loads the boot loader that is in a partition boot record.
7. Boot the system
stage 2 loaders used in LILO and GRUB allow to choose from several operating
systems or versions to load. However, LILO and GRUB differ significantly
Linux boot loaders
7
With LILO, a change to the system requires use of command to recreate LILO boot setup
whenever there’s changes to kernel or other changes to the system.
With GRUB, can accomplish changes with a configuration text file that can be edited.
With GRUB 2 also requires a rebuild from a configuration file normally stored in /etc.
During Linux installation, you will usually specify either LILO or GRUB manager.
If chosing GRUB, then you may not have LILO installed.
8. Boot the system
Installing another operating system can overwrite the MBR.
Some systems like DOS and Windows, always install their own MBR.
Recovery
8
Boot from floppy into the Linux system and rerun lilo or grub-install.
Linux distributions can also boot the Linux in recovery mode.
In recovery mode the root file system on the hard drive could not be mounted or mounted
in recovery mode.
Use chroot cmd to make the recovery mount point become the root (/) directory.
Then run lilo or grub-install to reinstall the MBR.
10. Boot the system
Recovery
10
With prompt in recovery u can create a mount point (/mnt/sysimage), mount /dev/sda6,
chroot into the mounted system. cat /etc/issue commands show effect of chroot cmd.
Ex: root@yourcomp:~# mkdir /mnt/sysimage
root@yourcomp:~# mount /dev/sda6 /mnt/sysimage
root@yourcomp:~# cd /mnt/sysimage
root@yourcomp:~# mount -t proc none proc/
root@yourcomp:~# mount -t sysfs none sys/
root@yourcomp:~# mount -o bind /dev dev/
root@yourcomp:~# cat /etc/issue
Ubuntu 9.10 n l
root@yourcomp:~# chroot /mnt/sysimage
root@yourcomp:~#
sh-3.00# chroot /mnt/sysimage
[root@yourcomp /]# cat /etc/issue
Fedora release 8 (Werewolf)
Kernel r on an m
[root@yourcomp /]# grub-install /dev/fd0
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.
(fd0) /dev/fd0
(hd0) /dev/sda
[root@yourcomp /]#
11. Boot the system
Kernel parameters
11
LILO and GRUB allow to edit cmdline that is passed to kernel when it boots.
Kernel boot parameters are used to override the hardware config parameters detected by the kernel.
Ex: root@yourcomp:~# cat /proc/cmdline
ro root=/dev/hda1 apm=off
Format parameters supplied are:
- single word; - format name=value; format name=value1,value2,value3.
Each name identifies which part of the kernel receives the option.
Default kernel command line always specifies the root filesystem, mounted ro read-only
12. Boot the system
Kernel parameters
12
Kernel cmdline Parameters used:
•single – boot into single user mode (with root password)
•emergency – boot into a shell (newer versions of init require the root password)
•1, 2, 3, 4, 5, 6 – boot into a specific runlevel.
cmdline parameters not used by kernel as environment variables to load the usual daemons,
are passed onto init process program ( /sbin/init).
bootparam(7) man page discusses the boot parameters in detail.
file /usr/src/linux/Documentation/kernelparameters.txt is a complete reference.
Ex: root@yourcomp:~# man bootparam
root@yourcomp:~# less /usr/src/linux/Documentation/kernel-parameters.txt
13. Boot the system
Kernel parameters
13
boot parameters used:
•root=/dev/hda1: change the root filesystem during bootup
•init=/sbin/init: kernel boot will run /sbin/init.
troubleshooting parameter is init=/bin/bash which runs an interactive shell instead of /sbin/init.
•mem=32M: limit the amount of memory to specified. kernel does not attempt to check memory actually present
•Noinitrd: don't execute /linuxrc on initial root disk image supplied by boot loader.
avoid the behaviour of initial root disk loading modules required for booting (filesystem support).
•Config devices compiled in Kernel with IO and IRQ settings in format: device=irq,iobase
•rdev cmd: used to modify a kernel image to not require boot options for:
- root device (rdev /boot/vmlinuz "/dev/hda7 "),
- VGA mode (vidmode /boot/vmlinuz "788"),
- Readonly/Readwrite root filesystem (rootflags ...)
•vga=value: changes display mode of VGA adapter
VESA graphics modes support:
Color depth 640x480 800x600 1024x768 1280x1024
8 bits 256 colours 769 771 773 775
15 bits 32768 colours 784 787 790 793
16 bits 65535 colours 785 788 791 794
24 bits 16.7 Million 786 789 792 795
14. Boot the system
Kernel parameters with LILO
14
To control booting using LILO, interrupt boot process using:
1.Press Shift: To obtain prompt, Shift before LILO begins booting if there’s no timeout specified in
lilo.conf.
2.Enter a password: lilo.conf can specify that password must be entered to change boot parameters.
LILO allows configuring the boot sequence in following ways:
1.Select kernel to boot or boot image to load: By typing it's name (press Tab to see list), or by
selecting it from a menu.
2.Add options to the kernel command line (you can't remove option that are already there)
LILO: linux root=/dev/fd0 rw init=/bin/bash
15. Boot the system
Kernel parameters with GRUB
15
GRUB's is free cross platform, so it does not follow Linux hard disk convention naming.
(fd0) – /dev/fd0
(hd0) – /dev/hda (SCSI = sd0)
(hd0,1) – /dev/hda2 (2nd
partition of 1st
disk)
To boot Linux, it is required that GRUB knows:
1.where are the files found (root);
2.where is the kernel found (kernel);
3.where is the initial root disk (initrd), that contain vital system modules (filesystem or SCSI controller).
The boot command tells GRUB to boot.
Ex: root (hd0,0) # source of grub files is
/dev/hda1
kernel /boot/vmlinuz root=/dev/hda1 # load a kernel
initrd /boot/initrd # load an initial root disk
boot # boot up
16. Boot the system
Kernel parameters with GRUB
16
GRUB commands that are in /etc/grub.conf, can be typed when the system boots.
Newer versions of GRUB print helpful menus, for the key-presses:
• p – enter a password
• c – start the GRUB command line (type GRUB configuration yourself)
• e – edit a GRUB configuration line
• a – modify kernel arguments before booting
• o – open a new line for configuration commands
• d – remove the selected line from the configuration
• b – boot the system
• Escape – return to the menu
17. Boot the system
Boot messages
17
When Linux kernel boots, each subsystem is initialised in a predetermined order.
The messages generated by each subsystem are generally displayed on the console.
And are also recorded in 2 places:
Ex:
yourname@yourcomp~> grep "^Apr.*d:" /var/log/messages|tail -n 14
Apr 2 15:36:50 lyrebird kernel: hdd: attached ide-scsi driver.
Apr 2 15:36:26 lyrebird rc.sysinit: Setting hostname lyrebird: succeeded
Apr 2 15:36:26 lyrebird rc.sysinit: Initializing USB keyboard: succeeded
Apr 2 15:36:55 lyrebird sshd: succeeded
Apr 2 15:36:57 lyrebird crond: crond startup succeeded
Listing daemon status messages after a reboot.
1.kernel message (ring) buffer – kernel keeps 16k of messages, displayed by dmesg command.
redirect output to a file for later analysis or forward it to a kernel developer for debugging purposes
2.syslogd records timestamped kernel messages to /var/log/messages.
• After system starts /sbin/init, kernel logs events in the ring buffer,
but processes use the syslog daemon to log messages, usually in /var/log/messages.
• Each syslog line has a timestamp, and the file persists between system restarts.
This file is where you should first look for errors that occurred during the init scripts stage of booting.
