【図解】Linuxの起動の仕組みとは？RHELブートシーケンスと障害切り分け

「Linuxサーバーが起動しなくなった…」そんなとき、どこに原因があるのか冷静にアタリをつけられていますか？

インフラエンジニアにとって、サーバーの起動プロセス（ブートシーケンス）を理解することは、トラブルシューティングの基礎であり、避けては通れない最重要テーマの一つです。

そこで今回は、エンタープライズのサーバー環境で圧倒的なシェアを誇るRHEL（Red Hat Enterprise Linux）系ディストリビューション（AlmaLinuxやRocky Linuxなど）をベースに、Linuxの起動の仕組みを徹底解説します！

この記事を読めば、コンソール画面のログがどこで止まっているかを見るだけで、ハードウェア、設定ファイル（fstab等）、ネットワークのどこに原因があるかを瞬時に見極められるようになります。

電源ボタンを押してからログインプロンプトが表示されるまでの「裏側の動き」を整理し、実務で役立つ障害切り分けの知識を身につけましょう。

Linuxブートシーケンス（起動の仕組み） 4つの全体像

Linuxのブートシーケンスは、大きく分けて以下の4つのフェーズで進みます。まずはこの全体像を押さえておきましょう。

1. ハードウェア初期化（BIOS / UEFI）
2. ブートローダ（GRUB2）
3. カーネル初期化（Kernel & initramfs）
4. ユーザー空間の起動（systemd）

それぞれのステージで何が行われているのか、詳しく見ていきます。

第1ステージ：ハードウェアの初期化（BIOS / UEFI）

電源ボタンを押して最初に動くのは、OSではなくマザーボードに組み込まれたファームウェア（BIOSまたはUEFI）です。

• POST（Power On Self Test）： CPU、メモリ、ストレージなどのハードウェアが正常に認識され、動作しているかをチェックします。
• ブートデバイスの検索： 設定された優先順位（Boot Priority）に従って、SSDやHDDなどのストレージから、次のステージである「ブートローダ」を探して読み込みます。

システムの起動方式が「従来のBIOS」か「現在のUEFI」かによって、ストレージ上のどこからブートローダを読み込むか（MBR形式かGPT形式か）という仕組みが少し異なります。

サーバーのディスク設計や起動トラブルにも深く関わる部分ですので、怪しいなと思う方はぜひ以下の記事もあわせて参考にしてください。

第2ステージ：ブートローダ（GRUB2）の動作メカニズム

ファームウェアから制御を引き継いだGRUB2（Grand Unified Bootloader version 2）は、OSカーネルをメモリにロードするための多段階の処理を実行します。

GRUB2の内部ステージ構造

GRUB2は、ストレージの制限およびファイルシステム認識の観点から、段階的に機能拡張を行います。

• boot.img（Stage 1相当）： MBR環境では、先頭セクタからロードされ、コアイメージ（diskboot.img等）が格納されているセクタを読み出すための極小のコードです（UEFI環境ではこのステップはスキップされ、初期状態からファイルシステムを認識できます）。
• core.img（Stage 2相当）： ディスクドライバやファイルシステムドライバ（ext4、xfs、LVMなど）が動的に組み込まれたイメージです。これにより、GRUB2は /boot ディレクトリ配下の通常ファイルにアクセス可能となります。

設定ファイルの解釈とカーネルパラメータの引き渡し

ファイルシステムへのアクセスが確立されると、GRUB2は本番の設定ファイル（RHEL系では /boot/grub2/grub.cfg）を読み込みます。

• GRUBメニューの生成： 設定ファイルに基づき、選択可能なカーネルバージョンやレスキューモードのメニューを表示します。
• 静的ロードの実行： ユーザーが選択した（またはデフォルトの）カーネルバイナリ（vmlinuz-xxx）と、初期RAMディスクイメージ（initramfs-xxx.img）を、指定されたメモリ空間へロードします。この際、設定ファイルに記述されたカーネルパラメータ（例：ro、root=UUID=...、console=ttyS0、rhgb quiet）を引数として保持します。

