返回文章列表
玄貓（BlackCat）

Linux 啟動流程偵錯與運行層級管理解析

本文深入探討 Linux 系統的啟動流程與偵錯機制。從解析核心啟動訊息開始，闡述如何透過 `journalctl` 診斷硬體與驅動問題。接著，文章聚焦於初始化系統的角色，特別是 System V init 的 `rc.sysinit` 腳本，分析其在儲存掛載、網路配置與 SELinux 設定中的關鍵作用。此外，文章還系統性地介紹了 Linux 的七個運行層級（Runlevel），解釋其在不同系統狀態下的功能與管理意涵，並提供針對檔案系統掛載失敗等常見啟動問題的實務解決方案。

作業系統 系統管理
Linux 系統啟動 初始化系統 偵錯 運行層級 System V

Linux 系統的穩定運行始於一個可靠且無誤的啟動過程。此過程涉及從硬體偵測、核心載入到初始化系統接管的複雜鏈條，任何環節的異常都可能導致系統無法正常提供服務。本文將系統性地剖析此啟動鏈條，從核心層面的硬體驅動訊息解析，到應用層面的初始化腳本執行，深入探討 System V init 與 systemd 兩種主流初始化系統的運作原理與偵錯策略。文章後半部將進一步延伸至運行層級（Runlevel）的管理，說明其如何定義系統的服務狀態與功能集合，並闡述其在伺服器管理與故障排除中的實務應用，為系統管理者提供一個從底層到上層的完整啟動診斷框架。

系統啟動核心偵錯：從核心訊息到初始化流程

在探索系統穩健運作的過程中，理解核心啟動訊息的解析與初始化系統的偵錯至關重要。當系統啟動時，硬體組件如中央處理器（CPU）、記憶體、網路介面卡、硬碟等，都會被偵測並呈現為系統中的獨立元件。

核心啟動訊息的解析與應用

在基於 systemd 的 Linux 環境中，核心訊息會被整合至 systemd journal 中。因此，除了傳統的 dmesg 指令，使用者亦可透過 journalctl 指令來檢視從系統開機至今的所有核心訊息。例如，在 RHEL 7 系統上，執行 journalctl -k 指令，便能呈現類似以下的輸出：

-- Logs begin at Sat 2019-11-23 10:36:31 EST,
end at Sun 2019-12-08 08:09:42 EST. --
Nov 23 10:36:31 rhel81 kernel: Linux version 4.18.0-147.0.3.el8_1.x86_64
(gcc version 8.3.1 20190507 (Red Hat 8.3.1-4)
(GCC)) #1 SMP Mon Nov 11 12:58:36 UTC 2019
Nov 23 10:36:31 rhel81 kernel: Command line:
BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-147.0.3.el8_1.x86_64
root=/dev/mapper/rhel-root ro resume=/dev/mapper/rhel-swap
rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet
...
Nov 23 10:36:31 rhel81 kernel: Hypervisor detected: KVM
Nov 23 10:36:31 rhel81 kernel: kvm-clock: Using msrs 4b564d01 ...

在檢視這些訊息時，應特別關注那些指示驅動程式載入失敗或硬體功能啟用異常的訊息。過往的經驗中，曾遇過電視調諧卡因偵測到錯誤的調諧器類型而無法正常運作。透過結合電視卡型號資訊與故障現象，並調整調諧器驅動程式的參數，最終得以成功設定正確的調諧器類型。

在描述核心啟動訊息的檢視方法時，我們已略微超前了系統啟動的進程。在使用者能夠登入並查看核心訊息之前，核心本身必須先完成系統的初始化作業。一旦核心完成了初步的硬體偵測與驅動程式載入，便會將系統啟動的後續控制權，交由初始化系統（init system）來處理。

初始化系統的偵錯策略

系統啟動時，最先執行的程序取決於該系統所採用的初始化機制。對於 System V init，首個執行的程序是 init；而對於 systemd，則是 systemd。可透過 ps -ef | head 指令確認當前系統採用的初始化系統，並依循以下對應的偵錯指引。在此以 RHEL 6 系統為例，該系統融合了 Upstart 與 System V init 的混合機制，將用於說明 System V 初始化過程的偵錯。

偵錯 System V 初始化流程

在過去一段時間，絕大多數 Linux 系統都採用 System V init 來初始化系統服務。在 RHEL 6 中，當核心將啟動流程的控制權移交給 init 程序時，init 程序會解析 /etc/inittab 檔案，以獲取系統啟動的指令。

