======================
The Linux Boot Process
=======================
Part I
======
01. Power On
02. ROM - BIOS loaded into RAM auto by the boot code at the start of ROM [bootstrap]
Purpose of BIOS : Load the OS - any/some OS
03. POST - HW Inventory - Int 19H
04. CMOS - [Current bootable devices]
05. BIOS loads/starts [boots] whatever it finds in the first Sector [Sect 1] of HDD into RAM i.e. [cylinder 0, head 0, sector 1 of a hard disk]
- This first Sector is aka the MBR [on Windows-based systems]
Note: There is only one MBR per HDD, obviously !!
** During installation, when the Linux kernel is being installed, its exact size and location [CHS] on the HDD is stored in /boot/map in the /boot partition. By that we mean, the exact CHS no on the HDD of where it installed /boot/vmlinuz-2.4.20-8 Tis is the address of the Linux kernel on the HDD
06. BIOS then loads/executes [boots/runs] this first stage BL - which is
LILO [i.e /boot/boot.b] which is in the BS of the MBR and put there at install time AND NOT
/boot/boot.b from the /boot partition] and Transfers control to the it
Tis is called the 1st stage of bootloading
07. This first-stage BL has but one purpose in life : To load the 2nd stage BL.
08. Makes BIOS calls - Int 13 fn 8 --> "Get drive parameters" and - Int 13 fn 2 --> "Read sectors from drive" - which returns the disk geometry in 24-bit address format upto the
1024 cylinder limit.
Since you have enabled the LBA mode, 64-bit address format is used and
instead of the CHS way, BIOS reads the disk by numbering the sectors
from 1,2,3... etc
The requested info from this BIOS call is stored by the BIOS in the first
page of memory ( < 4k )
09. The first-stage loader then requests the BIOS for an Int 13 fn 2, gives it
the CHS # of the /boot/boot.map file
Now the BL speaks CHS and the BIOS speaks 24-bit addresses.
It is LBA which allows the BIOS to act as a speaker of both, CHS and
Linear Sector Addressing - using 64-bit addresses - Translator
10. BIOS loads this 2nd stage BL - from the CHS no supplied by the 1st stage
11. The 2nd-stage BL now loads the contents of the balance of the BS into the RAM
And what is that ?
/etc/lilo.conf
Not the file lilo.conf in dir /etc
but the contents of the BS - which is the same file - but in binary form
and was put there by the installer
12. The 2nd stage BL now examines this binary-format-BS which contains
"lilo.conf" and follows the instructions given there !!
It requests BIOS for an Int 13h and gives it the CHS # of the
/boot/message file which BIOS promptly fetches and the 2nd stage BL
executes - This is the splash screen
13. The 2nd stage BL then executes the instructions it got from the BS
after the 1st stage had loaded it, and executes those instructions
/etc/lilo.conf
==============
prompt <--------- Display labels
timeout=50 <--------- In decisecs
default=linux <--------- What to do after timeout
boot=/dev/hda <--------- Where to install the 1st stage BL
Here, in the BS of the MBR of Primary
Master HDD
map=/boot/map <--------- Location of map file which contains size and location of
ll=/boot/boot.b <--------- Boot sector image/file for MBR or
1st stage LILO to be installed in BS of the MBR
Message=/boot/message<-------- Splash Screen
lba32
image=/boot/vmlinuz-2.4.20-8 <------ Big Boss - The Linux kernel
label=linux <------ An unscary word for the kernel
initrd=/boot/initrd-2.4.20-8.img <--- Image of support modules
read-only
append="hdc=ide-scsi root=LABEL=/" <--- Parameters LILO will pass to
init before it starts
other=/dev/hda1 Another OS
optional
label=DOS
14. After timing out AND IF the default image is the Linux kernel, and IT IS
in the case above, the 2nd stage boot loader - /boot/boot.b -
loads the Linux kernel in RAM
15. Now what is a BootLoader ?
BootLoaders load "kernel images" into mem and hand control of the CPU
over to the newly loaded kernel [/boot/vmlinuz-2.4.20.8]
To make your new kernel work, you must tell the BL about the kernel
Nearly all BLs use and understand CHS numbers.
[BIOS can now understand CHS nos too, bcos of LBA]
16. Now the 2nd-stage wishes to load the kernel, as instructed by the
binary-format lilo.conf after timing out or whatever the user chooses
But there's a problem !!
The Linux kernel is on the HDD !!
In /boot to be precise !!
And the 2nd-stage LILO BL has no idea how to access the HDD
Why ?
The HDD drivers - /dev/hda... are in /dev on the HDD
and to access it the 2nd stage BL requires the file /dev/hda
which once again is itself on the HDD !!
Hen-and-Egg situation !!
17. The 2nd stage BL has no choice but to use the BIOS as its HDD device
driver to access the HDD at boot time.
After all that's where the kernel is [/boot/vmlinuz-2.4.20-8] !!
18. The 2nd stage BL once again requests BIOS - Int 13h fn 2 - and hands it
the CHS # of the /boot/map file, which BIOS loads
19. The 2nd stage loader now examines this /boot/map and extracts the
CHS # inside it - which was put there by the BL installer - anaconda -
and /sbin/lilo - and requests BIOS once more to load whatever is there
in that CHS # address
17. BIOS then loads the Linux kernel /boot/vmlinuz-2.4.20-8 into the RAM
and hands it to the 2nd stage BL
18. The 2nd stage BL uncomptars this file and fills the memory with kernel
mem structures which can be seen in the /proc virtual file system
The Engine Of The Car Is Ready And Running !!
The Linux OS is ready and running !! Kernel Land is ready !!
BUT WE FORGOT TO MAKE THE CAR PROPER ITSELF !! No Userland !!
How do we drive this car if there is no seat, steering wheel. Nothing.
Just an engine !!
=============================
Part II /sbin/init takes over
=============================
19. Now that the Linux Kernel is in the RAM, and is much more powerful
and immensely larger than the 2nd stage BL, it takes over total control
from it and makes yet another BIOS call Int 13h fn 2 for the
file /boot/initrd-2.4.20-8.img
20. It uncompresses it in RAM and creates a mini-FS as can be seen if
we look inside the image
# mount -o loop /boot/initrd-2.4.20-8.img /win
# cd /win
# ls
21. Note that the HDD driver is available now; Hence the kernel executes the
"linuxrc" script which mounts the "root" partition in R/O mode and
loads the /sbin/init* program into RAM
The Userland Part of Linux is now started by the /sbin/init daemon
22. /sbin/init* examines /etc/inittab
/etc/inittab
============
id:3:initdefault:
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit
l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
ls:S:wait:/etc/rc.d/rc S
~:S:respawn:/sbin/sulogin
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
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
1:2345:respawn:/sbin/mingetty --noclear tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6
11:2345:respawn:/sbin/mingetty tty11
# Run xdm in runlevel 5
x:5:respawn:/etc/X11/prefdm -nodaemon
=======================================================================
23. a. Executes /etc/rc.d/rc.sysinit in a subshell of inittab shell
rc.sysinit
==========
calls /etc/sysconfig/network in same env [shell]
sets the hostname and checks whether NW is yes or no
ie checks for existence for NW card
calls /etc/init.d/functions script in the same env [i.e rc.sysinit]
sets global umask and path and defines 17 shells fns
within the rc.sysinit shell env
# cat functions grep \(\)sortnl
/etc/init.d/functions
=====================
1 action() {
2 checkpid() {
3 confirm() {
4 daemon() {
5 echo_failure() {
6 echo_passed() {
7 echo_success() {
8 echo_warning() {
9 failure() {
10 killproc() {
11 passed() {
12 pidfileofproc() {
13 pidofproc() {
14 status() {
15 strstr() {
16 success() {
17 warning() {
24. Displays the "Welcome to Red Hat..." from /etc/redhat-release
25. Runs dmesg* which creates /var/log/dmesg and
display its contents on the screen
26. Mounts all local filesystems from /etc/fstab and updates /etc/mtab
Mount simply displays the contents of /etc/mtab
Now /etc/rc.d/rc.sysinit script ends !!
Summary: rc.sysinit : 1. sets the global umask, global PATH,
sets up the NW'ing subsystem
Basically starts the System Daemons
b. Back to inittab
27. rc is executed in a new subshell of /etc/inittab
starts and stops the Application NWing daemons
runs /etc/rc.d/rc.local which is a symlink in all RLs and is the
only script which is run regardless of the RL and is
S99local in all /etc/rc.d/rc?.d/...] and points to
/etc/rc.d/rc.local
goes back to inittab
Summary: rc : starts the 3rd party NW services [User NW services]
Basically starts the Application Daemons
i.e all the * in ntsysv
28. c. shutdown CAD magic keys are set - You can hack it if you wish
29. d. poweroff and poweron considerations [start upsd* daemon "ups" initscript
which reads /etc/sysconfig/ups which you will configure for your UPS model
30 e. 6 mingettys are spawned with dev drvs ; all enter sleep state
- EXCEPT one
31.f. Iff Runlevel 5, then script "prefdm" is executed..
we will do this in class of X
NOW INITTAB IS OVER
========
Part III
========
Note:
What is a getty? [RHL has agetty* [Alternate Linux getty]
mgetty* [Modem getty]
mingetty* [Minimal getty]
A getty is is a program that opens a tty port, prompts for a login name,
and runs the /bin/login command. It is normally invoked by init.
32 g. The first mingetty [awake one] loads dev drv /dev/tty1
* execs /etc/issue [Magic cookies Allowed: man uname / man mingetty]
33. * mingetty then executes the /bin/login process
and is then put to sleep state by init
34. * /bin/login displays login. You login!
35. * /bin/login execs /usr/bin/passwd which challenges for passwd from
user which then does authentication and authorization using PAM
36. * init then puts the login daemon into sleep state, wakes up
mingetty which now takes over
37. * mingetty checks for .hushlogin in $HOME/$USER
38. If $HOME/.hushlogin DOES NOT EXISTS
then it does the foll :
39. - execs lastlog* -u $USER using /var/log/lastlog
- execs /etc/motd
- checks users mail, if any, in /var/spool/mail/$USER
40. * init then wakes /bin/login process
41. * mingetty then goes into zombie state and is killed by init
42. * login then loads /bin/bash as a monitored child process
43. * /bin/bash takes over and login goes into sleep state
44. * Execs /etc/profile Sets system-wide ENV variables Global Profile
exec /etc/inputrc Sets keyb mappings [See stty -a]
Show Terminal characteristics
eg # stty intr ^g --> Keyboard mapping
# stty -echo --> Terminal Characteristics
eg /etc/inputrc See man bash - /bell-style
============
set bell-style [audible] [none] [visible]
set disable-completion [off] on
To do it per-user:
=================
setterm -blength 0 [in per user .bash_profile]
or
xset b off [in GUI]
[bash -r, --noediting as args in /etc/passwd
7th field]
45. exec /etc/termcap Sets the terminal capabilities
46. exec /etc/profile.d/*.sh [13 shell scripts are executed]
1. colorls.sh
2. glib2.sh
3. gnome-ssh-askpass.sh
4. krb5.sh
5. lam.sh
6. lang.sh
7. less.sh
8. mc.sh
9. pvm.sh
10. qt.sh
11. vim.sh
12. which-2.sh
13. xpvm.sh
47. i. * Execs /etc/bashrc - Sets system-wide [Global] aliases/shell functions
sets the users and root's final global umask
48. * execs user's personal .bash_profile
49. execs .bashrc Run after every command you execute
50. .bash_history
51. .bash_logout
52. Finally, at last, the comforting shell login prompt bash
inviting you type a cmd and explore the party [FS] !!!!
Subscribe to:
Post Comments (Atom)
2 comments:
Hi,
Where did you get the log information to outline the linux boot process?
Thanks,
Richard
Post a Comment