Linux起動のシーケンス：電源ONからログイン画面までの壮大な旅
連載ナビ
この連載は「Linuxを使えるようになる」ではなく、「Linuxがどう動いているのか」を理解するための実践シリーズです。
今回は Linuxを理解する 〜 LFSで学ぶLinux内部構造 〜 の Part 2 / 第5回として、仕組みのつながりを意識しながら学びます。
—
起動とは「ファームウェア → ブートローダ → カーネル → PID 1」の権限移譲
電源ボタンを押してからログイン画面が出るまでに、内部では何が起きているのか。結論から言うと、Linuxの起動は「より原始的なプログラムが、次に動くべきプログラムをメモリにロードして制御を渡す」というバトンリレーであり、大きく次の流れで進みます。
電源ON
→ BIOS/UEFI (ファームウェア。ハードウェアの初期化と自己診断)
→ ブートローダ (GRUBなど。カーネルをディスクから探してロード)
→ カーネル + initramfs (ハードウェア認識、ルートファイルシステムのマウント)
→ PID 1 (systemd) (サービスの起動、ログイン画面の表示)
前回学んだPID 1は、このリレーの最終走者です。今回はスタートからゴールまでを通しで追い、「起動しない」というトラブルをステージ単位で切り分けられるようになることを目指します。
ステージごとに担当が違うから、止まった場所で原因を絞れる
なぜこの流れを覚える価値があるのか。理由は、各ステージの担当範囲が明確に分かれているため、「どこまで進んで止まったか」がそのまま原因の絞り込みになるからです。
BIOS/UEFIまでしか進まないならハードウェアかディスクの問題、GRUBのメニューは出るのにその先で止まるならカーネルかルートファイルシステムの問題、カーネルは起動したのにサービスが上がらないならsystemd配下のユニットの問題——というように、画面に最後に表示されたものが、そのまま調査の入り口を教えてくれます。
これは、クラウドのVMやオンプレサーバーが「SSHできなくなった」ときにコンソール画面（AWSならEC2シリアルコンソールなど）を見て状況判断する場面で、そのまま役立つ知識です。
6つのステージを、実際のファイル名とともに追う
1. 電源ON → BIOS/UEFI
マザーボード上のファームウェアが起動し、CPUやメモリの自己診断（POST）を行います。その後、設定された起動順序に従ってブートデバイスを探します。UEFI環境では、ディスク内のESP（EFIシステムパーティション。通常 /boot/efi にマウントされる）から次のステージのプログラムを読み込みます。
2. ブートローダ（GRUB）
多くのディストリビューションで使われるブートローダがGRUBです。GRUBの仕事は、設定ファイル /boot/grub/grub.cfg に従って起動メニューを表示し、選ばれたカーネルをメモリにロードして制御を渡すことです。このとき「ルートファイルシステムはどこか」などの起動パラメータ（root=UUID=... など）もカーネルに引き渡します。
3. カーネル + initramfs のロード
GRUBがロードするのは2つのファイルです。/boot を見ると実物が確認できます。
– vmlinuz-<バージョン> — 圧縮されたカーネル本体
– initrd.img-<バージョン>（または initramfs-...）— initramfs。メモリ上に展開される小さな仮ファイルシステムで、ルートファイルシステムをマウントするために必要なドライバ（ストレージ、暗号化、LVMなど）とツールが入っています。カーネル本体にすべてのドライバを組み込むと巨大になるため、「本番のディスクを読むための最小セット」を別ファイルにしているのです。
4. ルートファイルシステムのマウント
initramfs内のドライバを使って、カーネルは起動パラメータ root= で指定された本物のルートファイルシステム（/）をマウントします。ここで初めて /etc の設定や /usr/bin のコマンド群にアクセスできるようになり、役目を終えたinitramfsは破棄されます。この段階の失敗が、有名な Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) です。
5. PID 1（systemd）の起動
カーネルはルートファイルシステム上の /sbin/init（現代の多くの環境ではsystemdへのシンボリックリンク）を、前回学んだPID 1として起動します。ここでカーネルからユーザー空間へバトンが渡り、以降のプロセスはすべてPID 1の子孫として生まれます。
6. ターゲット到達とログイン画面
systemdはunitファイルの依存関係を解決しながら、ネットワーク、sshd、ロギングなどのサービスを並列に起動します。ゴール地点は「ターゲット」と呼ばれ、サーバーなら multi-user.target（CUIログイン）、デスクトップなら graphical.target（GUIログイン）が一般的です。ログインプロンプトが表示されたら、リレーは完走です。
「どの画面で止まったか」を症状から逆引きする
このステージ分けを、実際のトラブルシューティングに落とし込むと次のようになります。
| 症状 | 疑うステージ | 調査の入り口 |
| 画面に何も出ない・メーカーロゴで停止 | Stage 1 (BIOS/UEFI) | ハードウェア、起動順序の設定、ディスクの認識 |
grub> プロンプトやGRUBエラーが出る |
Stage 2 (ブートローダ) | /boot/grub/grub.cfg、ブートローダの破損 |
VFS: Unable to mount root fs でパニック |
Stage 3〜4 | root= パラメータ、initramfsの再生成（Ubuntuなら update-initramfs） |
| 起動途中で emergency mode に落ちる | Stage 4〜6 | /etc/fstab の記述ミス、journalctl -xb でログ確認 |
| ログインはできるが特定サービスが動かない | Stage 6 | systemctl status <サービス名>、journalctl -u <サービス名> |
正常に起動した環境でも、リレーの記録は後から確認できます。systemd-analyze は「カーネル・initrd・ユーザー空間それぞれに何秒かかったか」を1行で示し、journalctl -b は今回の起動ログ全体を時系列で見せてくれます。起動が遅いときは systemd-analyze blame で時間を食っているサービスを特定するのが定石です。
起動シーケンスが分かれば、LFSの工程表が読めるようになる
Linuxの起動は、BIOS/UEFI → GRUB → カーネル+initramfs → ルートファイルシステム → PID 1（systemd）→ ターゲット到達、という権限移譲のリレーであり、止まった場所がそのまま原因の切り分けになる——これが今回の結論であり、Part 2の総まとめです。
そしてこの知識は、次のPart 3以降で挑むLFSの「工程表」そのものでもあります。LFSでは、カーネルを自分でビルドし、GRUBを自分で設定し、initを自分で用意します。つまり今回追ったリレーの各走者を、全部自分の手で作るのです。次回はまず、LFSとは具体的に何をするプロジェクトなのかを整理します。
コマンドで起動プロセスを分析する
# 全体の起動時間を表示（カーネル、initrd、ユーザー空間の内訳が出る）
systemd-analyze
# 各サービスの起動所要時間を長い順に表示。ボトルネック特定に役立つ
systemd-analyze blame | head
# 今回の起動（-b）における、警告(-p warning)以上のログを表示
journalctl -b -p warning | head
# ブートローダがロードするカーネルとinitramfsの実物を確認する
ls -lh /boot/vmlinuz-* /boot/initrd.img-* 2>/dev/null || ls -lh /boot
チェックポイント
- Linuxの起動プロセスを、BIOS/UEFIからsystemdまでの6段階で説明できる
initramfsが、ルートファイルシステムをマウントするために必要な初期ツールキットであることを理解した- 「GRUBは出るがその先で止まる」場合に、どのステージを疑うべきか言える
systemd-analyze blameコマンドが、起動が遅い原因を特定するのに役立つことを知った
今回理解できたこと
- Linuxの起動は、ファームウェアからPID 1へと制御が委譲されていくバトンリレーであること
- カーネル本体（vmlinuz）とinitramfsは
/bootに実在するファイルであり、GRUBがそれらをロードすること - 各段階には明確な担当範囲があり、止まった場所がトラブル切り分けの重要な指標となること
systemd-analyzeやjournalctlで、起動シーケンスを事後に分析できること