🛠️ カーネルパラメータの一時編集

起動時にGRUBメニューで e キーを押下すると、メモリにロードされる直前のカーネルパラメータを行単位で編集できます。障害発生時に systemd.unit=rescue.target や init=/bin/bash を追記することで、標準の起動処理をバイパスして、メンテナンシェルを直接起動することが可能です。

第3ステージ：カーネル初期化とinitramfsによるルートマウント

GRUB2がメモリへのロードを完了し、カーネルの初頭エントリポイントへジャンプすると、制御はLinuxカーネルへ遷移します。

カーネルの自己解凍とローレベル初期化

メモリ上の vmlinuz（圧縮されたカーネルイメージ）は、内蔵された解凍ルーチンを実行し、自身をリアルモードからプロテクトモード（またはロングモード）へ移行させながら、メモリ空間上で展開します。その後、CPUの初期化、ページング（仮想メモリ）の有効化、基本的な割り込みハンドラの設定を行います。

initramfs（初期RAMディスク）の展開

カーネルは、ストレージ上の本来のルートファイルシステム（/）をマウントする必要がありますが、近代的なLinuxシステムでは、ルートファイルシステムがLVM（論理ボリューム）上やハードウェアRAID、あるいはSAN/iSCSIなどのネットワーク経由で存在することが一般的です。これらを制御するドライバモジュールは、マウント対象のディスク内に格納されているため、「マウントするためのドライバを読むために、マウントしなければならない」というデッドロックが発生します。

この制約を解決するために、initramfsが使用されます。

1. rootfs（仮想構造）の構築： カーネルは、メモリ上に tmpfs を利用した一時的なルートファイルシステム（rootfs）を作成します。
2. アーカイブの展開： GRUB2によってメモリにロードされていた initramfs（cpio形式の圧縮アーカイブ）を、この rootfs 上に展開します。
3. モジュールのロード： initramfsに同梱されている最小限のユーザー空間環境（主に udevd）およびスクリプト（init）が動作し、ストレージコントローラドライバ、RAIDドライバ、LVMメタデータのスキャン（vgchange -ay）などを実行し、物理ストレージデバイスへのアクセスパスを確立します。

switch_root（ルートファイルシステムの切り替え）

物理デバイスが認識されると、initramfs内のスクリプトは、カーネルパラメータの root= で指定されたデバイス（本番のルートファイルシステム）を読み込み専用（ro）で一時マウントします。

その後、switch_root（または pivot_root）システムコールを発行し、制御のベースとなるファイルシステムのルートを、メモリ上の rootfs から物理ストレージ上のルートファイルシステムへ完全に切り替えます。 メモリ上の不要となったinitramfsの領域は解放され、カーネルは本番環境のファイルシステム上にある最初のプロセス（/usr/lib/systemd/systemd）を PID 1 として実行します。

第4ステージ：systemdによるユーザー空間とサービスの起動

物理ルートファイルシステム上の systemd（PID 1） に制御が移ると、オペレーティングシステムはユーザー空間の初期化および各種デーモン（サービス）の確立フェーズへ移行します。

Unit（ユニット）の構造と依存関係の解析

systemdは、システムのリソースやサービスを「Unit」という抽象化されたオブジェクトで管理します。主要な種類には以下があります。

• .service：デーモンの起動・管理
• .target：複数のUnitを論理的にグループ化する同期ポイント（旧ランレベルに相当）
• .mount / .automount：ファイルシステムのマウント管理
• .socket：IPC/ネットワークソケットのリッスン管理

systemdは起動すると、まずターゲットファイル（標準設定では /etc/systemd/system/default.target が指す multi-user.target または graphical.target）の依存関係ツリーをメモリ上に構築します。

各ターゲットの遷移フェーズ

systemdは、以下のマイルストーン（Target）を順次クリアしながら、依存関係を解決していきます。

