理解運(yùn)轉(zhuǎn)良好的系統(tǒng)對(duì)于處理不可避免的故障是最好的準(zhǔn)備。

關(guān)于開源軟件最古老的笑話是：“代碼是自具文檔化的self-documenting”。經(jīng)驗(yàn)表明，閱讀源代碼就像聽天氣預(yù)報(bào)一樣：明智的人依然出門會(huì)看看室外的天氣。本文講述了如何運(yùn)用調(diào)試工具來觀察和分析 Linux 系統(tǒng)的啟動(dòng)。分析一個(gè)功能正常的系統(tǒng)啟動(dòng)過程，有助于用戶和開發(fā)人員應(yīng)對(duì)不可避免的故障。

從某些方面看，啟動(dòng)過程非常簡(jiǎn)單。內(nèi)核在單核上以單線程和同步狀態(tài)啟動(dòng)，似乎可以理解。但內(nèi)核本身是如何啟動(dòng)的呢?initrd(initial ramdisk) 和引導(dǎo)程序bootloader具有哪些功能?還有，為什么以太網(wǎng)端口上的 LED 燈是常亮的呢?

請(qǐng)繼續(xù)閱讀尋找答案。在 GitHub 上也提供了 介紹演示和練習(xí)的代碼。

啟動(dòng)的開始：OFF 狀態(tài)

局域網(wǎng)喚醒Wake-on-LAN

OFF 狀態(tài)表示系統(tǒng)沒有上電，沒錯(cuò)吧?表面簡(jiǎn)單，其實(shí)不然。例如，如果系統(tǒng)啟用了局域網(wǎng)喚醒機(jī)制(WOL)，以太網(wǎng)指示燈將亮起。通過以下命令來檢查是否是這種情況：

# sudo ethtool

其中 是網(wǎng)絡(luò)接口的名字，比如 eth0。(ethtool 可以在同名的 Linux 軟件包中找到。)如果輸出中的 Wake-on 顯示 g，則遠(yuǎn)程主機(jī)可以通過發(fā)送 魔法數(shù)據(jù)包MagicPacket 來啟動(dòng)系統(tǒng)。如果您無意遠(yuǎn)程喚醒系統(tǒng)，也不希望其他人這樣做，請(qǐng)?jiān)谙到y(tǒng) BIOS 菜單中將 WOL 關(guān)閉，或者用以下方式：

# sudo ethtool -s wol d

響應(yīng)魔法數(shù)據(jù)包的處理器可能是網(wǎng)絡(luò)接口的一部分，也可能是 底板管理控制器Baseboard Management Controller(BMC)。

英特爾管理引擎、平臺(tái)控制器單元和 Minix

BMC 不是唯一的在系統(tǒng)關(guān)閉時(shí)仍在監(jiān)聽的微控制器(MCU)。x86_64 系統(tǒng)還包含了用于遠(yuǎn)程管理系統(tǒng)的英特爾管理引擎(IME)軟件套件。從服務(wù)器到筆記本電腦，各種各樣的設(shè)備都包含了這項(xiàng)技術(shù)，它開啟了如 KVM 遠(yuǎn)程控制和英特爾功能許可服務(wù)等 功能。根據(jù) Intel 自己的檢測(cè)工具，IME 存在尚未修補(bǔ)的漏洞。壞消息是，要禁用 IME 很難。Trammell Hudson 發(fā)起了一個(gè) me_cleaner 項(xiàng)目，它可以清除一些相對(duì)惡劣的 IME 組件，比如嵌入式 Web 服務(wù)器，但也可能會(huì)影響運(yùn)行它的系統(tǒng)。

