Difference between revisions of "Arch boot process (简体中文)"

From ArchWiki
Jump to navigation Jump to search
(update interlanguage links)
Tag: wiki-scripts
 
(56 intermediate revisions by 16 users not shown)
Line 1: Line 1:
 
[[Category:Boot process (简体中文)]]
 
[[Category:Boot process (简体中文)]]
 
[[Category:About Arch (简体中文)]]
 
[[Category:About Arch (简体中文)]]
[[Category:简体中文]]
+
[[ar:Arch boot process]]
{{i18n|Arch Boot Process}}
+
[[bs:Arch boot process]]
 +
[[cs:Arch boot process]]
 +
[[en:Arch boot process]]
 +
[[es:Arch boot process]]
 +
[[fr:Processus de boot]]
 +
[[it:Arch boot process]]
 +
[[ja:Arch ブートプロセス]]
 +
[[pt:Arch boot process]]
 +
{{Related articles start (简体中文)}}
 +
{{Related|Boot loaders (简体中文)}}
 +
{{Related|Master Boot Record (简体中文)}}
 +
{{Related|GUID Partition Table (简体中文)}}
 +
{{Related|Unified Extensible Firmware Interface (简体中文)}}
 +
{{Related|mkinitcpio (简体中文)}}
 +
{{Related|init}}
 +
{{Related|systemd (简体中文)}}
 +
{{Related|fstab (简体中文)}}
 +
{{Related|Autostarting}}
 +
{{Related articles end}}
 +
{{TranslationStatus (简体中文)|Arch boot process|2017-09-01|477810}}
  
This article is intended to give a chronological overview of the Arch boot process and the system files and processes involved, providing links to relevant wiki articles where necessary. Arch famously follows the BSD init convention as opposed to the more common SysV. What this means is that there is little distinction between runlevels, since the system by default is configured to use the same modules and run the same processes on all runlevels. The advantage is that users have a simple way to configure the startup process (see [[rc.conf]]); the disadvantage is that some fine-grained configuration options that SysV offers are lost. See [[Adding Runlevels]] for a way to hack some SysV-like capabilities into Arch. See [[Wikipedia:init]] for more on the distinctions between SysV and BSD style.
+
为了启动 Arch Linux,一个与 Linux 兼容的 [[Boot loaders (简体中文)|启动引导器]],比如 [[GRUB (简体中文)|GRUB]] 或者 [[Syslinux (简体中文)|Syslinux]] 必须事先被安装到[[主引导记录]]或者 [[GUID Partition Table (简体中文)|GUID 分区表]]。启动引导程序负责在初始化启动进程之前,加载好内核和 [[mkinitcpio (简体中文)|initial ramdisk]]。具体过程因 [[Wikipedia:BIOS|BIOS]] 和 [[UEFI]] 系统而异,细节在正文中给出。
  
== init进程之前 ==
+
== 固件种类 ==
系统开机并且执行完[[Wikipedia:Power-on self-test|加电自检]]后,BIOS会根据自身设置选择最佳的启动媒介。把控制权传递给该媒介的主引导记录([[Master Boot Record]])部分。在GNU/Linux系统中,MBR里通常是像[[GRUB]]、[[LILO]]这样的引导器(bootloader)。引导器通常会给用户一个菜单或者命令行之类的机制,供用户选择和设置。例如[[Windows and Arch Dual Boot|双系统的设置]]。一旦你选择启动Arch时,引导器就会载入{{Filename|/boot}} 目录下的内核镜像(比如{{Filename|kernel26.img}}),并解压缩。
 
  
内核是一个操作系统的核心。他作用于非常底层的硬件和控制硬件的程序之间的部分(又称之为''内核空间'')。由于CPU在某个时刻只能执行一个任务,为了更为高效的使用CPU,内核使用称之为调度器的玩意。他通过一定的优先级算法,来将CPU按照时间动态的分配给各个人物。给我们的感觉就像所有程序都在使用CPU一样。
+
=== BIOS ===
  
