Linuxのブートプロセスをわかりやすく理解する

Linuxのブートプロセスは、電源を入れてからログイン画面やシェルが使えるようになるまでの一連の流れを指す。普段は意識しなくても動いているが、起動が遅い、カーネル更新後に立ち上がらない、ルートファイルシステムを認識しない、サービスが自動起動しないといったトラブルでは、この流れをどこまで理解しているかで調査速度が大きく変わる。重要なのは、Linuxの起動を「電源投入」「ファームウェア」「ブートローダ」「カーネル」「initramfs」「PID 1」「サービス起動」という段階に分けて捉えること。これを順番に理解すると、起動トラブルの切り分けがかなりやりやすくなる。

ブートプロセスとは何か

ブートプロセスとは、コンピュータの電源投入からOSが利用可能になるまでの流れ全体を指す。
Linuxでは、単にカーネルを読み込めば終わりではなく、
・ハードウェア初期化
・起動対象のディスクやEFI情報の確認
・ブートローダの実行
・カーネル展開
・initramfsの展開
・ルートファイルシステムへの切り替え
・PID 1 の起動
・各種サービスの起動
という段階を順番に通る。
そのため、どこで止まっているかによって見るべき場所が大きく変わる。

最初の入口はBIOSまたはUEFI

電源投入直後、最初に動くのはLinuxそのものではなく、マザーボード側のファームウェアになる。
古い環境では BIOS、現在の多くの環境では UEFI が使われる。
ここでは主に、
・CPUやメモリの初期化
・接続デバイスの認識
・起動対象デバイスの探索
が行われる。
Linux管理者が普段直接触ることは少ないが、「そもそもOSに到達する前の段階」であることを理解しておくと、ブートローダ以前の問題を切り分けやすい。

POSTで最低限のハードウェア確認が行われる

ファームウェア段階では、一般的にPOSTと呼ばれる初期診断が行われる。
これはメモリやCPU、基本デバイスが最低限使えるかを確認する処理として知られている。
もしこの段階で異常があれば、Linuxの画面どころかブートローダ画面まで進まないこともある。
つまり、Linuxのブート障害に見えても、実際にはハードウェア初期化の段階で止まっているケースもあり得る。

次にブートローダが呼び出される

ファームウェアが起動対象を決めたあと、次に動くのがブートローダ。
Linux環境では代表例として GRUB がよく使われる。
ブートローダの役割は、
・どのカーネルを起動するか選ぶ
・必要なら起動メニューを表示する
・カーネルとinitramfsをメモリへロードする
・カーネルパラメータを渡す
といったもの。
つまり、Linuxカーネル本体を「起動可能な状態にして引き渡す役目」を担っている。

GRUBは何をしているのか

Linux管理で最もよく目にするブートローダが GRUB。
普段は一瞬で通り過ぎるが、実際にはかなり重要な役割を持っている。
たとえば、
・複数カーネルの選択
・リカバリーモード起動
・カーネルパラメータの編集
・別OSとのデュアルブート
などを扱いやすくしている。
カーネル更新後に起動しない場合でも、GRUB から古いカーネルを選んで起動できることがあるため、障害時の退避口としても重要になる。

ブートローダがカーネルとinitramfsをロードする

ブートローダが次に行うのは、Linuxカーネル本体と initramfs をメモリへ読み込むこと。
ここで重要なのは、カーネルだけではなく initramfs も一緒にロードされる点。
なぜなら、カーネル単体ではすぐに本来のルートファイルシステムを扱えないことがあり、初期ユーザー空間として initramfs が必要になるから。
この段階で必要な情報が揃わないと、「カーネルは起動したが root をマウントできない」といった障害が起きやすい。

カーネルが起動すると何が起きるか

ブートローダから制御を受け取ると、Linuxカーネル自身の初期化が始まる。
ここでは主に、
・CPUのモード設定
・メモリ管理の初期化
・デバイスドライバの初期化
・スケジューラなどの基本機能起動
が進む。
この段階では、まだ普段の /usr や /home が普通に使えるわけではない。
あくまでOSの中核部分が立ち上がり、「本格的なユーザー空間へ移る準備」をしている状態と考えると分かりやすい。

initramfsとは何か

initramfs は、初期ルートファイルシステムとしてメモリ上へ展開される仕組み。
カーネル起動直後に使われ、必要なモジュールや起動スクリプトを持ち、本来のルートファイルシステムへ切り替えるための橋渡しをする。
たとえば、
・ストレージドライバ読み込み
・LVMの認識
・RAIDの有効化
・暗号化ディスクの解除
など、本番ルートを扱うための初期処理がここで行われることがある。
そのため、initramfs の内容が壊れていたり、必要モジュールが足りなかったりすると、ブート途中で止まる原因になる。

ルートファイルシステムへの切り替え