① sysinit.target（システム初期化フェーズ）

システムが動作するための最下層のインフラストラクチャおよび環境を確立するフェーズです。このターゲットがアクティブになるまでに、以下の処理が順次実行されます。

• ストレージの活性化： 暗号化ディスク（dm-crypt）の複号、LVM（論理ボリューム）の整合性チェックおよびボリュームグループの活性化。
• ローカルファイルシステムのマウント： /etc/fstab の記述に基づき、ルート以外のローカルファイルシステム（/var や /home など）の整合性チェック（fsck）およびマウント。
• セキュリティ基盤の確立： SELinuxポリシーのロードおよび初期化。
• 遷移条件： これらシステム維持に不可欠な下位Unitがすべて正常終了（Active）ステータスになることで、sysinit.target が成立し、次のフェーズへ制御が移行します。

② basic.target（基本実行環境フェーズ）

サービスやデーモンが本格的に動作するための、一般的な実行環境およびプロセス間通信の基盤を整えるフェーズです。

• ソケット・タイマーの初期化： systemdのコア機能である「Socket Activation」に必要なソケットファイルの作成、およびシステムタイマーUnitの活性化。
• 通信バスの確立： プロセス間通信（IPC）の標準インフラである D-Bus（System Message Bus） の初期化。これにより、以降で起動するサービス同士が協調動作するための通信経路が確保されます。
• 意味合い： basic.target の完了をもって、オペレーティングシステムの「基礎的なOS機能」の初期化がすべて完了したことになります。

③ multi-user.target（マルチユーザー環境フェーズ – CUI）

複数のユーザーが同時にシステムへログインし、サーバーとしての機能を完全に提供できる非グラフィカル環境（CUI）を確立するフェーズです。

• ネットワークの活性化： NetworkManager 等のネットワーク管理Unitが起動し、インターフェースにIPアドレスが割り当てられ、ルーティングが有効化されます。
• サーバーデーモンの並列起動： network.target の成立をトリガーとして、リモートアクセス用の sshd、タスクスケジューラの crond、システムログ管理の rsyslogd など、実務に必要な主要サービスが非同期・並列で一斉に立ち上がります。
• サーバーにおける終端： エンタープライズ用途で一般的に利用される「ヘッドレスサーバー（画面出力を必要としないサーバー）」においては、この multi-user.target の成立がブートシーケンスの実質的な最終ゴールとなります。

④ graphical.target（グラフィカル環境フェーズ – GUI）

デスクトップ環境やグラフィカルなログイン画面を提供するフェーズです。

• ディスプレイサーバーの起動： システムのデフォルトターゲットが graphical.target（旧ランレベル5相当）に設定されている場合、multi-user.target の成立後にこのフェーズへ遷移します。X11やWaylandといったディスプレイサーバーが起動します。
• ログインマネージャの活性化： GDM（GNOME Display Manager）などのディスプレイマネージャが起動し、GUIベースのユーザー認証画面を展開します。

並列起動とアクティベーション機構

従来のSysVinitシステムでは、シェルの起動スクリプト（/etc/rc.d/rc*.d/ 配下）がシリアル（直列）に実行されていたため、一つのサービス起動の遅延が全体の起動時間に直結していました。

systemdは、以下の機構を用いることで、Unit間の依存関係が競合しない限り、プロセスの非同期・並列起動を実行します。

• Socket Activation： サービスが完全に起動する前に、systemdが先行して該当サービス用のネットワークソケット（ポート）を作成してリッスンします。接続要求が発生した段階でパケットをバッファリングしつつ、対象サービスをオンデマンドで起動するため、サービス間の起動順序を厳密に同期させる必要がなくなります。
• D-Bus Activation： プロセス間通信（D-Bus）のインターフェースを事前定義し、必要に応じてサービスを並列で呼び出します。

すべての依存関係が満たされ、各種ターゲットのUnitがロード完了ステータスになると、ttyまたはディスプレイマネージャに対してログインプロンプトが出力され、ブートシーケンス全体が完了します。

