linux系统启动流程-阿里云开发者社区

开发者社区> 开发与运维> 正文

linux系统启动流程

简介:

POST-->BIOS(Boot Sequence)-->MBR(Bootload,446)-->Kernel-->init


POST:加电自检,通电时cpu会自己找到rom里面的程序进行自检,检查完毕后把控制权转交给BIOS

BIOS:我们的操作系统可以装在各种各样的位置,BIOS里面有个boot Sequence,可以指定介质(u盘、硬盘等)的查找顺序,找到介质里面的MBR并把控制权交给它,(如果找不到介质里面的MBR,则查找下一个介质,如果介质里面的MBR损坏则提示错误信息并停留)

MBR:MBR里面分两部分446字节的Bootload和16字节的分区表,Bootload会根据分区表查找活动分区的Kernel并装载,然后传递控制权

Kernel:Kernel获取控制权后会去探测硬件并挂载等,为实现它的功能(文件系统、进程管理、网络管理、安全功能等)初始化环境,然后生成第一个用户进程init

init:用户空间的第一个进程,id号为1,所有进程的父进程


    我们知道init进程在/sbin,因此,我们必须先识别/sbin所在的分区,我们知道linux的系统分区有些可以单独分区,有些不能。和系统初始化相关的不能单独分区,比如/bin、/sbin,和初始化无关,提供第三方特性的可以单独分区,比如/home,/usr。 这两者都有个共同点,都必须从根开始识别,我们把/所在的文件系统叫做根文件系统。

    内核在设计上有两种设计风格:微内核和单内核。微内核把核心和外围功能分开,需要某些功能的时候再加载对应的子系统,因此有先天性优势,但是这种风格的内核设计逻辑很复杂,对冲了其优势。  单内核把功能和核心做在一起,因此逻辑实现上比较简单。我们知道根文件系统要想使用硬件必须有相对应硬件的驱动程序,但是硬件多种多样,所需的驱动也是各不相同,如果把这些驱动都做进内核,无疑会使内核变得十分的庞大,而我们的硬件设备往往是单一的,因此单内核设计风格上引用了微内核的设计理念,把所需要的驱动等有的做成核心,有的做成模块,内核编译时只选择地编译,这样内核也变得精简了起来。linux是单内核设计风格,系统加载的时候只加载核心,而模块则要到硬盘的 /lib/modules/“内核版本号命名的目录”/ 下去读取,这样核心只有一两兆左右,模块却可以很大。 但是这样也会导致一个问题: 当我们没有把模块所在磁盘的驱动编译进核心时候,我们就会陷入两难,我们要想访问磁盘则需要加载对应的模块,要想加载对应的模块,需要能先访问磁盘。

    为了解决这个问题,linux使用了一个类似中间人角色的文件,这个文件含有对应磁盘的驱动,那这个文件怎么知道需要哪些驱动呢?原因在于这个文件是系统安装的最后由系统安装程序生成的,安装程序能够识别对应的驱动,并根据规则判断系统内核需要动态生成。这个文件在redhat5上叫做ramdisk,在redhat6叫ramfs。


核心,动态加载 内核模块

内核:/lib/modules/“内核版本号命名的目录”/

内核设计风格:

    单内核:linux(LWP)

        核心:ko (Kernel object)    

    微内核:windows,Solaris(线程)

redhat5:ramdisk-->initrd

redhat6:ramfs-->initramfs

chroot:改变/文件系统,切换的路径里面需要包含二进制程序和所依赖的库文件

     chroot [OPTION] NEWROOT [COMMAND [ARG]...]

ldd /PATH/TO/BINARY_FILE  :判断一个二进制程序所需要的库


linux的运行级别:0-6

    0:halt

    1:single user mode

    2:multi user mode,no nfs

    3:multi user mode ,text

    4:reserved

    5:multi user mode,graphic mode

    6:reboot


使用initrd的系统启动过程如下:

post-->bios-->mbr-->kernel-->initrd-->init


MBR(bootloader):

    bootloader有各种各样工具,比较常见的有lilo和grub

        lilo:LInux LOader  不能识别1024柱面以后的数据,所以不支持大硬盘,在嵌入式中比较常用

        Grub:GRand Unified Bootloader

            Stage1:MBR

            Stage1.5:识别文件系统

            Stage2:/boot/grub/ 引导内核,并转交控制权


    grub工作过程分成两部分,stage1 在MBR中,作用在于查找并引导至stage2,这样使得MBR的bootload不再限制于446字节,当grub的stage1阶段无法识别stage所在磁盘的文件系统时候,就会衍生出stage1.5,stage1.5的作用就是加载stage2所在磁盘的文件系统驱动,使得grub具有读取数据的能力(这个也是为什么grub可以加载内核,内核却不可以加载根的原因,内核被加载到内存中的时候,内核如果本身没有识别根文件系统所在磁盘的驱动,那么它就无法加载文件系统,也就是需要initrd这个软件来过渡,,识别需要两个必要条件:1 磁盘的驱动, 2 文件系统的驱动 )


grub.conf 解释:

default=0   #多个title的默认选项,第一个为0

timeout=5   #用户选择的超时时间

