zoukankan      html  css  js  c++  java
  • 【 计算机基础 】系统启动与磁盘分区布局

    Linux启动过程
        启动顺序:
        加载BIOS的硬件信息与进行自我测试,并依据设置取得第一个可启动的设备
        读取并执行第一个启动设备内的MBR的boot loader(即是grub spfidisk等程序)
        依据bootloader的设置加载kernel,kernel会开始检测硬件和加载驱动程序。
        驱动程序成功后,kernel会主动调用init进程,而init会取得run-level信息。
        init执行/etc/rc.d/rc.sysinit文件来准备软件执行的操作环境(网络,时区等)
        init执行run-level的各个服务的启动(scirpt方式)
        init执行/etc/rc.d/rc.local文件
        init执行终端机模拟程序mingetty来启东login进程,最后等待用户登录。

    linux启动流程
        理解操作系统开机引导和启动过程对于配置操作系统和解决相关启动问题是至关重要的。该文章陈述了 GRUB2 引导装载程序开机引导装载内核的过程和 systemd 初始化系统执行开机启动操作系统的过程。
        事实上,操作系统的启动分为两个阶段:引导boot和启动startup。引导阶段开始于打开电源开关,结束于内核初始化完成和 systemd 进程成功运行。启动阶段接管了剩余工作,直到操作系统进入可操作状态。
        总体来说,Linux 的开机引导和启动过程是相当容易理解,下文将分节对于不同步骤进行详细说明。
            BIOS 上电自检(POST)
            引导装载程序 (GRUB2)
            内核初始化
            启动 systemd,其是所有进程之父。
        注意,本文以 GRUB2 和 systemd 为载体讲述操作系统的开机引导和启动过程,是因为这二者是目前主流的 linux 发行版本所使用的引导装载程序和初始化软件。当然另外一些过去使用的相关软件仍然在一些 Linux 发行版本中使用。
        
        引导过程
            引导过程能以两种方式之一初始化。其一,如果系统处于关机状态,那么打开电源按钮将开启系统引导过程。其二,如果操作系统已经运行在一个本地用户(该用户可以是 root 或其他非特权用户),那么用户可以借助图形界面或命令行界面通过编程方式发起一个重启操作,从而触发系统引导过程。重启包括了一个关机和重新开始的操作。
            
        BIOS 上电自检(POST)
            上电自检过程中其实 Linux 没有什么也没做,上电自检主要由硬件的部分来完成,这对于所有操作系统都一样。当电脑接通电源,电脑开始执行 BIOS(基本输入输出系统Basic I/O System)的 POST(上电自检Power On Self Test)过程。
            在 1981 年,IBM 设计的第一台个人电脑中,BIOS 被设计为用来初始化硬件组件。POST 作为 BIOS 的组成部分,用于检验电脑硬件基本功能是否正常。如果 POST 电失败,那么这个脑就不能使用,引导过程也将就此中断。
            BIOS 上电自检确认硬件的基本功能正常,然后产生一个 BIOS 中断 INT 13H,该中断指向某个接入的可引导设备的引导扇区。它所找到的包含有效的引导记录的第一个引导扇区将被装载到内存中,并且控制权也将从引导扇区转移到此段代码。
            引导扇区是引导加载器真正的第一阶段。大多数 Linux 发行版本使用的引导加载器有三种:GRUB、GRUB2 和 LILO。GRUB2 是最新的,也是相对于其他老的同类程序使用最广泛的。
            
        GRUB2
            GRUB2 全称是 GRand Unified BootLoader,Version 2(第二版大一统引导装载程序)。它是目前流行的大部分 Linux 发行版本的主要引导加载程序。GRUB2 是一个用于计算机寻找操作系统内核并加载其到内存的智能程序。由于 GRUB 这个单词比 GRUB2 更易于书写和阅读,在下文中,除特殊指明以外,GRUB 将代指 GRUB2。
            GRUB 被设计为兼容操作系统多重引导规范,它能够用来引导不同版本的 Linux 和其他的开源操作系统;它还能链式加载专有操作系统的引导记录。
            GRUB 允许用户从任何给定的 Linux 发行版本的几个不同内核中选择一个进行引导。这个特性使得操作系统,在因为关键软件不兼容或其它某些原因升级失败时,具备引导到先前版本的内核的能力。GRUB 能够通过文件 /boot/grub/grub.conf 进行配置。(LCTT 译注:此处指 GRUB1)
            GRUB1 现在已经逐步被弃用,在大多数现代发行版上它已经被 GRUB2 所替换,GRUB2 是在 GRUB1 的基础上重写完成。基于 Red Hat 的发行版大约是在 Fedora 15 和 CentOS/RHEL 7 时升级到 GRUB2 的。GRUB2 提供了与 GRUB1 同样的引导功能,但是 GRUB2 也是一个类似主框架(mainframe)系统上的基于命令行的前置操作系统(Pre-OS)环境,使得在预引导阶段配置更为方便和易操作。GRUB2 通过 /boot/grub2/grub.cfg 进行配置。
            两个 GRUB 的最主要作用都是将内核加载到内存并运行。两个版本的 GRUB 的基本工作方式一致,其主要阶段也保持相同,都可分为 3 个阶段。在本文将以 GRUB2 为例进行讨论其工作过程。GRUB 或 GRUB2 的配置,以及 GRUB2 的命令使用均超过本文范围,不会在文中进行介绍。
            虽然 GRUB2 并未在其三个引导阶段中正式使用这些阶段stage名词,但是为了讨论方便,我们在本文中使用它们。
        阶段 1
            如上文 POST(上电自检)阶段提到的,在 POST 阶段结束时,BIOS 将查找在接入的磁盘中查找引导记录,其通常位于 MBR(主引导记录Master Boot Record),它加载它找到的第一个引导记录中到内存中,并开始执行此代码。引导代码(及阶段 1 代码)必须非常小,因为它必须连同分区表放到硬盘的第一个 512 字节的扇区中。 在传统的常规 MBR 中,引导代码实际所占用的空间大小为 446 字节。这个阶段 1 的 446 字节的文件通常被叫做引导镜像(boot.img),其中不包含设备的分区信息,分区是一般单独添加到引导记录中。
            由于引导记录必须非常的小,它不可能非常智能,且不能理解文件系统结构。因此阶段 1 的唯一功能就是定位并加载阶段 1.5 的代码。为了完成此任务,阶段 1.5 的代码必须位于引导记录与设备第一个分区之间的位置。在加载阶段 1.5 代码进入内存后,控制权将由阶段 1 转移到阶段 1.5。
        阶段 1.5
            如上所述,阶段 1.5 的代码必须位于引导记录与设备第一个分区之间的位置。该空间由于历史上的技术原因而空闲。第一个分区的开始位置在扇区 63 和 MBR(扇区 0)之间遗留下 62 个 512 字节的扇区(共 31744 字节),该区域用于存储阶段 1.5 的代码镜像 core.img 文件。该文件大小为 25389 字节,故此区域有足够大小的空间用来存储 core.img。    
            因为有更大的存储空间用于阶段 1.5,且该空间足够容纳一些通用的文件系统驱动程序,如标准的 EXT 和其它的 Linux 文件系统,如 FAT 和 NTFS 等。GRUB2 的 core.img 远比更老的 GRUB1 阶段 1.5 更复杂且更强大。这意味着 GRUB2 的阶段 2 能够放在标准的 EXT 文件系统内,但是不能放在逻辑卷内。故阶段 2 的文件可以存放于 /boot 文件系统中,一般在 /boot/grub2 目录下。
            注意 /boot 目录必须放在一个 GRUB 所支持的文件系统(并不是所有的文件系统均可)。阶段 1.5 的功能是开始执行存放阶段 2 文件的 /boot 文件系统的驱动程序,并加载相关的驱动程序。
            
        阶段 2
            GRUB 阶段 2 所有的文件都已存放于 /boot/grub2 目录及其几个子目录之下。该阶段没有一个类似于阶段 1 与阶段 1.5 的镜像文件。相应地,该阶段主要需要从 /boot/grub2/i386-pc 目录下加载一些内核运行时模块。    
            GRUB 阶段 2 的主要功能是定位和加载 Linux 内核到内存中,并转移控制权到内核。内核的相关文件位于 /boot 目录下,这些内核文件可以通过其文件名进行识别,其文件名均带有前缀 vmlinuz。你可以列出 /boot 目录中的内容来查看操作系统中当前已经安装的内核。
            GRUB2 跟 GRUB1 类似,支持从 Linux 内核选择之一引导启动。Red Hat 包管理器(DNF)支持保留多个内核版本,以防最新版本内核发生问题而无法启动时,可以恢复老版本的内核。默认情况下,GRUB 提供了一个已安装内核的预引导菜单,其中包括问题诊断菜单(recuse)以及恢复菜单(如果配置已经设置恢复镜像)
            阶段 2 加载选定的内核到内存中,并转移控制权到内核代码
        内核
            内核文件都是以一种自解压的压缩格式存储以节省空间,它与一个初始化的内存映像和存储设备映射表都存储于 /boot 目录之下。
            在选定的内核加载到内存中并开始执行后,在其进行任何工作之前,内核文件首先必须从压缩格式解压自身。一旦内核自解压完成,则加载 systemd 进程(其是老式 System V 系统的 init 程序的替代品),并转移控制权到 systemd。
            这就是引导过程的结束。此刻,Linux 内核和 systemd 处于运行状态,但是由于没有其他任何程序在执行,故其不能执行任何有关用户的功能性任务。
        启动过程
            启动过程紧随引导过程之后,启动过程使 Linux 系统进入可操作状态,并能够执行用户功能性任务。        
        systemd
            systemd 是所有进程的父进程。它负责将 Linux 主机带到一个用户可操作状态(可以执行功能任务)。systemd 的一些功能远较旧式 init 程序更丰富,可以管理运行中的 Linux 主机的许多方面,包括挂载文件系统,以及开启和管理 Linux 主机的系统服务等。但是 systemd 的任何与系统启动过程无关的功能均不在此文的讨论范围。    
            首先,systemd 挂载在 /etc/fstab 中配置的文件系统,包括内存交换文件或分区。据此,systemd 必须能够访问位于 /etc 目录下的配置文件,包括它自己的。systemd 借助其配置文件 /etc/systemd/system/default.target 决定 Linux 系统应该启动达到哪个状态(或目标态target)。default.target 是一个真实的 target 文件的符号链接。对于桌面系统,其链接到 graphical.target,该文件相当于旧式 systemV init 方式的 runlevel 5。对于一个服务器操作系统来说,default.target 更多是默认链接到 multi-user.target, 相当于 systemV 系统的 runlevel 3。
            emergency.target 相当于单用户模式。
            (LCTT 译注:“target” 是 systemd 新引入的概念,目前尚未发现有官方的准确译名,考虑到其作用和使用的上下文环境,我们认为翻译为“目标态”比较贴切。以及,“unit” 是指 systemd 中服务和目标态等各个对象/文件,在此依照语境译作“单元”。)
            注意,所有的目标态target和服务service均是 systemd 的单元unit。
            如下表 1 是 systemd 启动的目标态target和老版 systemV init 启动运行级别runlevel的对比。这个 systemd 目标态别名 是为了 systemd 向前兼容 systemV 而提供。这个目标态别名允许系统管理员(包括我自己)用 systemV 命令(例如 init 3)改变运行级别。当然,该 systemV 命令是被转发到 systemd 进行解释和执行的。
            
            SystemV        systemd             systemd                描述
            运行级别    目标态              目标态别名          
                        halt.target                             停止系统运行但不切断电源。
            0           poweroff.target     runlevel0.target    停止系统运行并切断电源.
            S           emergency.target                        单用户模式,没有服务进程运行,文件系统也没挂载。这是一个最基本的运行级别,仅在主控制台上提供一个 shell 用于用户与系统进行交互。
            1           rescue.target       runlevel1.target    挂载了文件系统,仅运行了最基本的服务进程的基本系统,并在主控制台启动了一个 shell 访问入口用于诊断。
            2                               runlevel2.target    多用户,没有挂载 NFS 文件系统,但是所有的非图形界面的服务进程已经运行。
            3           multi-user.target   runlevel3.target    所有服务都已运行,但只支持命令行接口访问。
            4                               runlevel4.target    未使用。
            5           graphical.target    runlevel5.target    多用户,且支持图形界面接口。
            6           reboot.target       runlevel6.target    重启。
                        default.target                          这个目标态target是总是 multi-user.target 或 graphical.target 的一个符号链接的别名。
                                                                systemd 总是通过 default.target 启动系统。default.target 绝不应该指向 halt.target、 poweroff.target 或 reboot.target。        
            
            表 1 老版本 systemV 的 运行级别与 systemd 与目标态target或目标态别名的比较
            每个目标态target有一个在其配置文件中描述的依赖集,systemd 需要首先启动其所需依赖,这些依赖服务是 Linux 主机运行在特定的功能级别所要求的服务。当配置文件中所有的依赖服务都加载并运行后,即说明系统运行于该目标级别。    
            systemd 也会查看老式的 systemV init 目录中是否存在相关启动文件,若存在,则 systemd 根据这些配置文件的内容启动对应的服务。在 Fedora 系统中,过时的网络服务就是通过该方式启动的一个实例。
            如下图 1 是直接从 bootup 的 man 页面拷贝而来。它展示了在 systemd 启动过程中一般的事件序列和确保成功的启动的基本的顺序要求。
            sysinit.target 和 basic.target 目标态可以被视作启动过程中的状态检查点。尽管 systemd 的设计初衷是并行启动系统服务,但是部分服务或功能目标态是其它服务或目标态的启动的前提。系统将暂停于检查点直到其所要求的服务和目标态都满足为止。
            sysinit.target 状态的到达是以其所依赖的所有资源模块都正常启动为前提的,所有其它的单元,如文件系统挂载、交换文件设置、设备管理器的启动、随机数生成器种子设置、低级别系统服务初始化、加解密服务启动(如果一个或者多个文件系统加密的话)等都必须完成,但是在 sysinit.target 中这些服务与模块是可以并行启动的。
            sysinit.target 启动所有的低级别服务和系统初具功能所需的单元,这些都是进入下一阶段 basic.target 的必要前提。
                图片丢失
            
            在 sysinit.target 的条件满足以后,systemd 接下来启动 basic.target,启动其所要求的所有单元。 basic.target 通过启动下一目标态所需的单元而提供了更多的功能,这包括各种可执行文件的目录路径、通信 sockets,以及定时器等。
            最后,用户级目标态(multi-user.target 或 graphical.target) 可以初始化了,应该注意的是 multi-user.target 必须在满足图形化目标态 graphical.target 的依赖项之前先达成。
            图 1 中,以 * 开头的目标态是通用的启动状态。当到达其中的某一目标态,则说明系统已经启动完成了。如果 multi-user.target 是默认的目标态,则成功启动的系统将以命令行登录界面呈现于用户。如果 graphical.target 是默认的目标态,则成功启动的系统将以图形登录界面呈现于用户,界面的具体样式将根据系统所配置的显示管理器而定。
            
    MBR与GPT相关
        1. MBR分区表: Master Boot Record ,即硬盘主引导记录分区表,只支持容量在2.1TB以下的硬盘,超过2.1TB的硬盘只能管理2.1TB,最多只支持4个主分区或三个主分区和一个扩展分区,扩展分区下可以有多个逻辑分区。
        2. GPT分区表: GPT,全局唯一标识分区表(GUID Partition Table) ,与MBR最大4个分区表项的限制相比, GPT对分区数量没有限制,但Windows最大仅支持128个GPT分区, GPT可管理硬盘大小达到了18EB,只有基于UEFI平台的主板才支持GPT分区引导启动。    
        3. ESP分区: EFl system partition ,该分区用于采用了EFI BIOS的电脑系统,用来启动操作系统。分区内存放引导管理程序、驱动程序、系统维护工具等。如果电脑采用了EF系统,或当前磁盘用于在EFI平台上启动操作系统,则应建议ESP分区。    
        4. MSR分区:即微软保留分区,是GPT磁盘上用于保留空间以备用的分区,例如在将磁盘转换为动态磁盘时需要使用这些分区空间。    
        5. SECURE BOOT功能: Windows 8中增加了一个新的安全功能Secure Boot内置于UE FI BIOS中,用来对抗感染MBR, BIOS的恶意软件, Windows 8缺省将使用Secure Boot,在启动过程中,任何要加载的模块必须签名(强制的) , UEFI固件会进行验证,没有签名或者无法验证的,将不会加载。    
        
        GPT概述
            全局唯一标识分区表(GUID Partition Table,缩写:GPT)是一个实体硬盘的分区结构。它是可扩展固件接口标准的一部分,用来替代BIOS中的主引导记录分区表。 传统的主启动记录 (MBR) 磁盘分区支持最大卷为 2.2 TB (terabytes) ,每个磁盘最多有 4 个主分区(或 3 个主分区,1 个扩展分区和无限制的逻辑驱动器)。 与MBR 分区方法相比,GPT 具有更多的优点,因为它允许每个磁盘有多达 128 个分区,支持高达 18 千兆兆字节(exabytes,1EB=10^6TB) 的卷大小,允许将主磁盘分区表和备份磁盘分区表用于冗余,还支持唯一的磁盘和分区 ID (GUID)。
            与 MBR 分区的磁盘不同,GPT的分区信息是在分区中,而不象MBR一样在主引导扇区。为保护GPT不受MBR类磁盘管理软件的危害,GPT在主引导扇区建立了一 个保护分区 (Protective MBR)的MBR分区表,这种分区的类型标识为0xEE,这个保护分区的大小在Windows下为128MB,Mac OS X下为200MB,在Window磁盘管理器里名为GPT保护分区,可让MBR类磁盘管理软件把GPT看成一个未知格式的分区,而不是错误地当成一个未分 区的磁盘。另外,GPT 分区磁盘有多余的主要及备份分区表来提高分区数据结构的完整性。
            在MBR硬盘中,分区信息直接存储于主引导记录(MBR)中(主引导记录中还存储着系统的引导程序)。但在GPT硬盘中,分区表的位置信息储存在GPT头中。但出于兼容性考虑,硬盘的第一个扇区仍然用作MBR,之后才是GPT头。跟现代的MBR一样,GPT也使用逻辑区块地址(LBA)取代了早期的CHS寻址方式。传统MBR信息存储于LBA 0,GPT头存储于LBA 1,接下来才是分区表本身。64位Windows操作系统使用16,384字节(或32扇区)作为GPT分区表,接下来的LBA 34是硬盘上第一个分区的开始。为了减少分区表损坏的风险,GPT在硬盘最后保存了一份分区表的副本。与主启动记录 (MBR) 分区方法相比,GPT 具有更多的优点,因为它允许每个磁盘有多达 128 个分区,支持高达18 千兆兆字节的卷大小,允许将主磁盘分区表和备份磁盘分区表用于冗余,还支持唯一的磁盘和分区ID(GUID)。
        GPT分区结构     
            图片丢失
        传统MBR (LBA 0)     
            在GPT分区表的最开头,处于兼容性考虑仍然存储了一份传统的MBR,用来防止不支持GPT的硬盘管理工具错误识别并破坏硬盘中的数据,这个MBR也叫做保护MBR。在支持从GPT启动的操作系统中,这里也用于存储第一阶段的启动代码。在这个MBR中,只有一个标识为0xEE的分区,以此来表示这块硬盘使用GPT分区表。不能识别GPT硬盘的操作系统通常会识别出一个未知类型的分区,并且拒绝对硬盘进行操作,除非用户特别要求删除这个分区。这就避免了意外删除分区的危险。另外,能够识别GPT分区表的操作系统会检查保护MBR中的分区表,如果分区类型不是0xEE或者MBR分区表中有多个项,也会拒绝对硬盘进行操作。
            在使用MBR/GPT混合分区表的硬盘中,这部分存储了GPT分区表的一部分分区(通常是前四个分区),可以使不支持从GPT启动的操作系统从这个MBR启动,启动后只能操作MBR分区表中的分区。如Boot Camp就是使用这种方式启动Windows。
            
                图片丢失
            
        分区表头 (LBA 1)
            分区表头定义了硬盘的可用空间以及组成分区表的项的大小和数量。在使用64位Windows Server 2003的机器上,最多可以创建128个分区,即分区表中保留了128个项,其中每个都是128字节。(EFI标准要求分区表最小要有16,384字节,即128个分区项的大小)
            分区表头还记录了这块硬盘的GUID,记录了分区表头本身的位置和大小(位置总是在LBA 1)以及备份分区表头和分区表的位置和大小(在硬盘的最后)。它还储存着它本身和分区表的CRC32校验。固件、引导程序和操作系统在启动时可以根据这个校验值来判断分区表是否出错,如果出错了,可以使用软件从硬盘最后的备份GPT中恢复整个分区表,如果备份GPT也校验错误,硬盘将不可使用。所以GPT硬盘的分区表不可以直接使用16进制编辑器修改。
            分区表头的格式如下     
            起始字节 长度     内容
            0        8字节    签名("EFI PART", 45 46 49 20 50 41 52 54)
            8        4字节    修订(在1.0版中,值是 00 00 01 00)
            12       4字节    分区表头的大小(单位是字节,通常是92字节,即 5C 00 00 00)
            16       4字节    分区表头(第0-91字节)的CRC32 校验,在计算时,把这个字段作为0处理,需要计算出分区串行的CRC32校验后再计算本字段
            20       4字节    保留,必须是 0
            24       8字节    当前LBA(这个分区表头的位置)
            32       8字节    备份LBA(另一个分区表头的位置)
            40       8字节    第一个可用于分区的LBA(主分区表的最后一个LBA + 1)
            48       8字节    最后一个可用于分区的LBA(备份分区表的第一个LBA − 1)
            56       16字节   硬盘GUID(在类UNIX 系统中也叫UUID)
            72       8字节    分区表项的起始LBA(在主分区表中是2)
            80       4字节    分区表项的数量
            84       4字节    一个分区表项的大小(通常是128)
            88       4字节    分区串行的CRC32校验
            92       *        保留,剩余的字节必须是0(对于512字节LBA的硬盘即是420个字节)
            主分区表和备份分区表的头分别位于硬盘的第二个扇区(LBA 1)以及硬盘的最后一个扇区。备份分区表头中的信息是关于备份分区表的。
            分区表项 (LBA 2–33)
            GPT分区表使用简单而直接的方式表示分区。一个分区表项的前16字节是分区类型GUID。例如,EFI系统分区的GUID类型是{C12A7328-F81F-11D2-BA4B-00A0C93EC93B}。接下来的16字节是该分区唯一的GUID(这个GUID指的是该分区本身,而之前的GUID指的是该分区的类型)。再接下来是分区起始和末尾的64位LBA编号,以及分区的名字和属性。
            GPT分区表项的格式如下
            起始字节 长度      内容
            0        16字节    分区类型GUID
            16       16字节    分区GUID
            32       8字节     起始LBA(小端序 )
            40       8字节     末尾LBA
            48       8字节     属性标签(如:60 表示“只读”)
            56       72字节    分区名(可以包括36个UTF-16(小端序)字符)

    Legacy 和 UEFI
        BIOS 是Basic Input Output System的缩写,中文翻译为“基本输入输出系统”是固化在一个只读存储器(ROM)或非易失性存储器(NvRAM)上的程序。但你知道吗?随着现代新式电脑的出现,逐渐地开始用UEFI启动,尤其是在当下win10系统的逐渐普及,除此之外还有EFI启动方式,这是一种为早期的过渡电脑用的。
        那么什么是EFI、UEFI呢?与BIOS有什么关系及区别呢?EFI或UEFI的一部分也是存储在一个芯片中,由于它们在表面形式、基本功能上和BIOS差不多,所以习惯上我们也把存储EFI/UEFI的芯片叫做EFI/UEFI BIOS芯片,EFI/UEFI也叫做EFI/UEFI BIOS,但在实际上它们和BIOS根本是不一样的。具体他们是什么?下面和小编一起来了解一下BIOS、EFI和UEFI。
        一、BIOS
            上图,为早期时电脑的BIOS界面,不同的品牌电脑界面可能有很大的区别但功能上却有很多相同之处。
            IOS用于计算机硬件自检、CMOS设置、引导操作系统启动、提供硬件I/O、硬件中断等4项主要功能,因此BIOS程序可以分为若干模块,主要有Boot Block引导模块、CMOS设置模块、扩展配置数据(ESCD)模块、DMI收集硬件数据模块,其中引导模块直接负责执行BIOS程序本身入口、计算机基本硬件的检测和初始化,ESCD用于BIOS与OS交换硬件配置数据,DMI则充当了硬件管理工具和系统层之间接口的角色,通过DMI,用户可以直观地获得硬件的任何信息,CMOS设置模块就是实现对硬件信息进行设置,并保存在CMOS中,是除了启动初始化以外BIOS程序最常用的功能。
            IOS本身是汇编语言代码,是在16位实模式下调用INT 13H中断执行的,由于x86-64是一个高度兼容的指令集,也为了迁就BIOS的16位实模式的运行环境,所以即使现在的CPU都已是64位,如果还是在BIOS启动(基本见于09年以前的主板),,在开机时仍然都是在16位实模式下执行的。16位实模式直接能访问的内存只有1MB,就算你安了4G、8G或者16G还是32G内存,到了BIOS上一律只先认前1MB。在这1MB内存中,前640K称为基本内存,后面384K内存留给开机必要硬件和各类BIOS本身使用。
            虽然BIOS作为电脑加电启动所必不可少的部分,但是从其于1975年诞生之日起近30余年,16位汇编语言代码,1M内存寻址,调用中断一条条执行的理念和方式竟然一点都没有改变,虽然经各大主板商不懈努力,BIOS也有了ACPI、USB设备支持,PnP即插即用支持等新东西,但是这在根本上没有改变BIOS的本质,而英特尔为了迁就这些旧技术,不得不在一代又一代处理器中保留着16位实模式(否则根本无法开机的)。但是,英特尔在2001年开发了全新的安腾处理器,采用IA-64架构,并推出了全新的EFI。后来证明,安腾处理器、IA-64架构没有推广开来,而EFI和后继的UEFI却发扬光大,成为现在电脑的主要预启动环境。
        二、EFI
            EFI,是Extensible Firmware Interface的词头缩写,直译过来就是可扩展固件接口,它是用模块化、高级语言(主要是C语言)构建的一个小型化系统,它和BIOS一样,主要在启动过程中完成硬件初始化,但它是直接利用加载EFI驱动的方式,识别系统硬件并完成硬件初始化,彻底摒弃读各种中断执行。EFI驱动并不是直接面向CPU的代码,    而是由EFI字节码编写成,EFI字节码是专用于EFI的虚拟机器指令,需要在EFI驱动运行环境DXE下解释运行,这样EFI既可以实现通配,又提供了良好的兼容。此外,EFI完全是32位或64位,摒弃16位实模式,在EFI中就可以实现处理器的最大寻址,因此可以在任何内存地址存放任何信息。另外,由于EFI的驱动开发非常简单,基于EFI的驱动模型原则上可以使EFI接触到所有硬件功能,在EFI上实现文件读写,网络浏览都是完全可能的。i,BIOS上的的CMOS设置程序在EFI上是作为一个个EFI程序来执行的,硬件设置是硬件设置程序、而启动管理则是另一个程序,保存CMOS又是另一个程序,虽然它们在形式的Shell上是在一起的。
            EFI在功能上完全等同于一个轻量化的OS,但是EFI在制定时就定位到不足以成为专业OS的地位上,首先,它只是一个硬件和操作系统间的一个接口;其次,EFI不提供中断访问机制,EFI必须用轮询的方式检查并解释硬件,较OS下的驱动执行效率较低,最后,EFI只有简单的存储器管理机制,在段保护模式下只将存储器分段,所有程序都可以存取任何一段位置,不提供真实的保护服务。伴随着EFI,一种全新的GUID磁盘分区系统(GPT)被引入支持,传统MBR磁盘只能存在4个主分区,只有在创建主分区不足4个时,可以建立一个扩展分区,再在其上建立被系统识别的逻辑分区,逻辑分区也是有数量的,太多的逻辑分区会严重影响系统启动,MBR硬盘分区最大仅支持2T容量,对于现在的大容量硬盘来说也是浪费。GPT支持任意多的分区,每个分区大小原则上是无限制的,但实际上受到OS的规定限制不能做到无限,不过比MBR的2T限制是非常重要的进步。GPT的分区类型由GUID表唯一指定,基本不可能出现重复,其中的EFI系统分区可以被EFI存取,用来存取部分驱动和应用程序,虽然这原则上会使EFI系统分区变得不安全,但是一般这里放置的都是些“边缘”数据,即使其被破坏,一般也不会造成严重后果,而且也能够简单的恢复回来。
        三、UEFI
            当EFI发展到1.1的时候,英特尔决定把EFI公之于众,于是后续的2.0吸引了众多公司加入,EFI也不再属于英特尔,而是属于了Unified EFI Form的国际组织,EFI在2.0后也遂改称为UEFI,UEFI,其中的EFI和原来是一个意思,U则是Unified(一元化、统一)的缩写,所以UEFI的意思就是“统一的可扩展固件接口”,与前身EFI相比,UEFI主要有以下改进:
            首先,UEFI具有完整的图形驱动功能,之前的EFI虽然原则上加入了图形驱动,但为了保证EFI和BIOS的良好过渡,EFI多数还是一种类DOS界面(仍然是640*480VGA分辨率),只支持PS/2键盘操作(极少数支持鼠标操作),不支持USB键盘和鼠标。到了UEFI,则是拥有了完整的图形驱动,无论是PS/2还是USB键盘和鼠标,UEFI一律是支持的,而且UEFI在显卡也支持GOP VBIOS的时候,显示的设置界面是显卡高分辨率按640*480或1024*768显示,因此画面虽小但很清楚,但是这样会导致屏幕周围大片留黑,不过鱼和熊掌不可兼得,除非UEFI默认窗口大小也是最高分辨率。其次,UEFI具有一个独特的功能,安全启动,而EFI是没有安全启动的,安全启动(Secure Boot),实际上通俗的解释是叫做固件验证。开启UEFI的安全启动后,主板会根据TPM芯片(或者CPU内置的TPM)记录的硬件签名对各硬件判断,只有符合认证的硬件驱动才会被加载,而Win8以后的Windows则是在操作系统加载的过程中对硬件驱动继续查签名,符合Windows记录的硬件才能被Windows加载,这在一定程度上降低了启动型程序在操作系统启动前被预加载造成的风险,但是这也会造成系统安装变得垄断。
            无论EFI还是UEFI,都必须要有预加载环境、驱动执行环境、驱动程序等必要部分组成,为了支持部分旧设备(如在UEFI下挂载传统MBR硬盘,不支持UEFI启动的显卡在UEFI下仍然支持运行等),还需要一个CSM兼容性支持模块、EFI或UEFI都是仅支持GPT磁盘引导系统的。
            BIOS和UEFI在启动方式上也有很大的不同:BIOS先要对CPU初始化,然后跳转到BIOS启动处进行POST自检,此过程如有严重错误,则电脑会用不同的报警声音提醒,接下来采用读中断的方式加载各种硬件,完成硬件初始化后进入操作系统启动过程;而UEFI则是运行预加载环境先直接初始化CPU和内存,CPU和内存若有问题则直接黑屏,其后启动PXE采用枚举方式搜索各种硬件并加载驱动,完成硬件初始化,之后同样进入操作系统启动过程。
            BIOS是16位汇编语言程序,只能运行在16位实模式,可访问的内存只有1MB,而UEFI是32位或64位高级语言程序(C语言程序),突破实模式限制,可以达到要求的最大寻址。


  • 相关阅读:
    本地Grails配置与MyEclipse配置
    Linux下Apache James 邮件安装与发送程序
    MyEclipse8.6 安装groovy插件
    系统管理指南:基本管理 第21 章• 使用Sun PatchManager 管理Solaris 修补程序(任务)
    tar.bz2 解压命令。
    系统管理指南:基本管理 索引
    系统管理指南:基本管理 第22 章• 使用patchadd 命令管理Solaris 修补程序(任务)~附录A • SMF 服务
    如何安装gcc
    系统管理指南:基本管理 第20 章• 管理Solaris 修补程序和更新(概述)
    系统管理指南:基本管理 第18 章• 用Solaris 系统管理工具管理软件(任务)
  • 原文地址:https://www.cnblogs.com/guoqingpeng/p/14713925.html
Copyright © 2011-2022 走看看