在内核载入后,会去处理[[initramfs]](初始化RAM文件系统)。initramfs不一定是必须的,仅限于根文件系统所需的内核模块(比如IDE驱动)没有被编译到内核中时才需要(参考[[FHS]])。换句话说他只需要包含内核中没有,并且访问根文件系统所必须的模块。比如IDE、SCSI、SATA(如果从USB设备中启动的话,肯定还有USB/FW模块)这类驱动驱动。在initramfs载入了必要的模块后,他就会将控制权交回给内核,继续引导过程。因此,initrd无须包含其他的模块都包含,其他模块可以在随后的引导中会通过[[udev]]载入。
+
{{Expansion|需要增加关于 [[Wikipedia:Unified Extensible Firmware Interface#CSM booting|CSM]]的内容。}}
  
然后内核就会去找{{Codeline|init}}程序,通常就是根文件系统下的{{Filename|/sbin/init}}文件。{{Codeline|init}}的实现依赖于GNU C基础库{{Codeline|glibc}}。Libraries are collections of frequently used program routines and are readily identifiable through their filename extension of {{Filename|*.so}}. They are essential for basic system functionality. 这部分启动过程又称之为''early userspace''.
+
所谓 BIOS 或 Basic Input-Output System, 就是开机时第一个被执行的程序,又名固件。一般来说它储存在主板上的一块闪存中,与硬盘彼此独立。
  
== init: The Arch boot scripts ==
+
BIOS 被启动后,会按启动顺序加载磁盘的前 512 字节,即[[主引导记录]],前 440 字节包含某个启动引导器,像 [[GRUB (简体中文)|GRUB]] 、[[Syslinux (简体中文)|Syslinux]] 和 [[LILO]] 之类的第一启动阶段代码。因为空间太小了,后续的启动代码保存在磁盘上,最后启动引导器又通过「链式引导」,或是直接加载内核,以加载一个操作系统。
Arch主要的启动过程是由{{Codeline|init}}完成的,他通过克隆出其他的进程(以及这些进程克隆出的进程),使系统进入一个可用的状态。正如前文中提到的,Arch使用的是一种BSD风格的引导脚本。具体来说,{{Codeline|init}}程序会首先读取{{Filename|/etc/inittab}}这个配置文件,{{Filename|inittab}}通常像这样:
 
  
{{File
+
=== UEFI ===
|name=/etc/inittab
 
|content=<nowiki>
 
...
 
  
# Boot to console
+
UEFI 不仅能读取分区表,还能自动支持文件系统。所以它不像 BIOS,已经没有仅仅 440 字节可执行代码即 MBR 的限制了,它完全用不到 MBR。
id:3:initdefault:
 
# Boot to X11
 
#id:5:initdefault:
 
  
rc::sysinit:/etc/rc.sysinit
+
UEFI 主流都支持 MBR 和 GPT 分区表。Apple-Intel Macs 上的 EFI 还支持 Apple 专用分区表。绝大部分 UEFI 固件支持软盘上的 FAT12,硬盘上的 FAT16、FAT32 文件系统,以及 CD/DVDs 的 IS09660 和 UDF。Intel Macs 的 EFI 还额外支持 HFS/HFS+ 文件系统。
rs:S1:wait:/etc/rc.single
 
rm:2345:wait:/etc/rc.multi
 
rh:06:wait:/etc/rc.shutdown
 
su:S:wait:/sbin/sulogin
 
  
...
+
不管第一块上有没有 MBR,UEFI 都不会执行它。相反,它依赖分区表上的一个特殊分区,叫 EFI 系统分区,里面有 UEFI 所要用到的一些文件。计算机供应商可以在 {{ic|<EFI 系统分区>/EFI/<VENDOR NAME>/}} 文件夹里放官方指定的文件,还能用固件或它的 shell,即 UEFI shell,来启动引导程序。EFI 系统分区一般被格式化成 FAT32,或比较非主流的 FAT16。
</nowiki>}}
 
  
根据这个文件的第一个未被注释掉的行克制,系统默认的启动级别为3(启动器(bootloader)通常可以给内核传递系统的运行级别,如果没有传递,系统运行级别就采用这里的默认值),当内核调用init时:
+
== 系统初始化 ==
  
* 首先,运行主初始化脚本{{Filename|/etc/rc.sysinit}},这是个[[Bash]]脚本。
+
=== BIOS ===
* 如果系统处于单用户模式(运行级别为1或者S),系统就会接着运行{{Filename|/etc/rc.single}}脚本。否者,如果系统处于2~5之间的运行级别,系统就会接着运行{{Filename|/etc/rc.multi}}脚本。
 
* 最后运行的脚本是{{Filename|/etc/rc.local}},这个脚本默认什么都没有。
 
  
=== {{Filename|/etc/rc.sysinit}} ===
+
# 开机时[[Wikipedia:Power-on self-test|加电自检]]。
{{Filename|rc.sysinit}}是一个很大的启动脚本。他通过一系列的初始化人物,完成所有的硬件配置。当你看到屏幕打印出下面这些行时,代表他开始运行了:
+
# 加电自检后,BIOS 初始化一些必要的硬件以准备引导,比如硬盘和键盘等。
 +
# BIOS 执行在「BIOS 硬盘顺序」中的第一块硬盘上的前 440 字节代码,即[[主引导记录]]。
 +
# MBR 接管后,执行它之后的第二阶段代码,如果后者存在的话,它一般就是[[Boot loaders (简体中文)|启动引导器]]。
 +
# 第二阶段代码会读取它的支持文件和配置文件。
  
Arch Linux
+
=== UEFI ===
http://www.archlinux.org
 
Copyright 2002-2007 Judd Vinet
 
Copyright 2007-2010 Aaron Griffin
 
Distributed under the GNU General Public License (GPL)
 
  
我们可以来看看这个脚本的任务列表:
+
# 系统开机 - 上电自检(Power On Self Test 或 POST)。
* 导入{{Filename|/etc/rc.conf}}文件
+
# UEFI 固件被加载,并由它初始化启动要用的硬件。
* 导入{{Filename|/etc/rc.d/functions}}文件
+
# 固件读取其引导管理器以确定从何处(比如,从哪个硬盘及分区)加载哪个 UEFI 应用。
* 显示欢迎信息
+
# 固件按照引导管理器中的启动项目,加载UEFI 应用。
* 挂在各种各样的虚拟文件系统(proc、sysfs之类的)
+
# 已启动的 UEFI 应用还可以启动其他应用(对应于 UEFI shell 或 rEFInd 之类的引导管理器的情况)或者启动内核及initramfs(对应于GRUB之类引导器的情况),这取决于 UEFI 应用的配置。
* 创建dummy设备的设备文件
+
{{Note|在有些 UEFI 系统中,唯一可行的启动时(如果应用没有在 UEFI 启动菜单定制条目的话)加载 UEFI 应用的方法是把它放在此固定位置:{{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (对于 64 位的 x86 系统)}}
* 启动[[minilogd]]日志服务
 
* 从[[dmesg]]输出内核启动信息
 
* 配置硬件时钟
 
* 清空设备热拔插{{Filename|/proc/sys/kernel/hotplug}}文件
 
* 启动[[udev]]服务并检查udev事件
 
* 启动回环([[loopback]])接口
 
* 根据[[rc.conf]]文件中的{{Codeline|MODULES}}数组变量载入内核模块
 
* 配置RAID和加密文件系统映射
 
* 根据[[fstab|/etc/fstab]]的配置,运行[[fsck]]检查相应分区的完整性
 
* 挂载本地文件系统和交换分区,(由于网络未加载,网络设备不会挂载)
 
* 激活[[swap|交换分区]]
 
* 根据{{Filename|rc.conf}}中的配置,设置主机名、locale、系统时钟
 
* 移除leftover/temporary文件中的临时变量和文件,比如{{Filename|/tmp/*}}
 
* 配置[[Locale_(简体中文)|本地化]]、终端、键盘映射
 
* 设置终端字体
 
* 输出dmesg中输出的信息到{{Filename|/var/log/dmesg.log}}
 
  
{{Filename|/etc/rc.sysinit}}是一个脚本。他本身并不包含任何的配置信息,而是通过导入[[rc.conf]]来读取配置信息。就连他内部使用的很多实现彩色输出(比如右对齐的busy、done字符串)的函数,也是定义在{{Filename|/etc/rc.d/functions}}中。通常情况下不需要编辑这个文件。当然如果为了通过减少某些不必要的步骤加速启动,也可以试试这么干。
+
=== UEFI 的多重引导 ===
  
=== {{Filename|/etc/rc.single}} ===
+
因为每个操作系统或者提供者都可以维护自己的 EFI 系统分区中的文件,同时不影响其他系统,所以 UEFI 的多重启动只是简单的运行不同的UEFI 程序,对应于特定操作系统的引导程序。这避免了依赖 chainloading 机制(通过一个[[Boot loader|启动引导程序]]加载另一个引导程序,来切换操作系统)。
单用户(Single)模式通常在无法正常启动时使用,他会直接以root用户启动。除了最基本的syslog-ng和udev外,不会启动任何服务。单用户模式在修复系统时,需要避免远程用户操作导致数据丢失时很有用。单用户模式下可以直接在提示符后输入'exit'进入到多用户模式。
 
  
=== {{Filename|/etc/rc.multi}} ===
+
参阅 [[Dual boot with Windows]].
{{Filename|/etc/rc.multi}}通常在多用户模式(运行级别为2~5)下执行。通常情况,从{{Filename|rc.sysinit}}切换到{{Filename|rc.multi}}时,用户不太能感觉到。因为两者使用的函数类似,导致输出的提示信息也差不多。这个脚本主要执行以下任务:
 
  
* 首先,会根据{{Filename|/etc/sysctl.conf}}的设置,运行sysctl以在运行时修改内核参数,Arch除了网络配置外,通常很少用这么干。
+
== 启动加载器 ==
* 然后,会根据{{Filename|rc.conf}}文件中的{{Codeline|DAEMONS}}变量,执行非常重要的——[[daemons|服务(守护进程)]]启动任务。
 
* 最后,会执行{{Filename|/etc/rc.local}}脚本
 
  
=== {{Filename|/etc/rc.local}} ===
+
{{Expansion|需要补充解释启动加载器和启动管理器之间的区别|Talk:Arch boot process#Boot loader vs boot manager}}
{{Filename|rc.local}}是多用户启动脚本下的本地化(个性化)脚本,默认是空的。通常情况下可以将一些需要在启动过程最后执行的命令放在这个脚本里。 Most common system configuration tasks (like loading modules, changing
 
the console font, or setting up devices) usually have a dedicated place where they belong. To avoid confusion, ensure that whatever one intends to add to {{Filename|rc.local}} is not already residing in {{Filename|/etc/profile.d}}, or any other existing configuration location instead.
 
  
在修改这个文件时切记,该脚本(及其内部的所有命令)在模块载入和守护进程'''之后'''以root用户的权限运行。并且'''不管'''是否启动图形环境X都会执行。下面是一个在该脚本中调整ALSA声音设置例子
+
启动加载器是 [[Wikipedia:BIOS|BIOS]] 或 [[UEFI]] 启动的第一个程序。它负责使用正确的[[kernel parameters|内核参数]]加载内核, 并根据配置文件加载[[mkinitcpio|初始化 RAM disk]]。
  
{{File
 
|name=/etc/rc.local
 
|content=<nowiki>
 
#!/bin/bash
 
  
# /etc/rc.local: Local multi-user startup script.
+
{{Note|加载 [[Microcode]] 补丁要求对启动加载器的配置进行调整。[https://www.archlinux.org/news/changes-to-intel-microcodeupdates/]}}
  
amixer sset 'Master Mono' 50% unmute &> /dev/null
+
=== 功能比较 ===
amixer sset 'Master' 50% unmute &> /dev/null
 
amixer sset 'PCM' 75% unmute &> /dev/null
 
</nowiki>}}
 
  
另外一个{{Filename|rc.local}}的用途,就是实现一些特殊的修改。
+
{{Note|
 +
* 只需要启动加载器兼容内核和initramfs所处的位置({{ic|/boot}})的文件系统兼容即可。
 +
* 因为GPT是UEFI规范的一部分,所以所有的UEFI启动加载器都支持GPT磁盘。在BIOS上使用GPT磁盘是可行的,要么根据[https://www.rodsbooks.com/gdisk/hybrid.html Hybrid MBR]使用 "hybrid booting",要么使用新的 [http://repo.or.cz/syslinux.git/blob/HEAD:/doc/gpt.txt GPT-only] 协议。但是这个协议可能在某些BIOS实现上出问题,参考 [http://www.rodsbooks.com/gdisk/bios.html#bios rodsbooks]。
 +
* 在文件系统支持中提到的“加密”是[[wikipedia:Filesystem-level encryption|filesystem级别加密]],和[[dm-crypt|block级别加密]]没有任何关系。
 +
}}
  
== init: 登录 ==
+
{| class="wikitable sortable"
默认情况下,Arch启动过程完成后,{{Codeline|agetty}}程序就会启动,并提示用户输入用户名。在输入用户名后{{Codeline|agetty}}调用{{Codeline|login}},提示用户输入登录密码。
+
! rowspan="2"| Name
 +
! colspan="2"| Firmware
 +
! colspan="2"| [[Partition table]]
 +
! rowspan="2"| Multi-boot
 +
! colspan="5"| [[File systems]]
 +
! rowspan="2"| Notes
 +
|-
 +
! BIOS !! [[UEFI]]
 +
! [[MBR]] !! [[GPT]]
 +
! [[Btrfs]] !! [[ext4]] !! ReiserFS !! [[VFAT]] !! [[XFS]]
 +
|-
 +
! [[EFISTUB]]
 +
| {{-}} || {{Yes}}
 +
| {{Yes}} || {{Yes}}
 +
| {{-}}
 +
| {{-}} || {{-}} || {{-}} || {{Y|ESP only}} || {{-}}
 +
| 内核会变成一个 EFI executable 来被 [[UEFI]] 固件或者其他启动加载器加载。
 +
|-
 +
! [[Clover]]
 +
| {{G|模拟 UEFI}} || {{Yes}}
 +
| {{Yes}} || {{Yes}}
 +
| {{Yes}}
 +
| {{No}} || {{Y|不支持加密}} || {{No}} || {{Yes}} || {{No}}
 +
| 修改版的 rEFIt,用来运行[[wikipedia:Hackintosh|黑苹果]]。
 +
|-
 +
! [[GRUB]]
 +
| {{Yes}} || {{Yes}}
 +
| {{Yes}} || {{Yes}}
 +
| {{Yes}}
 +
| {{Y|不支持 zstd 压缩}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
 +
| 在 BIOS/GPT 配置下需要一个 [[BIOS boot partition|BIOS启动分区]]。<br/>支持RAID, LUKS1 和 LVM (但是不支持thin provisioned volumes)。
 +
|-
 +
! [[rEFInd]]
 +
| {{No}} || {{Yes}}
 +
| {{Yes}} || {{Yes}}
 +
| {{Yes}}
 +
| {{Y|不支持加密和 zstd 压缩}} || {{Y|不支持加密}} || {{Y|不支持 tail-packing 功能}} || {{Yes}} || {{No}}
 +
| 支持自动寻找内核和确定内核参数而不需要手动配置。
 +
|-
 +
! [[Syslinux]]
 +
| {{Yes}} || {{Y|[[Syslinux#Limitations of UEFI Syslinux|有限支持]]}}
 +
| {{Yes}} || {{Yes}}
 +
| {{Y|[[Syslinux#Chainloading|有限支持]]}}
 +
| {{Y|不支持: 跨设备卷、压缩、加密}} || {{Y|不支持加密}} || {{No}} || {{Yes}} || {{Y|仅限MBR;不支持 sparse inodes}}
 +
| 不支持某些 [[File systems (简体中文)|文件系统]] 功能 [https://wiki.syslinux.org/wiki/index.php?title=Filesystem] <br/>启动加载器只能够访问它所处的文件系统。[https://bugzilla.syslinux.org/show_bug.cgi?id=33]
 +
|-
 +
! [[systemd-boot]]
 +
| {{No}} || {{Yes}}
 +
| {{Y|[https://github.com/systemd/systemd/issues/1125 仅限手动安装]}} || {{Yes}}
 +
| {{Yes}}
 +
| {{No}} || {{No}} || {{No}} || {{Y|ESP only}} || {{No}}
 +
| [[ESP]]以外的分区上的binaries它都启动不了.
 +
|-
 +
! {{Grey|[[GRUB Legacy]]}}
 +
| {{Yes}} || {{No}}
 +
| {{Yes}} || {{No}}
 +
| {{Yes}}
 +
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Y|v4 only}}
 +
| [https://www.gnu.org/software/grub/grub-legacy.html 停止开发] in favor of [[GRUB]].
 +
|-
 +
! {{Grey|[[LILO]]}}
 +
| {{Yes}} || {{No}}
 +
| {{Yes}} || {{No}}
 +
| {{Yes}}
 +
| {{No}} || {{Y|不支持加密}} || {{Yes}} || {{Yes}} || {{Yes|http://xfs.org/index.php/XFS_FAQ#Q:_Does_LILO_work_with_XFS.3F}}
 +
| [http://web.archive.org/web/20180323163248/http://lilo.alioth.debian.org/ 停止开发] 因为某些局限性 (e.g. with Btrfs, GPT, RAID).
 +
|}
  
最后,再成功登录后{{Codeline|login}}会启动用户的默认会话终端(shell)。默认终端和环境变量在{{Filename|/etc/profile}}下定义。还有一些别的配置在{{Filename|/etc}}目录下的文件中定义。用户也可以在自己的家目录下通过{{Filename|~/.bashrc}}这类的文件重新定义。如果两部分的定义冲突,那么将会优先采用主目录下的定义。
+
See also [[Wikipedia:Comparison of boot loaders]].
  
[[Automatic login to virtual console|mingetty]]提供了一些选项,可以实现自动登录的功能。[[rungetty]]也提供了一些用户登陆时自动运行程序的功能。
+
== 内核 ==
  
大多数用户可能希望启动[[X|图形界面]],这个时候可以安装一个KDM、GDM之类的显示管理器(参考[[Display Manager_(简体中文)|显示管理器]])。 当然你如果觉得不需要或者不喜欢用显示挂你器,也可以[[Start X at Boot_(简体中文)|直接启动图形界面]]。
+
内核是操作系统的核心。它运行于一个叫「内核空间」的底层上,负责机器硬件和应用程序之间的交流。为了尽可能充分地压榨 CPU 性能,内核使用调度器,通过一定的优先级算法将 CPU 按照时间动态的分配给各个程序。让我们感觉就像所有程序都在同时使用 CPU 一样。
  
== 参考 ==
+
== initramfs ==
  
* [[Startup files]]
+
内核被加载后,它就会解压 [[mkinitcpio (简体中文)]], 又名 initial RAM filesystem, 后者会伪装成一个已初始化的根文件系统。内核接着会执行 {{ic|/init}} 作为第一条进程。传说中的「用户空间」就这么被启动了。
  
== 扩展资源 ==
+
initramfs 之所以存在,是为了帮系统访问真正的根文件系统(参见 [[Arch filesystem hierarchy (简体中文)]])。也就是说,那些硬件 IDE, SCSI, SATA, USB/FW 所要求的内核模块,如果并没有内置在内核里,就会被 initramfs 负责加载。一旦通过 [[udev (简体中文)]] 之类的程序或脚本加载好模块,启动流程才会继续下去。所以,initramfs 只要有能够让系统访问真实根文件系统的模块就可以了,不用尽可能地包含一切模块。当然,其它真正有用的模块之后会在 init 流程中被 udev 加载好。
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ 通过Grub启动到单用户模式]
+
 
* [http://www.linuxjournal.com/article/4622 通过GRUB引导Linux]
+
== Init 流程 ==
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Linux驱动过程探究]
+
 
* [http://linux.about.com/library/cmd/blcmdl5_sysctl.conf.htm Linux / Unix命令之sysctl.conf详解]
+
在「早期用户空间」的最终环节里,'''真正'''的根文件系统被挂载好后,就会替换掉原来的'''伪'''根文件系统。接着 {{ic|/sbin/init}} 被执行,同样也替换掉原来的 {{ic|/init}} 进程。Arch 御用的 [[init]] 就是 [[systemd (简体中文)]].
* [http://bbs.archlinux.org/search.php?action=search&keywords=rc.local&search_in=topic&sort_dir=DESC&show_as=topics 论坛中的rc.local范例]
+
 
* [[Wikipedia:Linux startup process|维基百科中的启动过程解析]]
+
== Getty ==
 +
 
 +
[[init]] 为每一个 [[Wikipedia:Virtual console|虚拟终端]] 调用 [[getty]],前者一般有六个,每个虚拟终端都会初始化 tty 并请求输入用户名和密码。当在某虚拟终端输入用户名和密码后,其 getty 会通过 {{ic|/etc/passwd}} 检查是否正确,如果正确,就接着调用 [[#Login|login]], 此外 getty 也可能会改启动一个显示管理器。
 +
 
 +
== 显示管理器 ==
 +
 
 +
[[display manager (简体中文)|显示管理器]], 可以配置为代替原来的 getty 登录命令行提示符。
 +
 
 +
== Login ==
 +
 
 +
所谓的 ''login'' 程序会为用户启动一个设置了环境变量的「会话」,接着根据 {{ic|/etc/passwd}} 配置以启动用户专用 shell.
 +
 +
=== 每日信息 ===
 +
 
 +
''login'' 程序会在成功登录后显示 [[Wikipedia:motd (Unix)|/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) 的内容,可以显示服务协议或希望告诉用户的信息。
 +
 
 +
== Shell ==
 +
 
 +
一旦用户专用的 [[shell]] 启动了,它会在显示命令行提示符前,执行一个「有可执行性的配置文件」,比如 [[.bashrc]]. 如果用户有设定了 [[Start X at login]], 原来那个「有可执行性的配置文件」会调用 [[startx]] or [[xinit]].
 +
 
 +
== xinit ==
 +
 
 +
[[xinit]] 也会调用用户的 [[.xinitrc]]这个「有可执行性的配置文件」,后者一般用来启动一个 [[window manager (简体中文)|窗口管理器]]。如果用户退出了窗口管理器,xinit, startx, shell login 就会先后中断,返回到 getty.
 +
 
 +
== 参见 ==
 +
* [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]
 +
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]
 +
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]
 +
* [[Wikipedia:Linux startup process]]
 
* [[Wikipedia:initrd]]
 
* [[Wikipedia:initrd]]
 +
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]
 +
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]

Latest revision as of 17:54, 9 October 2019

翻译状态: 本文是英文页面 Arch boot process翻译,最后翻译时间:2017-09-01,点击这里可以查看翻译后英文页面的改动。

为了启动 Arch Linux,一个与 Linux 兼容的 启动引导器,比如 GRUB 或者 Syslinux 必须事先被安装到主引导记录或者 GUID 分区表。启动引导程序负责在初始化启动进程之前,加载好内核和 initial ramdisk。具体过程因 BIOSUEFI 系统而异,细节在正文中给出。

固件种类

BIOS

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: 需要增加关于 CSM的内容。 (Discuss in Talk:Arch boot process (简体中文)#)

所谓 BIOS 或 Basic Input-Output System, 就是开机时第一个被执行的程序,又名固件。一般来说它储存在主板上的一块闪存中,与硬盘彼此独立。

BIOS 被启动后,会按启动顺序加载磁盘的前 512 字节,即主引导记录,前 440 字节包含某个启动引导器,像 GRUBSyslinuxLILO 之类的第一启动阶段代码。因为空间太小了,后续的启动代码保存在磁盘上,最后启动引导器又通过「链式引导」,或是直接加载内核,以加载一个操作系统。

UEFI

UEFI 不仅能读取分区表,还能自动支持文件系统。所以它不像 BIOS,已经没有仅仅 440 字节可执行代码即 MBR 的限制了,它完全用不到 MBR。

UEFI 主流都支持 MBR 和 GPT 分区表。Apple-Intel Macs 上的 EFI 还支持 Apple 专用分区表。绝大部分 UEFI 固件支持软盘上的 FAT12,硬盘上的 FAT16、FAT32 文件系统,以及 CD/DVDs 的 IS09660 和 UDF。Intel Macs 的 EFI 还额外支持 HFS/HFS+ 文件系统。

不管第一块上有没有 MBR,UEFI 都不会执行它。相反,它依赖分区表上的一个特殊分区,叫 EFI 系统分区,里面有 UEFI 所要用到的一些文件。计算机供应商可以在 <EFI 系统分区>/EFI/<VENDOR NAME>/ 文件夹里放官方指定的文件,还能用固件或它的 shell,即 UEFI shell,来启动引导程序。EFI 系统分区一般被格式化成 FAT32,或比较非主流的 FAT16。

系统初始化

BIOS

  1. 开机时加电自检
  2. 加电自检后,BIOS 初始化一些必要的硬件以准备引导,比如硬盘和键盘等。
  3. BIOS 执行在「BIOS 硬盘顺序」中的第一块硬盘上的前 440 字节代码,即主引导记录
  4. MBR 接管后,执行它之后的第二阶段代码,如果后者存在的话,它一般就是启动引导器
  5. 第二阶段代码会读取它的支持文件和配置文件。

UEFI

  1. 系统开机 - 上电自检(Power On Self Test 或 POST)。
  2. UEFI 固件被加载,并由它初始化启动要用的硬件。
  3. 固件读取其引导管理器以确定从何处(比如,从哪个硬盘及分区)加载哪个 UEFI 应用。
  4. 固件按照引导管理器中的启动项目,加载UEFI 应用。
  5. 已启动的 UEFI 应用还可以启动其他应用(对应于 UEFI shell 或 rEFInd 之类的引导管理器的情况)或者启动内核及initramfs(对应于GRUB之类引导器的情况),这取决于 UEFI 应用的配置。
Note: 在有些 UEFI 系统中,唯一可行的启动时(如果应用没有在 UEFI 启动菜单定制条目的话)加载 UEFI 应用的方法是把它放在此固定位置:<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi (对于 64 位的 x86 系统)

UEFI 的多重引导

因为每个操作系统或者提供者都可以维护自己的 EFI 系统分区中的文件,同时不影响其他系统,所以 UEFI 的多重启动只是简单的运行不同的UEFI 程序,对应于特定操作系统的引导程序。这避免了依赖 chainloading 机制(通过一个启动引导程序加载另一个引导程序,来切换操作系统)。

参阅 Dual boot with Windows.

启动加载器

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: 需要补充解释启动加载器和启动管理器之间的区别 (Discuss in Talk:Arch boot process#Boot loader vs boot manager)

启动加载器是 BIOSUEFI 启动的第一个程序。它负责使用正确的内核参数加载内核, 并根据配置文件加载初始化 RAM disk


Note: 加载 Microcode 补丁要求对启动加载器的配置进行调整。[1]

功能比较

Note:
  • 只需要启动加载器兼容内核和initramfs所处的位置(/boot)的文件系统兼容即可。
  • 因为GPT是UEFI规范的一部分,所以所有的UEFI启动加载器都支持GPT磁盘。在BIOS上使用GPT磁盘是可行的,要么根据Hybrid MBR使用 "hybrid booting",要么使用新的 GPT-only 协议。但是这个协议可能在某些BIOS实现上出问题,参考 rodsbooks
  • 在文件系统支持中提到的“加密”是filesystem级别加密,和block级别加密没有任何关系。
Name Firmware Partition table Multi-boot File systems Notes
BIOS UEFI MBR GPT Btrfs ext4 ReiserFS VFAT XFS
EFISTUB Yes Yes Yes ESP only 内核会变成一个 EFI executable 来被 UEFI 固件或者其他启动加载器加载。
Clover 模拟 UEFI Yes Yes Yes Yes No 不支持加密 No Yes No 修改版的 rEFIt,用来运行黑苹果
GRUB Yes Yes Yes Yes Yes 不支持 zstd 压缩 Yes Yes Yes Yes 在 BIOS/GPT 配置下需要一个 BIOS启动分区
支持RAID, LUKS1 和 LVM (但是不支持thin provisioned volumes)。
rEFInd No Yes Yes Yes Yes 不支持加密和 zstd 压缩 不支持加密 不支持 tail-packing 功能 Yes No 支持自动寻找内核和确定内核参数而不需要手动配置。
Syslinux Yes 有限支持 Yes Yes 有限支持 不支持: 跨设备卷、压缩、加密 不支持加密 No Yes 仅限MBR;不支持 sparse inodes 不支持某些 文件系统 功能 [2]
启动加载器只能够访问它所处的文件系统。[3]
systemd-boot No Yes 仅限手动安装 Yes Yes No No No ESP only No ESP以外的分区上的binaries它都启动不了.
GRUB Legacy Yes No Yes No Yes No No Yes Yes v4 only 停止开发 in favor of GRUB.
LILO Yes No Yes No Yes No 不支持加密 Yes Yes Yes 停止开发 因为某些局限性 (e.g. with Btrfs, GPT, RAID).

See also Wikipedia:Comparison of boot loaders.

内核

内核是操作系统的核心。它运行于一个叫「内核空间」的底层上,负责机器硬件和应用程序之间的交流。为了尽可能充分地压榨 CPU 性能,内核使用调度器,通过一定的优先级算法将 CPU 按照时间动态的分配给各个程序。让我们感觉就像所有程序都在同时使用 CPU 一样。

initramfs

内核被加载后,它就会解压 mkinitcpio (简体中文), 又名 initial RAM filesystem, 后者会伪装成一个已初始化的根文件系统。内核接着会执行 /init 作为第一条进程。传说中的「用户空间」就这么被启动了。

initramfs 之所以存在,是为了帮系统访问真正的根文件系统(参见 Arch filesystem hierarchy (简体中文))。也就是说,那些硬件 IDE, SCSI, SATA, USB/FW 所要求的内核模块,如果并没有内置在内核里,就会被 initramfs 负责加载。一旦通过 udev (简体中文) 之类的程序或脚本加载好模块,启动流程才会继续下去。所以,initramfs 只要有能够让系统访问真实根文件系统的模块就可以了,不用尽可能地包含一切模块。当然,其它真正有用的模块之后会在 init 流程中被 udev 加载好。

Init 流程

在「早期用户空间」的最终环节里,真正的根文件系统被挂载好后,就会替换掉原来的根文件系统。接着 /sbin/init 被执行,同样也替换掉原来的 /init 进程。Arch 御用的 init 就是 systemd (简体中文).

Getty

init 为每一个 虚拟终端 调用 getty,前者一般有六个,每个虚拟终端都会初始化 tty 并请求输入用户名和密码。当在某虚拟终端输入用户名和密码后,其 getty 会通过 /etc/passwd 检查是否正确,如果正确,就接着调用 login, 此外 getty 也可能会改启动一个显示管理器。

显示管理器

显示管理器, 可以配置为代替原来的 getty 登录命令行提示符。

Login

所谓的 login 程序会为用户启动一个设置了环境变量的「会话」,接着根据 /etc/passwd 配置以启动用户专用 shell.

每日信息

login 程序会在成功登录后显示 /etc/motd (message of the day) 的内容,可以显示服务协议或希望告诉用户的信息。

Shell

一旦用户专用的 shell 启动了,它会在显示命令行提示符前,执行一个「有可执行性的配置文件」,比如 .bashrc. 如果用户有设定了 Start X at login, 原来那个「有可执行性的配置文件」会调用 startx or xinit.

xinit

xinit 也会调用用户的 .xinitrc这个「有可执行性的配置文件」,后者一般用来启动一个 窗口管理器。如果用户退出了窗口管理器,xinit, startx, shell login 就会先后中断,返回到 getty.

参见