IME 固件和系統(tǒng)管理模式System Management Mode(SMM)軟件是 基于 Minix 操作系統(tǒng) 的，并運(yùn)行在單獨(dú)的平臺(tái)控制器單元Platform Controller Hub上(LCTT 譯注：即南橋芯片)，而不是主 CPU 上。然后，SMM 啟動(dòng)位于主處理器上的通用可擴(kuò)展固件接口Universal Extensible Firmware Interface(UEFI)軟件，相關(guān)內(nèi)容 已被提及多次。Google 的 Coreboot 小組已經(jīng)啟動(dòng)了一個(gè)雄心勃勃的 非擴(kuò)展性縮減版固件Non-Extensible Reduced Firmware(NERF)項(xiàng)目，其目的不僅是要取代 UEFI，還要取代早期的 Linux 用戶空間組件，如 systemd。在我們等待這些新成果的同時(shí)，Linux 用戶現(xiàn)在就可以從 Purism、System76 或 Dell 等處購(gòu)買 禁用了 IME 的筆記本電腦，另外 帶有 ARM 64 位處理器筆記本電腦 還是值得期待的。

引導(dǎo)程序

除了啟動(dòng)那些問題不斷的間諜軟件外，早期引導(dǎo)固件還有什么功能呢?引導(dǎo)程序的作用是為新上電的處理器提供通用操作系統(tǒng)(如 Linux)所需的資源。在開機(jī)時(shí)，不但沒有虛擬內(nèi)存，在控制器啟動(dòng)之前連 DRAM 也沒有。然后，引導(dǎo)程序打開電源，并掃描總線和接口，以定位內(nèi)核鏡像和根文件系統(tǒng)的位置。U-Boot 和 GRUB 等常見的引導(dǎo)程序支持 USB、PCI 和 NFS 等接口，以及更多的嵌入式專用設(shè)備，如 NOR 閃存和 NAND 閃存。引導(dǎo)程序還與 可信平臺(tái)模塊Trusted Platform Module(TPM)等硬件安全設(shè)備進(jìn)行交互，在啟動(dòng)最開始建立信任鏈。

在構(gòu)建主機(jī)上的沙盒中運(yùn)行 U-boot 引導(dǎo)程序。

包括樹莓派、任天堂設(shè)備、汽車主板和 Chromebook 在內(nèi)的系統(tǒng)都支持廣泛使用的開源引導(dǎo)程序 U-Boot。它沒有系統(tǒng)日志，當(dāng)發(fā)生問題時(shí)，甚至沒有任何控制臺(tái)輸出。為了便于調(diào)試，U-Boot 團(tuán)隊(duì)提供了一個(gè)沙盒，可以在構(gòu)建主機(jī)甚至是夜間的持續(xù)集成(CI)系統(tǒng)上測(cè)試補(bǔ)丁程序。如果系統(tǒng)上安裝了 Git 和 GNU Compiler Collection(GCC)等通用的開發(fā)工具，使用 U-Boot 沙盒會(huì)相對(duì)簡(jiǎn)單：

# git clone git://git.denx.de/u-boot; cd u-boot

# make ARCH=sandbox defconfig

# make; ./u-boot

=> printenv

=> help

在 x86_64 上運(yùn)行 U-Boot，可以測(cè)試一些棘手的功能，如 模擬存儲(chǔ)設(shè)備 的重新分區(qū)、基于 TPM 的密鑰操作以及 USB 設(shè)備熱插拔等。U-Boot 沙盒甚至可以在 GDB 調(diào)試器下單步執(zhí)行。使用沙盒進(jìn)行開發(fā)的速度比將引導(dǎo)程序刷新到電路板上的測(cè)試快 10 倍，并且可以使用 Ctrl + C 恢復(fù)一個(gè)“變磚”的沙盒。

啟動(dòng)內(nèi)核

配置引導(dǎo)內(nèi)核

引導(dǎo)程序完成任務(wù)后將跳轉(zhuǎn)到已加載到主內(nèi)存中的內(nèi)核代碼，并開始執(zhí)行，傳遞用戶指定的任何命令行選項(xiàng)。內(nèi)核是什么樣的程序呢?用命令 file /boot/vmlinuz 可以看到它是一個(gè) “bzImage”，意思是一個(gè)大的壓縮的鏡像。Linux 源代碼樹包含了一個(gè)可以解壓縮這個(gè)文件的工具—— extract-vmlinux：

