电脑启动时BIOS车启不了,自检提示需要初始化和硬件初始化是一回事吗?如何了解

 上传我的文档
 上传文档
 下载
 收藏
粉丝量:114
该文档贡献者很忙,什么也没留下。
 下载此文档
电脑开机自检顺序
下载积分:500
内容提示:电脑开机自检顺序
文档格式:PDF|
浏览次数:850|
上传日期: 03:21:22|
文档星级:
全文阅读已结束,如果下载本文需要使用
 500 积分
下载此文档
该用户还上传了这些文档
电脑开机自检顺序
关注微信公众号UEFI和BIOS启动模式对比
传统BIOS开机流程
从你按下主机机壳上的电源键,到进入作业系统的期间,储存於主机板上那颗EEPROM(电气可抹除暨可程式化唯读记忆体)裡的BIOS便会开始执行以下的工作:
1. 初始化:
当电脑打开,CPU会自行重置為初始状态,準备运作。BIOS boot block(基本输出输入系统开机区块)初始化阶段啟动,因為此时系统记忆体中是空的,没有内容可以执行,所以厂商让CPU去寻找系统BIOS ROM中的reset vector(重置向量):用一个固定的位置来啟动所谓的BIOS boot program开机程式。
一般来说程式会在记忆体的FFFF0h位址,也就是在UMA(上层记忆区域)靠结尾的地方。為避免ROM大小改变造成相容性的问题,所以一般会选择放这裡。它的内容只有一个jump指令,进一步跳到真正的BIOS啟动程序。当然了,各家IBV (independent BIOS vender;独立BIOS供应商)可以把程式放在不同的位置,只要透过jump来指定就可以了。
在这段期间,系统的CPU、晶片组、Super I/O和USB只有部分初始化,仅获取足够资料来应付万一BIOS开机失败,可以利用软碟(由Super I/O控管)甚至是光碟(由晶片组的IDE/SATA)等储存媒体来救援BIOS的boot block。
2. POST(Power On Self Test;开机自我检测):
然后BIOS开始施行Power-On Self Test(POST;开机自我检测),在过程中检查电脑各项组件及其设定,像是:中央处理器、主记忆体、键盘、滑鼠等等状态。接著便寻找被内建在BIOS内部的显示卡程序并执行。
它通常被放在记忆体C0000h的位置,作用是显示卡的初始化,而大部分的显示卡都会在显示器上显示其相关讯息。这就是為何各位在开机的时候,首先会在显示器的画面左上角出现有关显示卡讯息的原因。
再下来就是让BIOS寻找其他装置的ROM(唯读记忆体),看看这些设备中哪些还有个别的BIOS。如果这时有找到任何其它装置的BIOS,它们也会被执行。
下一步BIOS会显示啟动画面,并开始更深入的检测,包含我们平常可以在萤幕上看到的记忆体容量检测。如果这时候遇到任何错误,就会在画面上显示错误讯息。
3. 记录电脑系统的设定值:
到这裡还没有结束,再来BIOS会根据自己的「系统资源表」,来对系统进行进一步的确认,看看你的电脑究竟安装了那些系统资源或设备。有些电脑会逐步显示这些被侦测到的设备。例如BIOS支援随插即用,那它将会侦测和配置随插即用装置,并显示由BIOS侦测到的随插即用设备。
在这些检测结束后,BIOS会打出一个侦测总结表於画面上。而这个总结表在部分IBV的设定中是可以让使用者开啟或关闭的。当然也有些IBV為加速开机把这一步直接隐藏省略。
Tips:BIOS boot block
在快闪唯读记忆体内,通常会分成两个区块,一个区块存放一般的BIOS程式码,即所谓的code block(程式码区块);另一个区块则是存放用来开机(或急救)的程式码,就是所谓的boot block(开机区块)。当电源打开时,主机板会先从boot block执行,它会立即检查code block 的程式码是否正确,如果正确,就会转到code block 继续执行下去。而所谓的BIOS recovery(BIOS回复)就是利用boot block回写动作来进行BIOS更新失败时的救援。
4. 提供常驻程式:
提供作业系统或应用程式呼叫的中断向量,如INT 10h(VGA图形及文字输出中断)等。
5. 载入作业系统:
到这裡是系统检测的部分,接下来BIOS便开始寻找开机装置,使用者可以透过在BIOS的设定来决定搜寻顺序,目前常见的开机设备至少包含FDD、HDD以及光碟机和USB开机装置等多项。
找到开机装置后,BIOS将会搜寻开机讯息以进行作业系统的开机过程。如果是找到了一个灌好OS的硬碟,它将会寻找位在硬碟第0面,第0轨,第1磁区裡的Master Boot Record(主要开机磁区)。如果它找到的是FDD,也会读取软碟的第1磁区。再把读取到的资料放在记忆体7C00h的位置,跳到那裡并且执行它。自此才开始进入OS啟动阶段。
UEFI BIOS系统的开机流程
同样是进行电脑系统的开机,由於UEFI BIOS是遵循UEFI论坛的规范定义下开发的,所以UEFI的开机流程会像下图一般:
1. SEC阶段:
SEC(安全性)阶段其主要的特色為「cache as RAM」,即处理器的快取当成记忆体。由於C语言需要使用堆叠,在这个阶段的系统记忆体尚未被初始化,在没有记忆体可用的情况下,便把处理器的快取当成记忆体来使用,在主记忆体被初始化之前来进行预先验证CPU/晶片组及主机板。
因為这时侯没有快取,会导致处理器的效能变得较差,所以在记忆体初始化完毕之前,SEC和PEI阶段的程式码越简短,越能减少这个副作用。
2. PEI阶段:
和传统BIOS的初始化阶段类似,PEI(EFI前初始化)阶段是用以唤醒CPU及记忆体初始化。这时候只起始了一小部分的记忆体。同时,晶片组和主机板也开始初始化。接下来的服务程式会确定CPU晶片组被正确的初始化,在此时,EFI驱动程式派送器将载入EFI驱动程式记忆体,进入了起始所有记忆体的DXE阶段(驱动程式执行环境)。
3. DXE阶段:
DXE的主要功能在於沟通EFI驱动程式及硬体。也就是说此阶段所有的记忆体、CPU(在此是指实体两个或以上的非核心数目,也就是双CPU插槽处理器甚至是四CPU插槽处理器)、PCI、USB、SATA和Shell都会被初始化。
4. BDS阶段:
在BDS(开机设备选择)这个阶段,使用者就可以自开机管理者程式页面,选择要从哪个侦测到的开机设备来啟动。
5. TSL阶段:
然后进入TSL(短暂系统载入)阶段,由作业系统接手开机。除此之外,也可以在BDS阶段选择UEFI Shell,让系统进入简单的命令列,进行基本诊断和维护。
传统BIOS哪裡不好?
在继续探讨何谓UEFI BIOS之前,先来看看传统BIOS有哪些问题,让Intel决心带头推出UEFI BIOS。
1. 过时的16位元模式
在x86系列CPU进入32位元的时代,為了相容性考量,当时最新的80386 CPU保留了16位元的执行方式,即真实模式(real mode)。在后来多次的CPU改朝换代中都保留了这种执行方式,甚至在含有EM64T的Xeon系列CPU中,供电到CPU啟动时仍然会切换到16位元的真实模式下执行。
也就是说,虽然各大BIOS厂商為了配合潮流演进,将许多新功能新元素添加到產品中,但BIOS在本质上没有任何改变。迫使Intel在开发更新的CPU时,都必须加进会使效能大大降低的相容模式。
2. 只有1MB定址空间
各位读者如果有注意传统BIOS开机,在POST完毕后萤幕上打出的系统摘要表,会发现记忆体栏位标示著「Base Memory=640KB」。加上前一篇提到的384KB UMA(这裡的记忆体不会列入Base Memory),就是所谓1MB可定址记忆体空间。
会造成这项限制,主要还是真实模式的副作用。16位元的CPU,其定址能力為20条定址线所能处理的2^20位元组(Bytes),也就是1024千位元组(KB)。换句话说,在进入OS之前的开机阶段,即使安装了高达4GB的记忆体,绝大部分都无法使用。
3. 组合语言难维护
假设某天你买了一张高阶工作站主机板,再装上一张SCSI或SAS的磁碟阵列卡,竟然发现安装后你的主机板开机开不下去,然后显示「Not enough space to copy PCI option ROM」或「Option ROM memory space exhausted」警告字串。然后本来你那雀跃快乐的心情消失了,取而代之的是「归LP火」熊熊燃烧著。
当你打电话给阵列卡商,电话那头的死公务员声音说著:「你要不要问问主机板厂有没有新的BIOS?」。 好不容易找上主机板厂商客服问:「你们有没有办法解决?」然后,你和主机板BIOS工程师之间的攻防就此展开。
对板卡厂的BIOS工程师而言,除非刚好有下单下很大的客户遇到类似相关问题,否则很有可能就是不了了之。你只好趁购买七天内退掉那张阵列卡,不然就是再找一张可以正常搭配的主机板。
由於传统BIOS是用组合语言编写的,而软体界早就已经是C/C++高阶语言甚至是.NET满天飞,為了相对难找的人才(组合语言高手相对少,要BIOS真正写得好的更是少数)来减缓新產品上市的速度,不管是消费者或厂商都无法接受。
此时UEFI BIOS标準化和模组化的特徵,便可加速產品推出和减少debug的时间。另外C语言写的UEFI BIOS体积也会变大,连带使储存BIOS的EEPROM需要扩增。
别忘了,这也是Intel的势力范围,如果EFI BIOS推广成功,板卡厂就得多採购一颗晶片。
▲ 由於传统BIOS的先天侷限,有时候磁碟阵列卡就是装不上去。
4. 十年不变的程式码
上述三大问题是以开发厂商的角度来观察。其他隐而不现的部分,则包含了功能的侷限性和对使用者不够友善的操作介面。对照现今的视窗介面作业系统,传统BIOS以文字介面為主且充满著火星文,加上除了单纯的开机,作為仲介硬体初始化和作业系统的功能外实在阳春的可怜。
在开发Itanium CPU之际,业界大魔王Intel实在不想再受制於这些顾虑。试想,既然这是一个新生的CPU架构,那系统韧体和作业系统之间的介面就顺便一起重新定义。
并且这一次,Intel為了让以后各种新的规格和技术可以快速导入,严格定义这个传统BIOS接班人必须具有扩展弹性,而且採取标準化的韧体介面规范,以避免发生传统BIOS的IBV程式码更新太被动的问题。
笔者不是开玩笑,业界之前盛传一句话,如果Award BIOS当时(Intel Pentium处理器时代)没有华硕,那肯定没有后来功能齐全的BIOS程式编码。传统BIOS静态连结,缺乏远见且叠床架屋,而几乎全基於经验和约定的见招拆招。所以才有2000年开发出来所谓的EFI(Extensible Firmware Interface;可扩展韧体介面)技术作為工业标準规格,定义了一个驱动介面,用以沟通硬体/韧体和作业系统。
UEFI的版本发展
最初制定的EFI版本2000年12月的1.02版。在2002年的12月又释出了加入EFI驱动程式模型的1.10版。於2005年,Intel将此规格提供给负责UEFI开发和推广的UEFI论坛。為了反映这点,EFI也被更名為UEFI。在大部分的文件资料中,EFI和UEFI讲的是一样的东西。
UEFI论坛在2007年1月释出2.1版的规范。目前最新公开的版本就是2009年5月发佈的2.3版。概括而论,凡依照UEFI论坛规范,使用C语言写作的BIOS即為UEFI BIOS。
UEFI论坛成员类别
IBV(独立BIOS 厂商) AMI、Insyde、Phoenix
IHV(独立硬体厂商) AMD、Apple、Dell、HP、
IBM、Intel、联想
ISV(独立软体厂商) 微软
UEFI BIOS哪裡好?
UEFI是藉由UEFI论坛制定的严谨规范来达成标準化,并用模组化之C语言方式的参数堆叠传递,藉由动态连结形式所建构出来的系统,相较於使用组合语言的传统BIOS更易於实作,在容错和错误更正的表现上更加优良,更好开发。UEFI是以32或64位元CPU保护模式执行(也称為Flat Mode),突破传统16位元代码的定址能力,可达到CPU的最大定址空间。
1. 定址空间更弹性
UEFI BIOS利用载入EFI driver的形式,来进行硬体的辨识/控制及系统资源掌控。
传统BIOS是以真实模式中断向量的方式增加硬体功能。它要将一段类似於驱动程式的16位元代码,放置在记忆体0x000CDFFFF之间。这段记忆体空间有限(128KB),因此,当必须放置的option ROM超过128KB时,传统BIOS便无能為力。
很多时候传统BIOS的工程师為了解决这类问题,像刚刚提到的介面卡BIOS容量过大,便要想办法利用可能的排列组合硬挤出空间来放驱动代码。而重组过程有时不小心造成一些副作用,例如才刚解决的bug,重组后又再发生!也就是说,UEFI BIOS可以更有系统的分配储存空间,避免使用强制定址。
2. 什麼系统都能用
另外,传统BIOS的硬体服务程式都是以16位元代码的形式存在,在增强模式下执行的作业系统想存取这些服务会有困难。因此BIOS提供的服务在现实中只能提供给MS-DOS之类的系统用。
相对的,UEFI系统下的驱动并不是可以直接在CPU执行的代码,而是用EBC(EFI Byte Code)这种专用於EFI driver的虚拟机器指令,该指令必须在UEFI的DXE阶段被解压缩后翻译执行。
如此便有更佳的向下相容性,因為EFI driver是弹性的驱动程式模组架构,可不断的扩充驱动程式及介面,不用重新编写,所以就无需考虑因系统升级所衍生的相容性因素。
3. 开发维护更容易
加上EFI driver开发简单,所有的PC零组件厂商都可以参与,就像现代作业系统的开发模式,这样的模式曾使Windows系统短短几年就变得无比强大。有了EFI driver,也可以让显示卡在开机阶段就载入某种程度的功能,进而可以把传统文字介面為主的BIOS转成图形介面。
4. 精简系统用途大
最后还有EFI Shell,这是个精简的作业系统,可以让使用者进行BIOS的更新、系统诊断、安装特定软体。有了UEFI BIOS甚至可以播放CD和DVD而不需完全载入OS,EFI driver可以被载入或卸载,连TCP/IP核心程式都可以使用。基於EFI的driver model可使UEFI系统接触到所有的硬体功能,在进入作业系统之前瀏览网站不再是天方夜谭,甚至实作起来也非常简单。总之,对使用者而言,多了一个方便的环境以及华丽的图形介面,是最明显的好处。
传统BIOS vs. UEFI BIOS重点差异
BIOS种类 传统BIOS UEFI BIOS
程式语言 组合语言 C语言
资源控制 中断向量
写死的记忆体存取
写死的输出/输入存取 驱动程式/协定
处理器运行环境 X86 16位元 CPU保护模式
扩充方式 接合中断向量 载入驱动程式
第三方IHV和ISV支援性 较差 较佳且可以支援多平台
图形化能力 较差 较佳
内建简化的作业系统前环境 无 有
有谁在用UEFI?
UEFI支援必须藉由软硬体的相互合作来达成,我们来看看目前市面上流通的產品中,哪些已经採用了UEFI。
支援UEFI的硬体
1. 2006年,苹果电脑推出第一台使用Intel处理器架构的麦金塔电脑。从此开始用EFI/UEFI framework,而非以往搭载IBM PowerPC处理器的麦金塔电脑用的、发源於Sun Microsystems(昇阳电脑公司)的Open Firmware。
▲ 目前新版的Mac OS X都已经支援UEFI。
2. Intel自家的行动型、桌上型和伺服器电脑主机板自2006年起开始全面转换為EFI/UEFI BIOS。例如从945系列晶片组开始,Intel的主机板就已经使用了该framework。
3. 此外,2008年开始,许多64位元电脑系统也正式支援EFI/UEFI BIOS。如IBM的x3450伺服器、微星科技具备ClickBIOS的主机板(包括下一篇介绍的EFINITY主机板)、HP笔记型电脑EliteBook系列和平板电脑、HP Compaq笔记型电脑较新的机种。
▲ 微软到了Windows Server 2008才开始支援UEFI。
支援UEFI的作业系统
1. 早在2000年,Linux作业系统便可以支援EFI,当时是elilo EFIboot loader(开机载体),演化至今是EFI版本的grub。
2. 苹果电脑到了Mac OS X 10.4(代号Tiger)的Intel版便可以支援EFI。
3. 2002年微软给Itanium CPU使用的Windows 2000 Advanced Server Limited Edition及Datacenter Server Limited Edition版支援了EFI v1.10规范。后来的Windows Server 2003 for IA-64版和Windows XP 64-bit版本也支援EFI。至於UEFI的支援是从Windows Server 2008和Vista SP1的64位元版本开始,包括Windows 7也只有64位元版完整支援UEFI。
▲ Intel自家的D945PSN主机板。
综上所述:
BIOS开机:上电---初始化---自检---载入开机程式---开机;
UEFI开机:上电先加载EFI微型操作系统;应用软件,驱动程序,硬件构成;最后加载作业系统windows;什么是电脑中的石硬件?(节选自BIOS负责开机时,对每项石硬件进行初始化测试和设置)_百度知道
什么是电脑中的石硬件?(节选自BIOS负责开机时,对每项石硬件进行初始化测试和设置)
答题抽奖
首次认真答题后
即可获得3次抽奖机会,100%中奖。
采纳数:152
获赞数:443
应该是印刷的问题,或者错别字,意思就是BIOS开机时要对主板上的输入输出硬件及其附属的硬件系统进行检测,如果有错误就会终止报错!
davidwei2004
davidwei2004
采纳数:171
获赞数:224
请予以正确回答,请勿水楼,如需悬赏,请自己回答正确
石硬件?能不能说明白点?
其他1条回答
为你推荐:
其他类似问题
个人、企业类
违法有害信息,请在下方选择后提交
色情、暴力
我们会通过消息、邮箱等方式尽快将举报结果通知您。新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
大富大贵, 积分 12763, 距离下一级还需 7237 积分
论坛徽章:0
Linux系统启动的基本过程和步骤:
Linux系统启动过程大致按照如下步骤进行(这是一个简述):
第一阶段:BIOS启动引导阶段;
& && && && && && && &在该过程中实现硬件的初始化以及查找启动介质;
& && && && && && && &从MBR中装载启动引导管理器(GRUB)并运行该启动引导管理
第二阶段:GRUB启动引导阶段;
& && && && && && && &装载stage1
& && && && && && && &装载stage1.5
& && && && && && && &装载stage2
& && && && && && && &读取/boot/grub.conf文件并显示启动菜单;
& && && && && && && &装载所选的kernel和initrd文件到内存中
第三阶段:内核阶段:
& && && && && && && &运行内核启动参数;
& && && && && && && &解压initrd文件并挂载initd文件系统,装载必须的驱动;
& && && && && && && &挂载根文件系统
第四阶段:Sys V init初始化阶段:
& && && && && && && &启动/sbin/init程序;
& && && && && && && &运行rc.sysinit脚本,设置系统环境,启动swap分区,检查和挂载文件系统;
& && && && && && && &读取/etc/inittab文件,运行在/et/rc.d/rc&#&.d中定义的不同运行级别的服务初始化脚本;
& && && && && && && &打开字符终端1-6号控制台/打开图形显示管理的7号控制台
同时在上述过程中各阶段所需要读取的文件和操作的对象:
BIOS启动引导阶段& && && && && && && && &&&GRUB启动引导阶段& && && && && && &&&内核阶段& && && && && && && && & /init/sysinit阶段
==================================================================================================
None& && && && && && && && && && && && && &&&/boot/grub/grub.conf& && && && & /boot/vmlinuz-&version&& & /etc/rc.d/rc.sysinit
& && && && && && && && && && && && && && && &/boot/grub/stage1_5& && && && & /boot/initrd-&version&& && & /etc/inittab
& && && && && && && && && && && && && && && &/boot/grub/stage2& && && && && && && && && && && && && && && && && && & /etc/rc.d/rc&#&.d
& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &/etc/rc.d/init.d/*
& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&
(下面是详细的过程)& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &
第一阶段:
系统上电开机后,主板BIOS(Basic Input / Output System)运行POST(Power on self test)代码,检测系统外围关键设备(如:CPU、内存、显卡、I/O、键盘鼠标等)。硬件配置信息及一些用户配置参数存储在主板的CMOS( Complementary Metal Oxide Semiconductor)上(一般64字节),实际上就是主板上一块可读写的RAM芯片,由主板上的电池供电,系统掉电后,信息不会丢失。
执行POST代码对系统外围关键设备检测通过后,系统启动自举程序, 根据我们在BIOS中设置的启动顺序搜索启动驱动器(比如的硬盘、光驱、网络服务器等)。选择合适的启动器,比如通常情况下的硬盘设备,BIOS会读取硬 盘设备的第一个扇区(MBR,512字节),并执行其中的代码。实际上这里BIOS并不关心启动设备第一个扇区中是什么内容,它只是负责读取该扇区内容、 并执行,BIOS的任务就完成了。此后将系统启动的控制权移交到MBR部分的代码。
注: 在我们的现行系统中,大多关键设备都是连在主板上的。因此主板BIOS提供了一个操作系统(软件)和系统外围关键设备(硬件)最底级别的接口,在这个阶段,检测系统外围关键设备是否“准备好”,以供操作系统使用。
第二阶段:
BIOS通过下面两种方法之一来传递引导记录:
第一, 将控制权传递给initial program loader(IPL),该程序安装在磁盘主引导记录(MBR)中
第二, 将控制权传递给initial program loader(IPL),该程序安装在磁盘分区的启动引导扇区中
无论上面的哪种情况中,IPL都是MBR的一部分并应该存储于一个不大于446字节的磁盘空间中,因为MBR是一个不大于512字节的空间。
因此IPL仅仅是GRUB的第一个部分(stage1),他的作用就是定位和装载GRUB的第二个部分(stage2);stage2对启动系统起关键作 用,该部分提供了GRUB启动菜单和交互式的GRUB的shell。启动菜单在启动时候通过/boot/grub/grub.conf文件所定义的内容生 成。在启动菜单中选择了kernel之后,GRUB会负责解压和装载kernel image并且将initrd装载到内存中。最后GRUB初始化kernel启动代码。
完成之后后续的引导权被移交给kernel。
假设Boot Loader为grub (grub-0.97),其引导系统的过程如下:
grub分为stage1 (stage1_5) 和stage2两个阶段。stage1可以看成是initial program loaderI(IPL),而stage2则实现了grub的主要功能,包括对特定文件系统的支持(如ext2,ext3,reiserfs 等),grub自己的shell,以及内部程序(如:kernrl,initrd,root)等。
stage 1:MBR(512 字节,0头0道1扇区),前446字节存放的是 stage1,后面存放硬盘分区表信息,BIOS将stag1载入内存中0x7c00处并跳转执行。stage1(/stage1/start.S)的任 务非常单纯,仅仅是将硬盘0头0道2扇区读入内存。0头0道2扇区内容是源代码中的/stage2/start.S,编译后512字节,它是stage2 或者stage1_5的入口。
注:此时stage1是没有能力识别文件系统的,其定位硬盘0头0道2扇区过程如下:
BIOS将stage1载入内存0x7c00处并执行,然后调用BIOS INIT13中断,将硬盘0头0道2扇区内容载入内存0x7000处,然后调用copy_buffer将其转移到内存0x8000处。定位0头0道2扇区有两种寻址方式:LBA、CHS。
start.S的主要功能是将stage2或stage1_5从硬盘载入内存,如果是stage2,则载入0x820处;如果是 stage1_5,则载入0x2200处。
注:这里的stage2或者stage1_5不是/boot分区/boot/grub目录下的文件,这个时候grub还没有能力识别任何文件系统。分以下两种情况:
(1)假如start.S读取的是stage1_5,它存放在硬盘0头0道3扇区向后的位置,stage1_5作为stage1和stage2中间的桥 梁,stage1_5有识别文件系统的能力,此后grub才有能力去访问/boot分区/boot/grub目录下的 stage2文件,将stage2载入内存并执行。
(2)假如start.S读取的是stage2,同样,这个stage2也不是/boot分区/boot/grub目录下的stage2,这个时候 start.S读取的是存放在/boot分区Boot Sector的stage2。这种情况下就有一个限制:因为start.S通过BIOS中断方式直接对硬盘寻址(而非通过访问具体的文件系统),其寻址范 围有限,限制在8GB以内。因此这种情况需要将/boot分区分在硬盘8GB寻址空间之前。
假如是情形(2),我们将/boot/grub目录下的内容清空,依然能成功启动grub;假如是情形(1),将/boot/grub目录下stage2删除后,则系统启动过程中grub会启动失败。
这个地方经常要进行的操作:
是关于grub常用的几个指令对应的函数:
grub&root (hd0,0)& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&--root指令为grub指定了一个根分区
grub&kernel /xen.gz-2.6.18-37.el5& && && && && && && && && && && && && && && && && && && && && && &--kernel指令将操作系统内核载入内存
grub&module /vmlinuz-2.6.18-37.el5xen ro root=/dev/sda2& && && && && && && && && &--module指令加载指定的模块
grub&module /initrd-2.6.18-37.el5xen.img& && && && && && && && && && && && && && && && && && &--指定initrd文件
grub&boot& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && & --boot 指令调用相应的启动函数启动OS内核
第三阶段:
如阶段2所述,grub&boot指令后,系统启动的控制权移交给kernel。Kernel会立即初始化系统中各设备并做相关配置工作,其中包括CPU、I/O、存储设备等。
关于设备驱动加载,有两部分:一部分设备驱动编入Linux Kernel中,Kernel会调用这部分驱动初始化相关设备,同时将日志输出到kernel message buffer,系统启动后dmesg可以查看到这部分输出信息。另外有一部分设备驱动并没有编入Kernel,而是作为模块形式放在 initrd(ramdisk)中。
在2.6内核中,支持两种格式的initrd,一种是2.4内核的文件系统镜像image-initrd,一种是cpio格式。以 cpio 格式为例,内核判断initrd为cpio的文件格式后,会将initrd中的内容释放到rootfs中。
initrd是一种基于内存的文件系统,启动过程中,系统在访问真正的根文件系统/时,会先访问initrd文件系统。将initrd中的内容打开来看, 会发现有bin、devetc、lib、procsys、sysroot、init等文件(包含目录)。其中包含了一些设备的驱动模块,比如scsi ata等设备驱动模块,同时还有几个基本的可执行程序 insmod, modprobe, lvm,nash。主要目的是加载一些存储介质的驱动模块,如上面所说的scsi ideusb等设备驱动模块,初始化LVM,把/根文件系统以只读方式挂载。
initrd中的内容释放到rootfs中后,Kernel会执行其中的init文件,这里的init是一个脚本,由nash解释器执行。这个时候内核的控制权移交给init文件处理,我们查看init文件的内容,主要也是加载各种存储介质相关的设备驱动。
驱动加载后,会创建一个根设备,然后将根文件系统/以只读的方式挂载。这步结束后释放未使用内存并执行switchroot,转换到真正的根/上面去,同 时运行/sbin/init程序,开启系统的1号进程,此后系统启动的控制权移交给 init 进程。关于switchroot是在nash中定义的程序。
Linux Kernel需要适应多种不同的硬件架构,但是将所有的硬件驱动编入Kernel又是不实际的,而且Kernel也不可能每新出一种硬件结构,就将该硬件 的设备驱动写入内核。实际上Linux Kernel仅是包含了基本的硬件驱动,在系统安装过程中会检测系统硬件信息,根据安装信息和系统硬件信息将一部分设备驱动写入 initrd 。这样在以后启动系统时,一部分设备驱动就放在initrd中来加载。
第四阶段:
init进程起来后,系统启动的控制权移交给init进程。
/sbin/init进程是所有进程的父进程,当init起来之后,它首先会读取配置文件/etc/inittab,进行以下工作:
1)执行系统初始化脚本(/etc/rc.d/rc.sysinit),对系统进行基本的配置,以读写方式挂载根文件系统及其它文件系统,到此系统基本算运行起来了,后面需要进行运行级别的确定及相应服务的启动;
2)确定启动后进入的运行级别;
3) 执行/etc/rc.d/rc,该文件定义了服务启动的顺序是先K后S,而具体的每个运行级别的服务状态是放在/etc/rc.d/rcn.d(n=0~6)目录下,所有的文件均链接至/etc/init.d下的相应文件。
4)有关key sequence的设置
5) 有关UPS的脚本定义
6)启动虚拟终端/sbin/mingetty
7)在运行级别5上运行X
这时呈现给用户的就是最终的登录界面。
至此,系统启动过程完毕:)
1)/etc/rc.d/rc.sysint -- System Initialization Tasks
它的主要工作有:
配置selinux,
系统时钟,
内核参数(/etc/sysctl.conf),
hostname,
启用swap分区,
根文件系统的检查和二次挂载(读写),
激活RAID和LVM设备,
启用磁盘quota
检查并挂载其它文件系统
GRUB的基本原理以及对GRUB的操作控制方法:
GRUB全称为Grand Unified Boot Loader,是Linux操作系统主流的启动引导管理器。主要作用是启动和装载Linux操作系统。系统启动过程中一旦完成了BIOS自检,GRUB会 被立刻装载。在GRUB里面包含了可以载入操作系统的代码以及将操作系统引导权传递给其他启动引导管理器的代码。GRUB可以允许用户选择使用不同的 kernel启动系统,或者在启动系统的过程中设置不同的启动参数。
而通常BIOS会以下面两种方法之一来调用启动引导管理器:
将控制权移交给于驱动器主引导记录的initial program loader(IPL);
将控制权移交给其他启动引导管理器,再由他们将控制权移交给安装在分区引导扇区的IPL
通常情况下启动引导管理器GRUB由两部分组成(stage1和stage2):
stage1比较小,通常可以驻留在MBR或者各个磁盘分区的启动扇区中,主要作用是装载stage2。
stage2比较大,从磁盘的启动引导分区读取
至于在stage1和stage2之间存在一个stage1.5,是因为starge1.5具有识别文件系统的能力。
在Linux系统中对GRUB的配置有两种方法:
主要引导管理器:
会将启动引导管理器的stage1安装在MBR上,这时启动引导管理器必须被配置为可以传递控制权到其他操作系统;
次要引导管理器:
会将启动引导管理器的stage1安装在一些分区的引导扇区上,而其他的启动引导管理器会被安装在MBR上,由他们来向Linux启动引导管理器传递控制权。
GRUB在启动过程中可以提供命令行交互界面,可以从ext系列,reiserfs,fat等多种文件系统引导系统,并且可以提供密码加密功能,其内容在 /boot分区下,系统启动过程中由配置文件/boot/grub/grub.conf来定义启动方式,对该配置文件的更改会立即生效。
在配置文件/boot/grub/grub.conf文件中定义的内容包括:
grub所在的分区,引导系统所使用的kernel文件位置,硬件初始化使用的initrd文件位置,以及启动参数。
grub&root (hd0,0)& && && && && && && && && && && && && && && && && && && && && && && && && && && && &&&--root指令为grub指定了一个根分区
grub&kernel /xen.gz-2.6.18-37.el5& && && && && && && && && && && && && && && && && && && && &--kernel指令将操作系统内核载入内存
grub&module /vmlinuz-2.6.18-37.el5xen ro root=/dev/sda2& && && && && && && &--module指令加载指定的模块
grub&module /initrd-2.6.18-37.el5xen.img& && && && && && && && && && && && && && && && &--指定initrd文件
grub&boot& && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && && & --boot 指令调用相应的启动函数启动OS内核
可见其指定的内容大多数在/boot分区,如果切换到/boot分区之后会看到这些内容:
/boot/vmlinuz-*& && && && && &&&linux kernel的一个copy;
/boot/initrd*.img& && && && & 初始化的ram disk文件
/boot/grub/device.map& && &&&linux设备名和grub设备名的映射文件
/boot/grub/grub.conf& && & 主配置文件
通常GRUB出错几率不是很大,但一旦出现问题恐怕采用最多的方式是重装grub到MBR中。
在这种时候需要注意的问题有:
首先,设备映射关系:
GRUB里面对设备名称的定义和系统中对设备名称的定义方法不一样:
& && & (fd0)& && && && & /dev/fd0
& && & (hd0)& && && && & /dev/sda& && &&&/dev/hda
& && & (hd1)& && && && & /dev/sdb& && &&&/dev/hdb
如够进入系统或者救援模式,可执行命令/sbin/grub-install /dev/sda(或者hda)进行GRUB重装:
& && & # /sbin/grub-install device
处于某种原因MBR中信息出错可以使用上面的命令将其重装到磁盘主引导记录中;但是如果在不能进入系统的情况下就需要通过grub的命令行界面进行手动设置,这个时候就要注意上面所提到的映射关系。
同时,在grub命令行中对grub进行手动设置的时候需要注意所使用的命令:
& && & # root (hd0,0)& && && && && && && && && &--指定启动分区
& && & # setup(hd0)& && && && && && && && && & --表示将grub安装在主引导记录上
& && & # quit& && && && && && && && && && && && && && & --退出grub& && &&&shell
下面是一个完整的grub.conf文件内容:
[root@dhcp-0-195 ~]# cat /etc/grub.conf
# grub.conf generated by anaconda
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:& &You have a /boot partition.& &This means that
#& && & all kernel and initrd paths are relative to /boot/, eg.
#& && & root (hd0,0)
#& && & kernel /vmlinuz-version ro root=/dev/VolGroup001/LogVol00
#& && & initrd /initrd-version.img
#boot=/dev/sda
timeout=30
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
password --md5 $1$apEcJWbA$DTJ8a6mKn/3yrTTSXBtdH0
title Red Hat Enterprise Linux Client (2.6.18-8.1.1.el5)
& && & root (hd0,0)
& && & kernel /vmlinuz-2.6.18-8.1.1.el5 ro root=/dev/VolGroup001/LogVol00 crashkernel=128M@16M
& && & initrd /initrd-2.6.18-8.1.1.el5.img
系统启动运行级别的概念以及服务的定制方法;
当initrd可以正常检测和装载之后,最后的工作就基本上由操作系统来进行了。当系统的init进程起来之后系统启动的控制权移交给init进程。
/sbin/init进程是所有进程的父进程,当init起来之后,它首先会读取配置文件/etc/inittab,进行以下工作:
1)执行系统初始化脚本(/etc/rc.d/rc.sysinit),对系统进行基本的配置,以读写方式挂载根文件系统及其它文件系统,后面需要进行运 行级别的确定及相应服务的启动,(从这个角度可以看出如果要定义系统的init动作,需要修改/etc/rc.d/rc.sysinit脚本)
2)通过对/etc/inittab文件的读取确定启动后进入的运行级别;
3) 在相应的运行级别中执行/etc/rc.d/rcx.d目录下的脚本名称,该文件定义了服务启动的顺序是先K后S,而具体的每个运行级别的服务状态是放在 /etc/rc.d/rcn.d(n=0~6)目录下,但这些文件均是到/etc/init.d下的相应文件的链接。
系统会按照在该目录下的文件名称和优先级执行对应运行级别目录下的脚本:
在某个运行级别的对应目录下,K开头的服务被关闭,S开头的服务被开启,K在S开始之前执行,在执行过程中按照数字来定义优先级,数字越低优先级越高。
4)按照/etc/rc.d/rcX.d目录中的定义,系统会于后台启动相应的服务,如果要对某个运行级别中的服务进行更具体的定制,通过chkconfig命令来操作,或者通过setup/ntsys/system-config-services来进行定制。
5)在/etc/inittab文件中存在有关key sequence,UPS的脚本定义,启动虚拟终端/sbin/mingetty的设置,这时呈现给用户的就是最终的登录界面。
也就是说后台启动的服务完毕之后,如果系统默认进入字符界面,则运行mgetty进入1-6号终端控制台,如果系统默认进入图形界面,则开启gdm服务进入7号虚拟图形控制台。
至此,系统启动过程完毕。
对于/etc/rc.d/rc.sysinit文件的说明:
/etc/rc.d/rc.sysint -- System Initialization Tasks 执行系统初始化任务的脚本。
它的主要工作有:
配置selinux,
系统时钟,
内核参数(/etc/sysctl.conf),
hostname,
启用swap分区,
根文件系统的检查和二次挂载(读写),
激活RAID和LVM设备,
启用磁盘quota
检查并挂载其它文件系统
这是其基本要实现的工作内容:
#!/bin/bash
# /etc/rc.d/rc.sysinit - run once at boot time
# Taken in part from Miquel van Smoorenburg's bcheckrc.
# Check SELinux status
& && && &&&
# Because of a chicken/egg problem, init_crypto must be run twice.& &/var may be
# encrypted but /var/lib/random-seed is needed to initialize swap.
# Only read this once.
# Initialize hardware
# Set default affinity
# Load other user-defined modules
# Load modules (for backward compatibility with VARs)
# Start the graphical boot, /usr may not be mounted yet, so we
# may have to do this again after mounting
# Configure kernel parameters
# Set the hostname.
# Initialize ACPI bits
# RAID setup
# Device mapper & related initialization
# Update quotas if necessary
# Remount the root filesystem read-write.
# Clean up SELinux labels
# Clear mtab
# Remove stale backups
# Enter mounted filesystems into /etc/mtab
# Mount all other filesystems (except for NFS and /proc, which is already
# mounted). Contrary to standard usage,
# filesystems are NOT unmounted in single user mode.
# Check to see if a full relabel is needed
# Start the graphical boot, if necessary and not done yet.
# Initialize pseudo-random number generator
# Use the hardware RNG to seed the entropy pool, if available
# Configure machine if necessary.
# Clean out /.
# Do we need (w|u)tmpx files? We don't set them up, but the sysadmin might...
# Clean up /var.& &I'd use find, but /usr may not be mounted.
# Reset pam_console permissions
# Clean up utmp/wtmp
# Clean up various /tmp bits
# Make ICE directory
# Start up swapping.
家境小康, 积分 1483, 距离下一级还需 517 积分
论坛徽章:0
顶一下,太好了,谢谢了。
富足长乐, 积分 5671, 距离下一级还需 2329 积分
论坛徽章:0
非常棒,收藏了
感谢楼主分享
富足长乐, 积分 7550, 距离下一级还需 450 积分
论坛徽章:0
佩服!学习了!
论坛徽章:0
真的很不错谢谢楼住提供
富足长乐, 积分 5671, 距离下一级还需 2329 积分
论坛徽章:0
顺便问一句,这么长的文章,楼主用了多长时间?
白手起家, 积分 59, 距离下一级还需 141 积分
论坛徽章:0
强帖,留名,学习
哈哈,真不是一般的强!!
稍有积蓄, 积分 325, 距离下一级还需 175 积分
论坛徽章:0
写的真好,强烈建议版主应多加点分
大富大贵, 积分 12763, 距离下一级还需 7237 积分
论坛徽章:0
想不到有这么多人支持,既然如此我将这篇文章的下半部分:八个trouble shooting的大概案例共享出来吧!哈哈!
大富大贵, 积分 12763, 距离下一级还需 7237 积分
论坛徽章:0
以下是我在生产环境中所碰到的一些和GRUB修复有关的案例:
GRUB无法找到kernel image的问题:
产生这类型问题的原因包括:
配置文件中指定了错误的kernel image名称或者路径,在/boot分区下kernel文件被删除或者更名,kernel image文件被破坏,Raid-1磁盘阵列更换故障盘后信息不同步等。
对于这类型问题的解决方法:
可以设法通过救援模式或者在开机的时候进入grub的shell,然后利用grub shell尝试手动指定和装载正确的kernel image信息或者在救援模式下检查和重写grub.conf文件。
需要注意的是,如果要通过救援模式进入grub命令行界面需要先chroot,即执行chroot /mnt/sysimage。在
grub&提示符之后执行:
# root (hd0,0)
# setup(hd0)
不管通过什么样的方法和配置,只要使GRUB能够正确找到kernel image是解决问题的关键。
在对grub修复的时候尤其要注意MBR信息在软件Raid上的恢复。
Linux的boot分区不能建立在软件Raid-0上,但是可以建立在Raid-1阵列上。也就意味着系统的GRUB也是同时写入到Raid-1磁盘阵列两块盘的MBR中。但是如果这个信息一旦这个信息没有正确写入或者正常完成写入,问题就会出现。
这种情况多发于对Raid-1阵列中的坏盘进行更换的时候。
一个典型的例子是,用户只有两块磁盘做Raid-1,他在两块盘上分别规划了同样的磁盘分区/boot swap以及/,对应的设备是md0,md1和md2。在其中的某一个磁盘出现问题的时候,用户更换一块新的磁盘,并且按照原来的盘规划了/boot,swap以及/,同时使用了命令mdadm -A对三个md都进行了重组,重组能够顺利完成,但是一旦重启系统在出现一个GRUB的提示对话框之后引导停止。
从这个情况看来,很显然,md0,md1和md2内的数据都由原来的磁盘向新的磁盘进行了同步,但是MBR的内容和信息没有同步过来。这就造成了系统启动的失败。
解决该问题的方法:
可以使用救援模式引导系统,或者使得GRUB能够检测到文件系统——即出现GRUB&提示符,执行下面的命令,将GRUB重装到第一块盘:
# root (hd0,0)
# setup(hd0)
然后执行,将GRUB重装到第二块盘:
# root (hd1,0)
# setup(hd0)
完成之后重启系统。这种方法还可以对付在BIOS中对启动引导管理器进行的修改。
None System or Disk Error和GRUB的关系:
某个用户曾经报告一台HP的DL380服务器上原有40G和140G两块硬盘,并且按照第一块硬盘所能够提供的磁盘空间建立了一个软件Raid-0磁盘阵列。该用户在没有拔除这两块硬盘的情况下直接加入了两块新的硬盘并计划对原有的Raid-0阵列进行扩容。但在插入硬盘重启之后显示“None System or Disk Error”,在用户拔除这两块硬盘之后重启还出现同样的信息。
根据描述的系统启动过程来看,这个none system or disk error的报错,表明系统启动引导过程中并没有装在任何启动引导管理器(GRUB)信息,而之所以没有找到这些信息是因为这些磁盘的MBR里面没有用于引导的IPL或者说白了系统所用于引导的磁盘根本就不是启动盘。看来系统并没有使用用户设想的磁盘作为启动引导磁盘。那么也就时说这和在磁盘的GRUB没有任何关系,我们所要做的第一能够确保系统使用正确的磁盘引导,第二就是没有对原有的GRUB进行任何错误的修改就行。
按照我们对问题的分析,用户更换了硬盘所在的槽位,问题得到解决。
产生该问题的原因是因为HP DL380服务器在安装系统必须在阵列上进行,但是新加入的磁盘或者阵列会更改原来默认的启动引导顺序。尽管这和GRUB的修复没有任何关系,但是能够准确定位该问题的所在至少能够减少排错的时间以及一些不必要的麻烦。
在RHEL3中HP服务器上的cciss和system-map的问题:
众所周知在GRUB中对设备进行命名的方法和系统命名的方法是不同的。不管系统中的启动引导磁盘是sd接口还是hd接口在GRUB中都会被统一识别为hd,并且hda/sdahd0,hdb/sdbhd1……依次类推。这和系统对设备的命名方式显然存在一些差异,但是这种差异通过在/boot/grub/device-map文件中进行解释和映射来实现系统对两种设备命名方法的映射。
这是一个device-map文件的内容:
遗憾的是,redhat老版本的操作系统如RHEL3的某个版本,在一些特殊的硬件上,如HP的cciss中对系统设备名和GRUB设备名的映射关系不正确而导致系统在这些硬件上无法启动。这可以认为是操作系统的一个bug,所幸该bug在RHEL3靠后的几个发行版后都得到了修复。
尽管碰到这种问题的几率极低,但需要明确一点,检查设备映射是否正确也是GRUB排错的一项内容。
这里顺别说一下:
cciss是惠普的smart array控制器的设备名,c0指channl 0,第一个SCSI通道,d0指逻辑盘1,d1指逻辑盘2……,p1指第一个分区,p2是第二个分区……。在这种情况下,我们可以看到很多HP的服务器在通过该设备连接硬盘的时候,经常看到的设备是/dev/cciss/c0d0p1,/dev/cciss/c0d0p2,/dev/cciss/c0d0p3等。
北京盛拓优讯信息技术有限公司. 版权所有 京ICP备号 北京市公安局海淀分局网监中心备案编号:22
广播电视节目制作经营许可证(京) 字第1234号
中国互联网协会会员&&联系我们:
感谢所有关心和支持过ChinaUnix的朋友们
转载本站内容请注明原作者名及出处

我要回帖

更多关于 vcu自检初始化 的文章

 

随机推荐