/etc/inittab 檔案會定義系統的預設運行等級（runlevel），並指向 /etc/init 目錄下的相關檔案。這些檔案負責執行諸如重新映射鍵盤按鍵（例如將 Ctrl+Alt+Delete 設定為重新啟動系統）、啟動虛擬主控台，以及指定初始化系統基本服務的腳本位置：/etc/rc.sysinit。

當系統在 init 程序接管後出現問題時，兩個常見的潛在問題源頭是 /etc/rc.sysinit 腳本的執行。此腳本負責初始化系統的諸多基本功能。當它被執行時，會設定系統的主機名稱、掛載 /proc 和 /sys 檔案系統、配置 SELinux、設定核心參數，並執行數十項其他操作。

其中，rc.sysinit 最關鍵的功能之一是建立系統的儲存裝置。若啟動流程在 rc.sysinit 處理過程中失敗，極有可能表示該腳本未能找到、掛載或解密系統運行所需的本地或遠端儲存裝置。

以下列出一些常見的 rc.sysinit 腳本執行時可能發生的失敗情境，以及應對這些失敗的方法：

儲存裝置掛載失敗
  • 現象：系統無法找到或掛載必要的儲存裝置，導致後續服務無法啟動。
  • 偵錯方向：
    • 檢查 /etc/fstab 檔案，確認儲存裝置的 UUID 或裝置路徑是否正確。
    • 確認儲存裝置本身是否正常運作，例如硬碟是否通電、網路儲存是否連線。
    • 若涉及加密儲存，檢查加密金鑰或密碼是否正確輸入。
    • 嘗試手動掛載儲存裝置，以隔離問題。
網路配置異常
  • 現象：系統無法正確配置網路介面，影響依賴網路的服務。
  • 偵錯方向：
    • 檢查網路介面設定檔，確認 IP 位址、子網路遮罩、預設閘道等資訊是否正確。
    • 確認網路硬體連接正常。
    • 若使用 DHCP，檢查 DHCP 伺服器是否正常運作。
SELinux 策略衝突
  • 現象：SELinux 策略阻止了某些必要的服務或檔案存取，導致啟動失敗。
  • 偵錯方向：
    • 暫時將 SELinux 設定為寬鬆模式（permissive mode）或禁用模式（disabled mode），以判斷是否為 SELinux 問題。
    • 檢查 SELinux 審核日誌（audit log），尋找被拒絕的操作。
    • 根據日誌訊息，調整 SELinux 策略或標籤。
核心參數設定錯誤
  • 現象：不正確的核心參數設定影響了系統的穩定性或功能。
  • 偵錯方向：
    • 檢查 /etc/sysctl.conf 檔案及 /etc/sysctl.d/ 目錄下的設定檔。
    • 移除或修改可疑的核心參數，然後重新啟動系統進行測試。
裝置驅動程式載入問題
  • 現象：某些硬體裝置的驅動程式未能成功載入，導致裝置無法使用。
  • 偵錯方向：
    • 檢視核心啟動訊息 (journalctl -k)，尋找與驅動程式載入相關的錯誤訊息。
    • 確認驅動程式模組是否已正確安裝。
    • 嘗試手動載入驅動程式模組，並觀察輸出。

此偵錯過程強調了系統啟動初期各環節的連動性。從核心偵測硬體、載入驅動，到初始化系統接管並配置環境，每一個步驟的異常都可能導致系統無法順利啟動。透過系統性地分析核心訊息與初始化腳本的執行日誌，並結合對各類系統組態的理解，便能有效地診斷並解決啟動階段的問題。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

title System Boot Initialization Flow

node "Hardware" as HW
node "Kernel" as KNL
node "Init System" as INIT
node "System Services" as SVCS

HW --> KNL : Detect Hardware & Load Drivers
KNL --> INIT : Pass Control
INIT --> INIT : Parse Init Config (/etc/inittab, systemd units)
INIT --> SVCS : Start Services

rectangle "System V Init" {
    INIT --|> InitProcess : First Process
    InitProcess : Checks /etc/inittab
    InitProcess --> RcSysinit : Executes /etc/rc.sysinit
    RcSysinit : Sets Hostname, Filesystems, SELinux, Kernel Params, Storage Setup
    RcSysinit --> Storage : Mount Local/Remote Storage
    RcSysinit --> Network : Configure Network
    RcSysinit --> KernelParams : Set Kernel Parameters
}