# scripts/extract-vmlinux /boot/vmlinuz-$(uname -r) > vmlinux

# file vmlinux

vmlinux: ELF64-bit LSB executable,x86-64,version1(SYSV),statically

linked,stripped

內(nèi)核是一個(gè) 可執(zhí)行與可鏈接格式 Executable and Linking Format(ELF)的二進(jìn)制文件，就像 Linux 的用戶空間程序一樣。這意味著我們可以使用 binutils 包中的命令，如 readelf 來檢查它。比較一下輸出，例如：

# readelf -S /bin/date

# readelf -S vmlinux

這兩個(gè)二進(jìn)制文件中的段內(nèi)容大致相同。

所以內(nèi)核必須像其他的 Linux ELF 文件一樣啟動(dòng)，但用戶空間程序是如何啟動(dòng)的呢?在 main() 函數(shù)中?并不確切。

在 main() 函數(shù)運(yùn)行之前，程序需要一個(gè)執(zhí)行上下文，包括堆棧內(nèi)存以及 stdio、stdout 和 stderr 的文件描述符。用戶空間程序從標(biāo)準(zhǔn)庫(kù)(多數(shù) Linux 系統(tǒng)在用 “glibc”)中獲取這些資源。參照以下輸出：[!--empirenews.page--]

# file /bin/date

/bin/date: ELF64-bit LSB shared object,x86-64,version1(SYSV),dynamically

linked,interpreter /lib64/ld-linux-x86-64.so.2,forGNU/Linux2.6.32,

BuildID[sha1]=14e8563676febeb06d701dbee35d225c5a8e565a,

stripped

ELF 二進(jìn)制文件有一個(gè)解釋器，就像 Bash 和 Python 腳本一樣，但是解釋器不需要像腳本那樣用 #! 指定，因?yàn)?ELF 是 Linux 的原生格式。ELF 解釋器通過調(diào)用 _start() 函數(shù)來用所需資源 配置一個(gè)二進(jìn)制文件，這個(gè)函數(shù)可以從 glibc 源代碼包中找到，可以 用 GDB 查看。內(nèi)核顯然沒有解釋器，必須自我配置，這是怎么做到的呢?

用 GDB 檢查內(nèi)核的啟動(dòng)給出了答案。首先安裝內(nèi)核的調(diào)試軟件包，內(nèi)核中包含一個(gè)未剝離的unstripped vmlinux，例如 apt-get install linux-image-amd64-dbg，或者從源代碼編譯和安裝你自己的內(nèi)核，可以參照 Debian Kernel Handbook 中的指令。gdb vmlinux 后加 info files 可顯示 ELF 段 init.text。在 init.text 中用 l *(address) 列出程序執(zhí)行的開頭，其中 address 是 init.text 的十六進(jìn)制開頭。用 GDB 可以看到 x86_64 內(nèi)核從內(nèi)核文件 arch/x86/kernel/head_64.S 開始啟動(dòng)，在這個(gè)文件中我們找到了匯編函數(shù) start_cpu0()，以及一段明確的代碼顯示在調(diào)用 x86_64 start_kernel() 函數(shù)之前創(chuàng)建了堆棧并解壓了 zImage。ARM 32 位內(nèi)核也有類似的文件 arch/arm/kernel/head.S。start_kernel() 不針對(duì)特定的體系結(jié)構(gòu)，所以這個(gè)函數(shù)駐留在內(nèi)核的 init/main.c 中。start_kernel() 可以說是 Linux 真正的 main() 函數(shù)。

從 start_kernel() 到 PID 1

內(nèi)核的硬件清單：設(shè)備樹和 ACPI 表

在引導(dǎo)時(shí)，內(nèi)核需要硬件信息，不僅僅是已編譯過的處理器類型。代碼中的指令通過單獨(dú)存儲(chǔ)的配置數(shù)據(jù)進(jìn)行擴(kuò)充。有兩種主要的數(shù)據(jù)存儲(chǔ)方法：設(shè)備樹device-tree 和 高級(jí)配置和電源接口(ACPI)表。內(nèi)核通過讀取這些文件了解每次啟動(dòng)時(shí)需要運(yùn)行的硬件。