splashimage=(hd0,0)/grub/splash.xpm.gz #设置背景图片

hiddenmenu #是否隐藏菜单,隐藏开机则需额外按键才能显示

title CentOS 6 (2.6.32-573.el6.x86_64)  #标题,可自定义

root (hd0,0)    #根文件系统所在位置,这里跟linux不一样,不管是ide口还是其他硬盘都识别为hd# 0代表第几个分区

kernel /vmlinuz-2.6.32-573.el6.x86_64 ro root=UUID=b670d3c5-487a-43be-9624-5ad90ffda293 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet   #内核所在位置及其参数,注意:如果这里的boot是单独分区,那么内核所在位置就是/vmlinuzXXX ,如果boot没有单独分区那么内核的位置就是 /PATH/TO/boot/vmlinzxxx

initrd /initramfs-2.6.32-573.el6.x86_64.img  #initrd的位置,同上

        

password --md5  xxxxxxxxxx  #选项的加密,启用后需要输入密码才能访问,密码可以由grub-md5-crypt命令生成,也可以不加--md5 明文存放,放在title前面表示编辑grub引导需要密码,放在title里面表示想要引导此内核需要密码。


查看运行级别:

runlevel

who -r


安装grub stage1的两种方法:

第一种:

#grub

grub> root (hd0,0)

grub>setup (hd0)

第二种:

grub-install --root-directory=/PATH/TO/boot's_father_dir


在grub命令行中引导系统:

grub> find (hd#,N)/        tab键可以查看该路径下的文件

grub>root (hd#,N)

grub> kernel  /PATH/TO/KERNEL_FILE

grub>initrd   /PATH/TO/INITRD_FILE

grub>boot


kernel初始化的过程:

1,设备探测

2,驱动初始化(可能会用到initrd)

3,以只读挂载根文件系统

4,装载第一个进程init(PID 1)


init进程的配置文件/etc/inittab

格式: id:runlevel:action:process

id:标识符

runlevel:在哪个运行等级下执行此行

action:在什么情况下运行此行

process:要运行的程序


ACTION:

    initdefault:设定默认运行级别

    sysinit:系统初始化

    wait:等待级别切换至次级别时运行

    respawn:一旦程序终止,会重新启动

    

/etc/inittab完成的任务:

  1. 设置系统运行级别

  2. 执行系统初始化脚本

  3. 执行对应级别的服务脚本

  4. 定义:ctrl-alt-del按键执行程序

  5. ups电源断电/中途来电执行的操作

  6. 启动虚拟终端

启动图形终端

 

/etc/inittab执行的系统开机启动sysV风格脚本特点:

  1. 都在/etc/init.d/目录下

  2. 脚本必须至少支持四种传递参数[start|stop|restar|status]

  3. 在各个级别的链接中,K开头的服务会stop,S开头的服务会start

  4. 要想自动在每个运行级别中用chkconfig自动创建链接,注释行必须含有chkconfig和description


sysV脚本中的chkconfig注释行格式:

#chkconfig: runlevel SS KK 

例子:chkconfig: 2345 08 92

    runlevel代表在哪些运行级别中启动脚本

    SS代表/etc/rc#.d/下 S 开头后面跟的序号,比如本例/etc/rc3.d/S08iptables,SS代表08

    KK则代表K后面的序号,一般SS+KK=99 左右,这是为了遵循先启动的后关闭原则(因为先启动的可能被后面的服务依赖)


chkconfig 命令:

       chkconfig --list [name]

       chkconfig --add name

       chkconfig --del name

       chkconfig [--level levels] name <on|off|reset|resetpriorities>

       chkconfig [--level levels] name

 name代表/etc/init.d/下的服务名字

 level表示在哪些级别下运行,可省略,默认2345


一个特殊的文件:/etc/rc.local 这个是系统启动最后执行的脚本,在各个级别中的链接都是S99,所以一些想要开机执行的命令可以写入到这里


守护进程类型:

    独立守护进程:进程的启动关闭都由进程自己管理,类似于以上服务脚本

    瞬时守护进程:一个进程管理多个服务,服务启动与否取决于管理进程,适用于平时很少访问量的服务,这个管理进程在centos中就是xinetd,扮演类似代理人角色


一个sysV风格脚本案例:

#!/bin/bash

#

#chkconfig: 2345 22 77

#description: edit by linzb.

#

LOCK_FILE=/var/lock/subsys/myservice

Usage(){

echo "`basename $0 ` [start|stop|status|restart]"

}

start(){

touch $LOCK_FILE

echo "starting.."

}

stop(){

rm -f  $LOCK_FILE $> /dev/null

echo "stoping.."

}

status(){

if [ -f $LOCK_FILE ];then

echo "running.."

else

echo "stopped"

fi

}

case $1 in

start)

start;;

stop)

stop;;

restart)

stop

start;;

status)

status;;

*)

Usage;;

esac



注:/var/lock/subsys/这个目录下经常放服务的锁文件,很多服务根据这里面的文件判断服务是否启动

    











本文转自biao007h51CTO博客,原文链接:http://blog.51cto.com/linzb/1790459 ,如需转载请自行联系原作者



版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章