インフラエンジニア必見！起動プロセス別の障害切り分け境界線

ブートシーケンスを理解する最大のメリットは、「サーバーが起動しないときに、どのフェーズで止まっているか」の境界線が引けることにあります。現場で実際に起きた事例を交えながら、切り分けのポイントを見ていきましょう。

1. 画面が真っ暗、またはビープ音が鳴る（BIOS/UEFIフェーズ）

• 原因のフェーズ： ① BIOS / UEFI
• 切り分け： OSの処理にすら到達していません。マザーボードやメモリの不具合、電源周り、パーツの接触不良など、純粋なハードウェア故障を疑います。

2. 「GRUB _」で停止する（ブートローダフェーズ）

• 原因のフェーズ： ② GRUB2 (ブートローダ)
• 切り分け： ブート領域の破損や、GRUBの設定ファイル（/boot/grub2/grub.cfgなど）が壊れている、あるいはディスクのマスターブートレコードの読み込みに失敗している可能性があります。レスキューメディア等での復旧が必要です。

3. 「Kernel Panic」や「Emergency Mode」になる（カーネルフェーズ）

• 原因のフェーズ： ③ Kernel & initramfs
• 切り分け： ディスクの構成と、マウント設定ファイルである /etc/fstab の記述に不整合が起きているケースが多発するポイントです。

🚨 現場のリアル事件簿①：消えたfstabと時限爆弾 過去に開発機で、開発担当者が誤って /etc/fstab ファイルを削除してしまうということがありました。タチが悪いのは、削除されたその瞬間はOSが動き続けているため、誰も気付かないということです。 その後、かなり時間が経ってからメンテナンス等でOSを再起動した際、起動エラー（Emergency Mode）になって初めて発覚しました。fstabなどの超重要ファイルは、設定変更時以外も「触っていないか」の確認が不可欠だと痛感した事例です。

🚨 現場のリアル事件簿②：突然の強制終了と若手のパニック ハードウェアのエラー（電源瞬断やパーツ障害など）でOSが突然シャットダウンし、その後再起動を試みた時のことです。起動プロセスの途中でファイルシステムの整合性が崩れていることが検知され、コンソールにファイルシステムのチェック（fsck）と修復を要求するプロンプトが表示されました。 起動が途中で止まり、見慣れない英語の修復要求画面が出たため、対応した若手エンジニアは「サーバーが壊れた！」と非常にびっくりしていました。こういったケースでは、慌てずにファイルシステムチェックを手動実行するか、ログを確認してディスクの状態を見極める冷静さが求められます。

4. 起動するがSSH接続できない（systemdフェーズ）

• 原因のフェーズ： ④ systemd
• 切り分け： OS自体は起動していますが、sshd や network などのネットワーク系サービスの起動に失敗しています。仮想基盤のコンソールや物理コンソールから直接ログインし、systemctl status や journalctl -xe でサービスごとのログを確認しましょう。

まとめ：仕組みを知ればトラブルは怖くない

Linuxのブートシーケンスは一見複雑に見えますが、4つのステージに分けて整理することで、どこで何が起きているのかがクリアになります。

障害対応の現場では、コンソールに表示される「最後の一行」がどのフェーズに属しているかを見極めることが、迅速な復旧への第一歩です。

「いつも通り起動するはず」と思っているサーバーも、裏ではこれだけのドラマが動いています。次回サーバーを構築・再起動する機会があれば、ぜひコンソールのログを追いかけて、今どのフェーズが動いているかを意識してみてください！

---

Linuxの起動プロセスが整理できたら、ぜひWindowsサーバーとの「設計思想やプロセスの違い」にも目を向けてみてください。

以下の記事では、Windowsのブートシーケンスについて同様のレベル感で詳しく解説しています。両者を比較して学ぶことで、OSの起動メカニズムに対する理解がさらに一段深まります。