arch linux引导不启动_linux操作系统引导与启动——引导(2)

一、从上个月的话题过渡到当前话题

前两天我登上公众号时,发现有兄弟催更,好事儿73c2a3a2b750906c0b2876a3e909d1c3.png

其实上个月我连着发了两篇,两篇的.....51abc60fe1df0f30b9584f51e06302ec.png

写技术贴真的有点耗精力。

即使是有素材,然而编辑文字和图片、整理成稿也需半天的时间。

如果是将多个素材串联到一起,那就要两三天。

如果是从头写起,天哪.....

关于上个月写的vmcore分析系列两篇,本来手头还有多篇现成的。

若按照vmcore分析的思路写下去,接下来的一篇就是null pointer的分析了,案例如下图:

abffc11c48b7ce6283cb7a33677173b8.png

但是看了看先前保留的笔记,这个case但从执行逻辑上就分析了三层调用栈,而为了确定传参共看了五层调用栈,所以洋洋洒洒估计三篇帖子才能写完。

所以留到以后吧,否则在vmcore的大坑里又出不来了。——其实,现在这个浮夸的社会圈,还有多少人关心微观的技术细节?

贴出来上面的图,只是为了证明这些题目真的是现实的案例。

接着聊linux启动过程吧。

二、接着聊服务器启动过程

思考了一下,从bios/uefi到操作系统服务启动还是得分legacy模式和UEFI模式来说。上一篇我忽略了UEFI模式没说,然后发现后面的efishell就没法说了。

Legacy时代

如果将硬件自检当作bios启动的前期或准备,那么传统的legacy服务器启动其实是包括以下四部分:

cb614b30525ac6b0838079ed81cadf9b.png

说实话,我们能感受到bios和操作系统内核:

——因为毕竟服务器启动的时候,我们能看到bios执行的只言片语;而操作系统启动后,我们也能在boot分区里看到两大内核文件。

而对于中间的引导/grub部分,往往都忽视了——因为我们看不到。

上一篇我们聊过,在传统的legacy模式下,引导/grub 又分成了stage1,stage1.5,stage2三个阶段(我终于从笔记里找到了一副图):

cbcfe828244c795c3cb5ba495811513f.png

为什么引导要这么搞?

Stage1:

BIOS legacy模式有些地方真的很傻,真的。

BIOS可以知道磁盘的路径,但是BIOS不认识磁盘上的分区和文件系统,更不用说操作系统的内核文件了。所以Bios执行到最后,便闭着眼将磁盘的第一个扇区sector的头446字节拉到了实模式执行环境中,美其名曰:“从此将控制权交给了操作系统”。

而这446字节就是引导/grub部分的stage1,就是引导过程的火种。

Stage1.5:

从stage1的这446字节开始,所有的引导过程执行的很底层,很奴隶,很憋屈,真的。

在有限的执行空间内,以sector为单位,一个接一个的模块进行替代、腾挪,一点点的为后面稍复杂点的模块执行创造条件。整个过程让人看的精神扭曲,充分感受到了进化的漫长。

Stage1.5的作用,基本上是为了:能从无到有的看到磁盘上的/boot文件系统,从而可以读出/boot下的grub菜单文件以及操作系统内核文件。

Stage2:

文明时代的开始,引导过程终于拉起了grub启动菜单。

fbb83533a7ee2b093d194bfd91707570.png

我们终于看到了熟悉的grub菜单界面。

然后我们既可以安然等待相关的内核启动,也可以潇洒的按按tab键,修改内核启动命令行进行启动中断或者特殊参数设置。

——这时在外行眼里,大概是最装B的时刻。

然后,操作系统引导过程正式结束,从此进入内核启动阶段。

半年前吧,万里长征第一步,我尝试画了linux引导和内核启动的细节初稿。但是半年过去了,我一看到这两幅图就想吐,一直没有勇气进行勘误、整理(哭……):

2a5d5a6e34daf2720a6ce30a068dbf82.png

 这张还不算乱?呃,还有接着往后的第二张:

872702f888f87851f2cbb3388b071941.png

——虽然我曾犯贱抠过了磁盘MBR和GPT数据结构的每个字节,但是这个操作系统引导启动过程,我实在是不愿再整理了。除非哪一天,真的需要玩细节。

UEFI时代

其实我们可以把BIOS/UEFI也看成是一个操作系统。一个低级的、没有什么人机交互的操作系统(除了CMOS参数设置以外啊),一个面对一地鸡毛的硬件,默默进行硬件资源整理、编号的操作系统。

到了UEFI时代,BIOS/UEFI也叼了,至少在操作系统引导启动方面:

BIOS/UEFI从只认磁盘设备路径、但啥文件系统都不认的状态,也升级到可以认识磁盘上的vfat格式的EFI系统分区了。(当然伴随着UEFI,操作系统所在的硬盘分区模式从MBR模式进化到了GPT模式)。

于是引导模式从legacy的这样:

103953ab4bf6dbe3c6e614d4a4140836.png

变成了UEFI的这般模样:

da63b4ab8f15ae34d37fab27a8a48a4f.png

注意啊:

——UEFI已经可以认识磁盘上的EFI分区了。所以图中的磁盘EFI分区,画成了向左插入UEFI的样子。

——另外UEFI还自带了一个efi shell。但凡UEFI没有被阉割,我们就可以在操作系统引导的时候中断进入efishell。然后在一个类似于linux shell的界面下,去感受一步步手工引导操作系统的过程。

Efi shell的样子:

3e3ff496deffdec5d6a5ed29d796dd63.png

Efi shell中的三大类命令:设备信息,操作系统引导项以及相关配置,我看到的很多文档说的都不接地气,力争下个帖子将这个话题掀个底儿朝天。

下个帖子聊聊efi shell吧,先从map中的设备路径聊起:

ec493a35feebf6f8db6d1f32c90f93f7.png

——efishell中的maptable,划红线的设备路径,究竟意味着什么?

然后会聊聊启动项btcfg。

最后会聊到,如何在efi shell中测试pxe引导(从dhcp到tftp):

612ab6d9b30f29ec60dd1b6c6522172f.png

三、题外话

为什么我要聊两次操作系统的引导和内核启动?

那是因为:

聊透了操作系统的引导和内核启动,才能聊操作系统的安装。

    聊透了以上两点,才能聊pxe和无盘工作站。

        聊透了以上四点,我们才敢聊pxe安装诊断以及linux启动恢复。

否则,做相关的操作,都是比着葫芦画瓢。——万一别人的葫芦稍微畸形了一点,那就灾难了。

先说“聊透了操作系统的引导和内核启动,才能聊操作系统的安装。”

我们只有先理解了操作系统的引导和内核启动:

99daaca308e6922f5214aa5805506ad8.png

才能理解操作系统的安装过程(草):

fb7e352eebac5eceea7007a07a856723.png

然后再有其他pxe等等。

先做个引子,以后再聊。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值