rectangle "systemd" {
    INIT --|> SystemdProcess : First Process
    SystemdProcess : Manages Units & Targets
    SystemdProcess --> ServiceUnits : Activates Service Units
}

note left of KNL : Kernel messages logged via journalctl -k
note right of RcSysinit : Failures often related to storage or basic config
note right of INIT : Choice between System V and systemd

@enduml

看圖說話：

此圖示描繪了 Linux 系統的啟動初始化流程。流程始於硬體被偵測，隨後核心載入相關驅動程式。核心完成初步任務後，將控制權移交給初始化系統。初始化系統的具體形式取決於其類型，例如 System V init 或 systemd。在 System V init 的架構下，init 程序會解析 /etc/inittab，並執行 /etc/rc.sysinit 腳本，該腳本負責設定系統主機名稱、掛載檔案系統、配置 SELinux、設定核心參數，以及最重要的儲存裝置掛載。若此階段出現問題，通常與儲存裝置的存取或基本系統配置有關。相對地，systemd 則透過管理單位（units）和目標（targets）來啟動系統服務。核心的啟動訊息可透過 journalctl -k 指令進行檢視，這對於診斷硬體或驅動程式問題至關重要。

實務案例分析：儲存裝置遺失導致的啟動中斷

某次在部署一台新的伺服器時，系統在啟動過程中卡住了，螢幕上顯示著類似「Waiting for device /dev/mapper/vg0-root to appear…」的訊息，並且長時間沒有進展。透過遠端連線（若有配置）或直接連接顯示器，觀察到系統似乎卡在掛載根檔案系統的階段。

問題分析與解決過程：

  1. 初步判斷：訊息明確指出系統正在等待一個名為 /dev/mapper/vg0-root 的裝置出現，這通常是 LVM（Logical Volume Manager）配置下的邏輯卷。啟動中斷很可能與 LVM 儲存裝置的配置或偵測有關。
  2. 檢視核心訊息：在系統進入救援模式（rescue mode）或使用 Live CD/USB 啟動後，首先執行 journalctl -k 來查看核心啟動日誌。尋找與儲存裝置（特別是硬碟、LVM、RAID 等）相關的錯誤訊息。可能發現的訊息包括：
    • 「device-mapper: table ioctl failed: Invalid argument」
    • 「lvm: vgscan failed」
    • 「mdadm: failed to start array」
    • 硬碟偵測失敗的訊息。
  3. 檢查 LVM 配置：在救援環境中，執行 vgscan 和 vgchange -ay 來嘗試掃描並啟用所有 LVM 卷群組（Volume Groups）。如果 vgscan 找不到 vg0，則問題可能出在底層儲存裝置的偵測。
  4. 檢查底層儲存裝置：
    • 若為實體硬碟，使用 lsblk 或 fdisk -l 檢查硬碟是否被系統正確辨識。
    • 若為 RAID 陣列，使用 mdadm --detail /dev/mdX 檢查 RAID 狀態。
    • 若為網路儲存（如 iSCSI、NFS），檢查網路連線和儲存伺服器端的設定。
  5. 找出根本原因：在此案例中，經過仔細檢查，發現新伺服器上的某個硬碟在安裝時被錯誤地設定了 GPT 分割表，而系統預期的是 MBR 分割表，或是 LVM 相關的分割區標籤資訊遺失。這導致 LVM 無法正確識別底層的分割區，進而無法建立 /dev/mapper/vg0-root 這個邏輯卷。
  6. 解決方案：
    • 選項一（重新分割與重建 LVM）：如果資料不重要，最快的方式是重新啟動，進入安裝程式，確保硬碟分割與 LVM 設定正確，然後重新安裝系統。
    • 選項二（修復分割表與 LVM）：在救援模式下，使用 gdisk 或 parted 等工具修復分割表（若可能），然後嘗試使用 vgcfgrestore 指令從備份的 LVM 設定檔中恢復卷群組資訊。若無備份，則需手動重建 LVM 結構。
    • 選項三（調整啟動參數）：在極少數情況下，可以嘗試在 GRUB 啟動選單中修改核心參數，例如加入 rd.lvm.lv=vg0/root 等，但這通常是治標不治本。

學習心得：

這個案例深刻體現了儲存裝置在系統啟動中的關鍵地位。任何與儲存裝置相關的配置錯誤，無論是分割表、LVM 設定，或是底層硬體問題，都可能導致系統無法完成掛載根檔案系統的步驟，進而中斷整個啟動流程。因此，在部署新系統或進行硬體變更後，仔細檢查核心日誌和 LVM 相關的狀態是偵錯的第一步。同時，建立 LVM 設定檔的定期備份，能在發生嚴重問題時提供快速恢復的途徑。