對(duì)于嵌入式設(shè)備，設(shè)備樹是已安裝硬件的清單。設(shè)備樹只是一個(gè)與內(nèi)核源代碼同時(shí)編譯的文件，通常與 vmlinux 一樣位于 /boot 目錄中。要查看 ARM 設(shè)備上的設(shè)備樹的內(nèi)容，只需對(duì)名稱與 /boot/*.dtb 匹配的文件執(zhí)行 binutils 包中的 strings 命令即可，這里 dtb 是指設(shè)備樹二進(jìn)制文件device-tree binary。顯然，只需編輯構(gòu)成它的類 JSON 的文件并重新運(yùn)行隨內(nèi)核源代碼提供的特殊 dtc 編譯器即可修改設(shè)備樹。雖然設(shè)備樹是一個(gè)靜態(tài)文件，其文件路徑通常由命令行引導(dǎo)程序傳遞給內(nèi)核，但近年來增加了一個(gè) 設(shè)備樹覆蓋 的功能，內(nèi)核在啟動(dòng)后可以動(dòng)態(tài)加載熱插拔的附加設(shè)備。

x86 系列和許多企業(yè)級(jí)的 ARM64 設(shè)備使用 ACPI 機(jī)制。與設(shè)備樹不同的是，ACPI 信息存儲(chǔ)在內(nèi)核在啟動(dòng)時(shí)通過訪問板載 ROM 而創(chuàng)建的 /sys/firmware/acpi/tables 虛擬文件系統(tǒng)中。讀取 ACPI 表的簡(jiǎn)單方法是使用 acpica-tools 包中的 acpidump 命令。例如：

聯(lián)想筆記本電腦的 ACPI 表都是為 Windows 2001 設(shè)置的。

是的，你的 Linux 系統(tǒng)已經(jīng)準(zhǔn)備好用于 Windows 2001 了，你要考慮安裝嗎?與設(shè)備樹不同，ACPI 具有方法和數(shù)據(jù)，而設(shè)備樹更多地是一種硬件描述語(yǔ)言。ACPI 方法在啟動(dòng)后仍處于活動(dòng)狀態(tài)。例如，運(yùn)行 acpi_listen 命令(在 apcid 包中)，然后打開和關(guān)閉筆記本機(jī)蓋會(huì)發(fā)現(xiàn) ACPI 功能一直在運(yùn)行。暫時(shí)地和動(dòng)態(tài)地 覆蓋 ACPI 表 是可能的，而永久地改變它需要在引導(dǎo)時(shí)與 BIOS 菜單交互或刷新 ROM。如果你遇到那么多麻煩，也許你應(yīng)該 安裝 coreboot，這是開源固件的替代品。

從 start_kernel() 到用戶空間

init/main.c 中的代碼竟然是可讀的，而且有趣的是，它仍然在使用 1991 – 1992 年的 Linus Torvalds 的原始版權(quán)。在一個(gè)剛啟動(dòng)的系統(tǒng)上運(yùn)行 dmesg | head，其輸出主要來源于此文件。第一個(gè) CPU 注冊(cè)到系統(tǒng)中，全局?jǐn)?shù)據(jù)結(jié)構(gòu)被初始化，并且調(diào)度程序、中斷處理程序(IRQ)、定時(shí)器和控制臺(tái)按照嚴(yán)格的順序逐一啟動(dòng)。在 timekeeping_init() 函數(shù)運(yùn)行之前，所有的時(shí)間戳都是零。內(nèi)核初始化的這部分是同步的，也就是說執(zhí)行只發(fā)生在一個(gè)線程中，在最后一個(gè)完成并返回之前，沒有任何函數(shù)會(huì)被執(zhí)行。因此，即使在兩個(gè)系統(tǒng)之間，dmesg的輸出也是完全可重復(fù)的，只要它們具有相同的設(shè)備樹或 ACPI 表。Linux 的行為就像在 MCU 上運(yùn)行的 RTOS(實(shí)時(shí)操作系統(tǒng))一樣，如 QNX 或 VxWorks。這種情況持續(xù)存在于函數(shù) rest_init() 中，該函數(shù)在終止時(shí)由 start_kernel() 調(diào)用。

早期的內(nèi)核啟動(dòng)流程。

函數(shù) rest_init() 產(chǎn)生了一個(gè)新進(jìn)程以運(yùn)行 kernel_init()，并調(diào)用了 do_initcalls()。用戶可以通過將 initcall_debug 附加到內(nèi)核命令行來監(jiān)控 initcalls，這樣每運(yùn)行一次 initcall 函數(shù)就會(huì)產(chǎn)生 一個(gè) dmesg 條目。initcalls 會(huì)歷經(jīng)七個(gè)連續(xù)的級(jí)別：early、core、postcore、arch、subsys、fs、device 和 late。initcalls 最為用戶可見的部分是所有處理器外圍設(shè)備的探測(cè)和設(shè)置：總線、網(wǎng)絡(luò)、存儲(chǔ)和顯示器等等，同時(shí)加載其內(nèi)核模塊。rest_init() 也會(huì)在引導(dǎo)處理器上產(chǎn)生第二個(gè)線程，它首先運(yùn)行 cpu_idle()，然后等待調(diào)度器分配工作。

kernel_init() 也可以 設(shè)置對(duì)稱多處理(SMP)結(jié)構(gòu)。在較新的內(nèi)核中，如果 dmesg 的輸出中出現(xiàn) “Bringing up secondary CPUs…” 等字樣，系統(tǒng)便使用了 SMP。SMP 通過“熱插拔” CPU 來進(jìn)行，這意味著它用狀態(tài)機(jī)來管理其生命周期，這種狀態(tài)機(jī)在概念上類似于熱插拔的 U 盤一樣。內(nèi)核的電源管理系統(tǒng)經(jīng)常會(huì)使某個(gè)核core離線，然后根據(jù)需要將其喚醒，以便在不忙的機(jī)器上反復(fù)調(diào)用同一段的 CPU 熱插拔代碼。觀察電源管理系統(tǒng)調(diào)用 CPU 熱插拔代碼的 BCC 工具 稱為 offcputime.py。[!--empirenews.page--]

請(qǐng)注意，init/main.c 中的代碼在 smp_init() 運(yùn)行時(shí)幾乎已執(zhí)行完畢：引導(dǎo)處理器已經(jīng)完成了大部分一次性初始化操作，其它核無需重復(fù)。盡管如此，跨 CPU 的線程仍然要在每個(gè)核上生成，以管理每個(gè)核的中斷(IRQ)、工作隊(duì)列、定時(shí)器和電源事件。例如，通過 ps -o psr 命令可以查看服務(wù)每個(gè) CPU 上的線程的 softirqs 和 workqueues。

# ps -o pid,psr,comm $(pgrep ksoftirqd)

PID PSR COMMAND

7 0ksoftirqd/0

16 1ksoftirqd/1

22 2ksoftirqd/2

28 3ksoftirqd/3

# ps -o pid,psr,comm $(pgrep kworker)

PID PSR COMMAND

4 0kworker/0:0H

18 1kworker/1:0H

24 2kworker/2:0H

30 3kworker/3:0H

[...]

其中，PSR 字段代表“處理器processor”。每個(gè)核還必須擁有自己的定時(shí)器和 cpuhp 熱插拔處理程序。

那么用戶空間是如何啟動(dòng)的呢?在最后，kernel_init() 尋找可以代表它執(zhí)行 init 進(jìn)程的 initrd。如果沒有找到，內(nèi)核直接執(zhí)行 init 本身。那么為什么需要 initrd 呢?

早期的用戶空間：誰規(guī)定要用 initrd?

除了設(shè)備樹之外，在啟動(dòng)時(shí)可以提供給內(nèi)核的另一個(gè)文件路徑是 initrd 的路徑。initrd 通常位于 /boot 目錄中，與 x86 系統(tǒng)中的 bzImage 文件 vmlinuz 一樣，或是與 ARM 系統(tǒng)中的 uImage 和設(shè)備樹相同。用 initramfs-tools-core 軟件包中的 lsinitramfs 工具可以列出 initrd 的內(nèi)容。發(fā)行版的 initrd 方案包含了最小化的 /bin、/sbin 和 /etc 目錄以及內(nèi)核模塊，還有 /scripts 中的一些文件。所有這些看起來都很熟悉，因?yàn)?initrd 大致上是一個(gè)簡(jiǎn)單的最小化 Linux 根文件系統(tǒng)。看似相似，其實(shí)不然，因?yàn)槲挥谔摂M內(nèi)存盤中的 /bin 和 /sbin 目錄下的所有可執(zhí)行文件幾乎都是指向 BusyBox 二進(jìn)制文件 的符號(hào)鏈接，由此導(dǎo)致 /bin 和 /sbin 目錄比 glibc 的小 10 倍。

如果要做的只是加載一些模塊，然后在普通的根文件系統(tǒng)上啟動(dòng) init，為什么還要?jiǎng)?chuàng)建一個(gè) initrd 呢?想想一個(gè)加密的根文件系統(tǒng)，解密可能依賴于加載一個(gè)位于根文件系統(tǒng) /lib/modules 的內(nèi)核模塊，當(dāng)然還有 initrd 中的。加密模塊可能被靜態(tài)地編譯到內(nèi)核中，而不是從文件加載，但有多種原因不希望這樣做。例如，用模塊靜態(tài)編譯內(nèi)核可能會(huì)使其太大而不能適應(yīng)存儲(chǔ)空間，或者靜態(tài)編譯可能會(huì)違反軟件許可條款。不出所料，存儲(chǔ)、網(wǎng)絡(luò)和人類輸入設(shè)備(HID)驅(qū)動(dòng)程序也可能存在于 initrd 中。initrd 基本上包含了任何掛載根文件系統(tǒng)所必需的非內(nèi)核代碼。initrd 也是用戶存放 自定義ACPI 表代碼的地方。

救援模式的 shell 和自定義的 initrd 還是很有意思的。

initrd 對(duì)測(cè)試文件系統(tǒng)和數(shù)據(jù)存儲(chǔ)設(shè)備也很有用。將這些測(cè)試工具存放在 initrd 中，并從內(nèi)存中運(yùn)行測(cè)試，而不是從被測(cè)對(duì)象中運(yùn)行。

最后，當(dāng) init 開始運(yùn)行時(shí)，系統(tǒng)就啟動(dòng)啦!由于第二個(gè)處理器現(xiàn)在在運(yùn)行，機(jī)器已經(jīng)成為我們所熟知和喜愛的異步、可搶占、不可預(yù)測(cè)和高性能的生物。的確，ps -o pid,psr,comm -p 1 很容易顯示用戶空間的 init 進(jìn)程已不在引導(dǎo)處理器上運(yùn)行了。

總結(jié)

Linux 引導(dǎo)過程聽起來或許令人生畏，即使是簡(jiǎn)單嵌入式設(shè)備上的軟件數(shù)量也是如此。但換個(gè)角度來看，啟動(dòng)過程相當(dāng)簡(jiǎn)單，因?yàn)閱?dòng)中沒有搶占、RCU 和競(jìng)爭(zhēng)條件等撲朔迷離的復(fù)雜功能。只關(guān)注內(nèi)核和 PID 1 會(huì)忽略了引導(dǎo)程序和輔助處理器為運(yùn)行內(nèi)核執(zhí)行的大量準(zhǔn)備工作。雖然內(nèi)核在 Linux 程序中是獨(dú)一無二的，但通過一些檢查 ELF 文件的工具也可以了解其結(jié)構(gòu)。學(xué)習(xí)一個(gè)正常的啟動(dòng)過程，可以幫助運(yùn)維人員處理啟動(dòng)的故障。