initramfs 上で最低限の準備が整うと、本来のルートファイルシステムへ切り替える処理が行われる。
この切り替えが成功して初めて、通常のLinux環境へ本格的に進める。
もしここで失敗すると、
・ルートデバイスが見つからない
・ファイルシステムをマウントできない
・LVMや暗号化解除に失敗する
といったエラーで止まりやすい。
ブート障害ではかなり重要な段階で、「カーネルは生きているが root に到達できない」という状態がここに該当する。

PID 1 が起動する意味

ルートファイルシステムが整うと、ユーザー空間の最初のプロセスが起動する。
これが PID 1。
現在の多くのLinuxでは systemd がここを担っている。
PID 1 は特別な存在で、
・サービス起動の基点
・子プロセスの管理
・起動順序の制御
・終了処理のまとめ役
といった役割を持つ。
つまり、Linuxの「本格的な起動管理」がここから始まると考えると分かりやすい。

昔のinitと今のsystemdの違い

昔のLinuxでは SysV init が起動管理の中心だった時代が長く続いた。
現在は systemd が採用されている環境が多く、起動の考え方もかなり変わっている。
大きな違いとしては、
・サービス起動をユニット単位で扱う
・依存関係を明示的に管理しやすい
・並列起動を行いやすい
・ログ確認に journalctl を使いやすい
といった点がある。
ブートプロセスを現代Linux前提で理解するなら、systemd ベースで考える方が実務に合いやすい。

systemdはブート時に何をしているのか

systemd は PID 1 として起動したあと、必要なユニットを依存関係に従って起動していく。
たとえば、
・ファイルシステムの準備
・ソケットの準備
・ネットワーク関連サービス
・ログ関連サービス
・sshd、Webサーバー、DBなどの常駐サービス
が順番に、または可能なものは並列で起動される。
ここでの設定は unit ファイルに基づいており、サービス単位の自動起動や順序制御が systemd によって行われる。

target の考え方を知ると流れが見えやすい

systemd では target という概念があり、起動の到達点やまとまりを表現する。
たとえば、
・multi-user.target
・graphical.target
などが代表的。
ざっくり言えば、
・CUI中心の通常起動
・GUIまで含めた通常起動
のような違いを扱う入り口になる。
ブートがどこまで進んでいるかを見るうえで、target の概念を知っていると整理しやすい。

ブートが遅いときに見るコマンド

systemd 環境では、ブート時間の可視化に systemd-analyze が使いやすい。
まずは全体時間を見る。

systemd-analyze

さらに、どのサービスが遅いかを見たいなら次。

systemd-analyze blame

依存関係も見たいなら次が使える。

systemd-analyze critical-chain

これにより、ブートが遅い原因が
・デバイス待ち
・ネットワーク待ち
・特定サービスの起動遅延
のどれに近いかを見やすくなる。

ブートトラブルで見やすいログ

Linuxの起動トラブルでは、どの段階で止まったかに応じて見るべき情報が変わる。
systemd 起動後まで進んでいるなら、journalctl で前回ブートのログを追いやすい。

journalctl -b

前回ではなく、ひとつ前のブートログを見たいなら次のようにすることもある。

journalctl -b -1

これで、
・どのサービスが失敗したか
・どのタイミングで止まったか
を時系列で追いやすい。
カーネルメッセージ寄りで見たいなら dmesg も候補になる。

よくあるブート障害の場所

Linuxのブート障害は、大きく次のような段階で起きやすい。
・ファームウェア段階
・ブートローダ段階
・カーネル読み込み段階
・initramfs 段階
・ルートファイルシステム切り替え段階
・systemd / サービス起動段階
たとえば、
・GRUB 画面すら出ない
・カーネル panic
・root device not found
・特定サービスで起動待ち
などは、それぞれ違う段階の問題になる。
「Linuxが起動しない」という一言の中でも、止まっている位置を分けることが重要になる。

現場で見やすい確認の順番

実際にブート問題や遅さを調べるとき、進めやすい順番は次の流れ。

1. どこまで画面が進むかを見る
2. GRUB までか、カーネルまでか、systemd までかを分ける
3. 起動後なら systemd-analyze で時間を見る
4. journalctl -b で失敗箇所を確認する
5. 必要なら dmesg や initramfs 関連を確認する
   この順で考えると、「どこで壊れているか」をかなり整理しやすい。

まとめ

Linuxのブートプロセスを理解するうえで重要なのは、
・最初はBIOS / UEFI から始まること
・次にブートローダがカーネルとinitramfsを読み込むこと
・カーネルが初期化を進めること
・initramfs が本来のルートファイルシステムへ橋渡しすること
・その後に PID 1 として systemd が起動すること
・systemd が各種サービスを立ち上げて通常運用へ入ること
この流れを段階で押さえることになる。
ブートプロセスは一見複雑だが、「どこが担当している処理か」を分けて理解すると、起動遅延やブート障害の切り分けがかなりやりやすくなる。