前瞻性觀點：容器化與微服務對初始化過程的影響

隨著容器化技術（如 Docker、Kubernetes）的普及，傳統的系統初始化流程正經歷轉變。在容器環境中，應用程式被封裝在獨立的容器內，其啟動和依賴管理由容器引擎負責。這意味著，對於部署在容器內的應用程式而言，底層作業系統的 rc.sysinit 或 systemd 服務的啟動順序，可能不再是首要考量。

然而，底層作業系統的穩定性與正確配置依然是容器運行環境的基石。即使應用程式運行在容器中，其依賴的基礎設施（如網路、儲存）仍需由主機作業系統的初始化過程來準備。因此，理解並掌握核心訊息的解析與初始化系統的偵錯，對於維護容器化環境的穩定性，依然具有不可或缺的價值。

未來，隨著雲原生技術的發展，我們可能會看到更輕量級、更專注於應用程式部署的啟動機制。但對於底層系統的診斷，核心訊息的分析能力將持續作為工程師的關鍵技能。

系統啟動疑難排解與運行層級解析

系統在啟動過程中，常會遇到各種預期外的狀況，其中與檔案系統掛載、主機名稱設定及加密磁碟解密相關的問題，是影響系統正常運行的關鍵環節。此外，理解 Linux 系統的運行層級（runlevel）對於管理和診斷系統至關重要。

檔案系統掛載失敗的應對策略

當 /etc/fstab 檔案中的某個掛載點設定出現錯誤，且未經測試便重啟系統，將導致啟動流程中斷於服務啟動之前。此時，系統會進入一個根檔案系統唯讀的緊急模式，並提供一個 root 使用者的終端介面。

為了解決此問題，首要步驟是將根檔案系統重新掛載為可寫模式。接著，編輯 /etc/fstab 檔案以修正錯誤的條目。完成修正後，執行 mount -a 命令嘗試掛載所有在 /etc/fstab 中定義的檔案系統，以驗證修正的有效性。最後，重新啟動系統即可恢復正常。

以下是處理此類情況的指令序列：

mount -o remount,rw /
vim /etc/fstab
mount -a
reboot

在編輯 /etc/fstab 時，使用 vim 編輯器能提供語法高亮顯示，例如掛載選項的顏色變化，有助於識別潛在的格式錯誤，進而降低再次出錯的機率。

主機名稱未正確設定的診斷

系統啟動時的 rc.sysinit 腳本會嘗試設定主機名稱。此腳本主要依賴 /etc/sysconfig/network 檔案中的 HOSTNAME= 設定。若此設定不存在，系統預設會使用 localhost 作為主機名稱。此外，透過 DHCP 伺服器亦可動態取得主機名稱。若啟動過程中發現主機名稱未正確設定，應檢查上述配置檔案及 DHCP 服務的狀態。

加密檔案系統解密障礙的排除

rc.sysinit 腳本會查閱 /etc/crypttab 檔案來獲取解密加密檔案系統所需的資訊。若此檔案損壞，使用者可能需要尋找其備份來恢復檔案系統的解密能力。若在啟動過程中被提示輸入解密密碼，而使用者卻不知道該密碼，則可能面臨嚴重的資料存取問題。

Linux 運行層級詳解

Linux 系統的啟動流程中，服務的啟動是基於預設的運行層級。系統共有七個運行層級，編號從 0 到 6。伺服器環境通常預設為運行層級 3，而桌面環境則多為運行層級 5。以下是早期 RHEL 6 及之前版本的 Linux 系統中，各運行層級的定義：

  • 運行層級 0： 關機層級。所有處理程序將被終止，系統隨後關閉電源。
  • 運行層級 1： 單人使用者模式。僅啟動必要的處理程序以完成系統引導（包括掛載所有檔案系統），並在主控台提供一個 root 使用者提示。此模式不啟動網路功能，並繞過正常認證流程。它主要用於在忘記 root 密碼時進行系統修復。使用 single 關鍵字也能進入此模式，但 single 不會執行 /etc/rc1.d 目錄下的腳本。
  • 運行層級 2： 多人使用者模式。此層級在現今較少使用，其原始含義已模糊。早期 UNIX 系統用於啟動多個終端連線，允許多位使用者同時透過文字介面存取系統。網路介面通常不會啟動，因為當時的網路連接不如現今普遍。現今，運行層級 2 通常會啟動網路介面，但不一定啟動所有網路服務。
  • 運行層級 3： 多人使用者加上網路模式。此層級是 Linux 伺服器的典型配置，系統啟動後僅顯示純文字提示符，而非圖形介面。網路功能與所有網路服務都會啟動。雖然可能已安裝圖形桌面環境，但需要手動啟動才能使用。
  • 運行層級 4： 未定義。此層級的行為通常與運行層級 3 相同，但其用途可由系統管理員自行定義。

