关于linux的启动流程的笔记
一、从哪里到哪里
本文旨在描述linux中内核如何调用启动,然后如何从img的文件系统切换到硬盘的过程。
描述起于:linux-2.6.11/init/main.c中函数 static int init(void * unused)
描述止于:/etc/rc.d/rc.sysinit文件的被调用
二、描写流程
在linux代码linux-2.6.11/init/main.c中init这个函数被调用时,初始启动的文件
系统镜像:/boot/initrd-2.6.11.12.img(以2.6.11.12内核为例)已被grub加载到
内存中,并已挂载到根目录上("/")。
1、我们先来看看initrd-2.6.11.12.img到底是个什么东西:
[root@wj-server1 tmp]# cd /tmp
[root@wj-server1 tmp]# cp /boot/initrd-2.6.11.12.img /tmp/initrd-2.6.11.12.gz
[root@wj-server1 tmp]# gunzip initrd-2.6.11.12.gz
解压缩后的文件为:
[root@wj-server1 tmp]# ls -l initrd-2.6.11.12
-rw-r--r-- 1 root root 846848 7月 31 17:01 initrd-2.6.11.12
是一个CPIO格式的文件,该文件格式是种文件镜像让我们将它解开到一个目录中看看
其中的具体内容:
[root@wj-server1 tmp]# mkdir initrd
[root@wj-server1 tmp]# cd initrd
[root@wj-server1 initrd]# cpio -i < ../initrd-2.6.11.12
1654 blocks
[root@wj-server1 initrd]# ls
bin bootsplash dev etc init lib loopfs proc sbin sys sysroot
[root@wj-server1 initrd]# find .
.
./lib
./bin
./bin/nash
./bin/insmod
./bin/modprobe
./bin/hotplug
./etc
./dev
./dev/console
./dev/null
./dev/ram
./dev/systty
./dev/tty1
./dev/tty2
./dev/tty3
./dev/tty4
./loopfs
./proc
./sys
./sysroot
./sbin
./init
./bootsplash
可见该镜像文件目录中包括:
/bin 目录下的四个用于启动和切换到硬盘上的程序:
nash(用于处理根目录下的/init脚本)、insmod和modprobe来加载内核驱动、hotplug用
于外设的拔插处理。
/dev 目录下的八个设备文件
/init 是个nash的启动脚本文件
/bootsplash 是内核打了bootsplash补丁后,会在对该文件进行读取操作,然后将该文件
中包含的图片文件在启动时显示。
[root@wj-server1 initrd]# dmesg | grep -i bootsplash
bootsplash 3.1.6-2004/03/31: looking for picture... silentjpeg size 36270 bytes,
...found (1024x768, 19600 bytes, v3).
内核的这个装载信息就是在处理该文件。(具体的bootsplash的使用和创建这里不细说)。
附:CPIO文件的打包
[root@wj-server1 initrd]# cd /tmp/initrd
[root@wj-server1 initrd]# rm ../initrd-2.6.11.12
[root@wj-server1 initrd]# find . | cpio -c -o > ../initrd-2.6.11.12
1654 blocks
[root@wj-server1 initrd]# gzip ../initrd-2.6.11.12
[root@wj-server1 initrd]# mv ../initrd-2.6.11.12.gz ../initrd-2.6.11.12.img
2、回到内核init函数中,看看如何调用/boot/initrd-2.6.11.12.img中/init脚本的
....
// 这里判断在grub装载的/boot/initrd-2.6.11.12.img中是否有"/init"这个文件?
if (sys_access((const char __user *) "/init", 0) == 0)
execute_command = "/init"
else
....
// 如果有"/init"这个文件就先运行它。
if (execute_command)
run_init_process(execute_command);
run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");
panic("No init found. Try passing init= option to kernel");
由代码我们看到kernel会先判断并运行/boot/initrd-2.6.11.12.img中的/init文件,我们
来看看该/boot/initrd-2.6.11.12.img/init文件的内容,我们上面已将该文件展开到目录
/tmp/initrd中:
[root@wj-server1 initrd]# cat ./init
#!/bin/nash # 该文件是个nash的脚本文件
# 挂接proc文件系统
mount -t proc /proc /proc
# 不输出nash调试信息,由/proc/cmdline决定,cat /proc/cmdline我的启动参数
# 输出ro root=/dev/hda3 vga=791 splash=silent,如果该命令行中带了quiet参
# 数,则不输出nash提示信息。
setquiet
# 提示信息(这里提示因该放到上面去,mkinitrd-4.2.17-2mgc.rpm包中原来如是,
# 笔误?为什么这里牵涉到mkinitrd这个包类?因为:/boot/initrd-2.6.11.12.img
# 文件由下面命令生成:mkinitrd /boot/initrd-2.6.11.12.img 2.6.11.12)
echo Mounted /proc filesystem
# 挂接sys文件系统
echo Mounting sysfs
mount -t sysfs /sys /sys
# 创建/dev临时目录
echo Creating /dev
mount -o mode=0755 -t tmpfs /dev /dev
# 创建设备文件(这些设备文件在切换到硬盘后,由/etc/rc.sysinit中start_udev
# 重新创建)
mknod /dev/console c 5 1
mknod /dev/null c 1 3
mknod /dev/zero c 1 5
# 新建伪终端目录
mkdir /dev/pts
# 新建共享内存目录
mkdir /dev/shm
# 这里是调用的nash中的makedevs指令装载硬盘等块设备,不装载其他设备只装载
# 硬盘等块设备
echo Starting udev
# 告诉内核当发现新拔插设备时用"/sbin/hotplug"程序来处理
echo -n "/sbin/hotplug" > /proc/sys/kernel/hotplug
makedevs
makedevs # 这里多搞一次没必要
echo Creating root device
# 由grub启动命令行root=/dev/hda3来联接设备/dev/root到root变量所指定的启动
# 设备,见下面我的grub启动参数:
# kernel /boot/vmlinuz-2.6.11.12 ro root=/dev/hda3 vga=791 splash=silent
mkrootdev /dev/root
# 挂接/dev/root目录
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
echo Switching to new root
# 切换根目录到设备/dev/root目录,运行完该命令根目录"/"->"/dev/hda3"
switchroot --movedev /sysroot
由上面的注释我们大概能够明白./init脚本的基本运行流程:
a、装载基本的内核系统文件和设备文件
b、根据grub的启动命令行参数,判断root根文件设备,参看/boot/grub/grub.conf文件中制定
的参数,该参数在内核启动后可有cat /proc/cmdline显示出来,nash和其他的一些程序也是通
过读该系统文件来去内核启动参数的。
c、在将从grub启动参数中获得根设备并将其与/dev/root设备联接以后,通过nash的switchroot
指令将/dev/root设备挂接到根目录上("/")
看看这样操作后,留下的痕迹:
[root@wj-server1 initrd]# ls -l /dev/root
lrwxrwxrwx 1 root root 9 7月 31 12:06 /dev/root -> /dev/hda3
[root@wj-server1 initrd]# mount
/dev/hda3 on / type ext3 (rw)
到此为止,已将硬盘设备装载到根目录下了,从而取代了原来有initrd.img文件的根位置。
3、再回头看看内核中main.c中init函数,看看如何调用/sbin/init处理/etc/inittab文件
....
// 如果有"/init"这个文件就先运行它。
if (execute_command)
run_init_process(execute_command);
run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");
panic("No init found. Try passing init= option to kernel");
我们已经运行完run_init_process(execute_command);这里了,然后继续运行:
run_init_process("/sbin/init");
run_init_process("/etc/init");
run_init_process("/bin/init");
run_init_process("/bin/sh");
/sbin/init这个文件在SysVinit-2.85-34mgc.rpm这个包中,该程序的主要处理代码在文件:
sysvinit-2.85/src/init.c中,该文件主要查找和处理/etc/inittab文件,按照该文件的内容
依次做处理。
[root@wj-server1 initrd]# 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, <miquels@drinkel.nl.mugnet.org>
# 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)
#
id:5:initdefault: # /sbin/init 根据这里判断启动的级别
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit # /sbin/init 会最先运行这个系统配置文件
l0:0:wait:/etc/rc.d/rc 0 # /sbin/init 根据上面取得的级别运行相应
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
# 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 powerd 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
1:2345:respawn:/sbin/mingetty tty1 # 建立6个登陆控制终端可以通过CTRL-ALT-F?
2:2345:respawn:/sbin/mingetty tty2 # 切换,'?'表示第几个登陆控制台,比如第1
3:2345:respawn:/sbin/mingetty tty3 # 个为F1,第2个为F2依次类推。F7为X11控制
4:2345:respawn:/sbin/mingetty tty4 # 台,后面就没有了,所以在X下可以很灵活
5:2345:respawn:/sbin/mingetty tty5 # 的切换到控制台下面操作。
6:2345:respawn:/sbin/mingetty tty6
# Run xdm in runlevel 5
x:5
#!/bin/nash
echo "Loading scsi_mod.o module"
insmod /lib/scsi_mod.o
echo "Loading sd_mod.o module"
insmod /lib/sd_mod.o
echo "Loading libata.o module"
insmod /lib/libata.o
echo "Loading ata_piix.o module"
insmod /lib/ata_piix.o
echo "Loading jbd.o module"
insmod /lib/jbd.o
echo "Loading ext3.o module"
insmod /lib/ext3.o
echo Mounting /proc filesystem
mount -t proc /proc /proc
echo Creating block devices
mkdevices /dev
echo Creating root device
mkrootdev /dev/root
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
umount /initrd/proc
前面是加载驱动部分,而后面是什么用处,就没有深究了。而我自己用的虚拟机里通常会把驱动和文件系统支持编译到内核,也压根用不着initrd.img,所以把这个宝矿放了过去。今天几个学生在Redhat 9的基础上升级内核到2.6.19,并且是驱动、文件系统用模块方式支持,终于出了问题。该来的还是要来的,应了那句话“出来混,迟早都是要还的”。学生们把前面的硬盘驱动、文件系统驱动都替换成2.6的模块,后半部分在我的误导下删除(当然没有删除的也多半没有成功),结果死活不能进入系统,报无法挂载根文件系统的kernel panic错误。查了半天,发现所有的驱动都加载正常,即便是在linuxrc当中加入bash获得一个shell,检查设备和文件系统的状况也都是正常,可就是提示找不到根文件系统。
开始引起我注意的是,通常在硬盘驱动和文件系统支持都完备的情况下它并没有提示说VFS的root=xxxx错误,而直接提示的“VFS: Unable to mount root fs on (0, 0)”。这意味着它并未识别在grub.conf当中传递给kernel的root=/dev/xxx参数,因为Linux的设备主设备号是不会为0的。我曾怀疑root=参数没有被接受,但却注意到“Please append a correct "root=" boot option”的提示。
为了找出问题,我在linuxrc中用bash取得了一个shell,然后挂载proc文件系统后检查/proc/sys/kernel/real_root_dev,发现其值为0。这说明kernel得到的真实root文件系统的设备号不正确(当然有例外,注意后面的解释)。我试着把正确的设备值(例如/dev/sda2用0x802)写入,退出bash之后启动果然正常了。这说明kernel解析参数root=/dev/xxx出现了错误。
经过核对内核代码,发现kernel确实从root=这个参数传递中获得真实的根文件系统的位置,但是这些/dev/xxx会被转换成内核可识别的设备表示形式。转换的过程中内核会试图检查传递进来的/dev/xxx设备是否存在,而这一步是kernel初始化过程中完成的。当我们把硬盘驱动编译为模块时,kernel初始化过程中硬盘尚不能被识别(要等到kernel初始化完,使用initrd.img才能加载硬盘驱动),于是真实根文件系统的设备号就不能被正确转换,使得其保留为初始值0。
那对于使用硬盘驱动的情况下如何解决这个问题呢?那就是initrd.img后半部分的工作。在加载完硬盘驱动后,脚本会用mkrootdev生成设备/dev/root,通过man nash你会发现这个命令的作用是根据内核传递参数当中的root=来创建对应该设备的节点,节点名就是/dev/root。之后它会把这个设备挂载到/sysroot这个位置,然后用pivot_root这个根交换的命令把真正运行的根文件系统切换到/sysroot之下,而运行linuxrc的initrd的文件系统将被挂载到真正的根系统下的initrd目录。至于“echo 0x0100 > /proc/sys/kernel/real-root-dev”这个命令,看起来是告诉内核真正的文件系统是/dev/ram0,其实是利用内核判断使用/dev/ram0为根文件系统时不再mount其他设备作为根文件系统的分支,作了一个小小的技巧骗过内核。
整个脚本的关键在于mkrootdev这个命令。它不仅能够根据root=/dev/xxx来生成对应的设备节点,还能够在碰到root=LABEL=/的情况下探测所有的硬盘分区,以便找到对应着卷标为/的分区。这也解开了我一直没弄清楚的为什么root=LABEL=xxx的参数有些环境可以用而有些却不行的谜团。这个LABEL=/的解析根本不是内核完成的,而是initrd.img当中linuxrc脚本的mkrootdev命令来完成的。脚本的第二个关键在于它负责完成了本是由内核做的挂载真实根文件系统的动作,并对当前根(即initrd使用的内存文件系统)和真实根文件系统进行根切换,又利用欺骗让内核误认为当前使用/dev/ram0作为根文件系统可以不再挂载真实的根文件系统,可谓用心良苦啊 ^_^
当然,如果完全不用initrd.img的机制,你会发现/proc/sys/kernel/real_root_dev的值也是0。这并不是内核也弄错了,而是只有在使用initrd.img机制时,real_root_dev才反映了内核中记录的真实根文件系统的值,虽然它不一定准确。
最后,总结一下:
1、当硬盘驱动以模块形式提供时root=xxx传递给内核的参数可能不会直接起作用,内核在检查这个参数时可能会发现这个设备(因为没有加载驱动而)不存在,因此导致内核没有接受root=xxx的参数。
2、在这种情况下,initrd.img机制的作用不单单是加载驱动这么简单,还肩负着把正确的真实根的设备位置告知内核的艰巨任务。不过实现的方法有两种:
2.1 把正确的根设备号写入/proc/sys/kernel/real_root_dev,或者
2.2 自己挂载真正的根设备,并进行根交换把根系统切换到真实的根系统上,还要阻止内核去挂载它认为的真实根系统
对于2.2,挂载真正的根系统用nash解释器的内置命令mkrootdev完成,它可以根据传递给kernel的参数(估计读了/proc/cmdline)获得/dev/xxx的字符串,或者得到LABEL=xxx的字符串后查询各个分区的卷标来得到对应的真实根设备号。
3、如果没有使用initrd.img的机制,/proc/sys/kernel/real_root_dev的值没有任何处理,因为它只有在调用initrd.img的时候才会被同步于内核中的操作对象。
另外,redhat 9所带的nash解释器(版本3.4.42)在处理mkrootdev的流程上是有bug的。如果传给kernel的参数使用root=/dev/xxx的形式,那么nash会从/proc/sys/kernel/real_root_dev里获取用户想使用的真实根文件系统位置,显然这在我们上面的分析当中是0,也就是错误的;而如果参数传递是root=LABEL=/的形式,那么nash的处理走的另外一个分支,它会通过解析所有分区的卷标来查找所要的真实根文件系统,并不再查询/proc/sys/kernel/real_root_dev,这倒让我们可以得到正确的结果。bug呀bug。
不过FC6所带的nash 5.1.19已经完全不是这个流程了,应当不存在这样的bug。
本人,听网上视频的简单笔记:
Linux 启动详解
1. BIOS 自检,根据BIOS的设置顺序,如以什么方式硬盘引导,软驱引导看系统是以什么方式引导,内存地
址是从oxfff0开始
对硬件设备进行初妈始化。
如果是硬盘引导,MBR(512字节的一扇区),是磁盘的在0柱面的第一个扇区。
2.启动grub, 或lilo,都属于引导加载程序,都是在linux下的。
主要区别:
lilo,没有交互命令界面,grub有。
lilo,不支持网络引导,grub支持。
加密grub:
1)用加密工具:
/sbin/grub-md5-crypt 用来给grub加密
2)修改/etc/grub.conf 文件
title前加入一行 password: --md5 +已经MD5的字符串
3.加载内核,linux内核影像会被加载到内存
加载特定的内核,可以用kernel / +tab键
kernel /initrd/initrd+tab键自动补齐
4.执行init 进程,是所有进程的发起者与控制者,pid号为1,第一个运行的进程。
作用:
1). 是所有进程父进程
2). 进入运行某个特定级别的进程程序,对某个进程级别进行管理。
---- ps -ef 列出所有在执行的进程
PPID 指进程的父进程
5. 通过inittab文件进行系统的初始化
1)id:3:initdefault:
运行级别:0:关闭;
1:单用户模式;
2:多用户模式,但不允许使用网络
3:多用户模式,允许使用网络
4:用户可以自定义级别
5:图形界面,允许使用网络
6:重新启动
2)si:sysinit:/etc/rc.d/rc.sysinit 作用很多,如下一博客 /etc/rc.d/rc.sysinit的作用
cd /etc/rc.d/rc3.d
首先结束k开头的K(ill),然后开始s(tart)开头的,并是按s后接的数字大小来决定哪个先开启
3) 执行/etc/rc.d/rc.local文件
4)执行login程序
联系客服
微信登录中...
请勿关闭此页面