以下圖示將展示系統啟動時，不同服務與運行層級之間的關聯性。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

entity "啟動程序" as Boot {
  BIOS/UEFI
  Bootloader (GRUB)
  Kernel
  init/systemd
}

package "系統初始化" {
  Boot --> "載入核心" as LoadKernel
  LoadKernel --> "掛載根檔案系統" as MountRootFS
  MountRootFS --> "執行 init/systemd" as RunInit
}

package "運行層級管理" {
  RunInit --> "讀取 /etc/inittab 或 systemd 設定" as ReadConfig
  ReadConfig --> "啟動預設運行層級服務" as StartServices
}

node "運行層級" {
  StartServices --> "Runlevel 0 (關機)" as RL0
  StartServices --> "Runlevel 1 (單人使用者)" as RL1
  StartServices --> "Runlevel 2 (多人使用者)" as RL2
  StartServices --> "Runlevel 3 (多人使用者+網路)" as RL3
  StartServices --> "Runlevel 4 (未定義)" as RL4
  StartServices --> "Runlevel 5 (多人使用者+圖形)" as RL5
  StartServices --> "Runlevel 6 (重啟)" as RL6
}

package "服務與配置" {
  RL1 --> "僅核心服務"
  RL3 --> "網路服務"
  RL5 --> "圖形介面"
}

RL0 ..> "系統關閉"
RL6 ..> "系統重啟"

note left of MountRootFS
  若 /etc/fstab 錯誤，
  此階段可能中斷。
end note

note right of ReadConfig
  決定系統進入
  哪個運行層級。
end note

@enduml

看圖說話：

此圖示描繪了 Linux 系統從 BIOS/UEFI 啟動到進入特定運行層級的流程。首先，啟動載入程式載入核心，隨後核心掛載根檔案系統。接著，init 或 systemd 處理程序啟動，並根據設定檔案（如 /etc/inittab 或 systemd 的 unit 檔案）來決定系統應進入哪個運行層級。不同的運行層級（0 至 6）代表著系統的不同工作狀態，從完全關機、單人使用者修復模式，到支援網路的多人使用者環境，乃至包含圖形使用者介面的模式。圖中特別標示出，若 /etc/fstab 檔案存在錯誤，系統在掛載根檔案系統階段就可能中斷，這與前面討論的檔案系統掛載失敗問題直接相關。運行層級的選擇決定了哪些服務會被啟動，進而影響系統的可用功能。

好的，這是一篇針對您提供的「系統啟動核心偵錯」技術文章，所撰寫的「玄貓風格高階管理者個人與職場發展」結論。

結論

深入剖析系統啟動的核心偵錯後，我們不僅掌握了技術層面的問題診斷，更可從中提煉出一套適用於高階管理者個人發展的深刻隱喻。系統的初始化流程，如同管理者每日運作的內在心智模式與核心價值觀。儲存裝置掛載失敗，恰似個人核心資源（如精力、時間）的配置失當；而/etc/fstab的一筆錯誤設定導致系統停擺，則精準對應了某個僵化信念如何癱瘓我們的決策流程。這種從「緊急模式」中手動修正、重新掛載的過程，正是高階領導者進行深度自我覺察與核心假設修正的寫照，其價值遠超表層的行為調整。

文中提及的容器化趨勢，雖看似將底層初始化過程抽象化，卻也反襯出「主機作業系統」穩健的重要性。這預示著，無論未來管理工具與方法論（如敏捷、OKR）如何演進，領導者個人心性的穩定度、情緒韌性與自我修復能力，始終是承載一切高階策略與團隊動能的最終基石。

玄貓認為，真正卓越的管理者，不僅是組織的架構師，更是自身「內在作業系統」的首席維運工程師。精通這套從核心訊息解讀到初始化流程偵錯的思維，意味著掌握了實現持續自我迭代與組織韌性共振的關鍵法門。