ブートプロセス入門 LinuC101 第2回

新卒インフラエンジニア向けLinuC 101 試験対策シリーズの第2回です。前回はサーバーへのログインと停止を扱いました。今回はその一段階手前、「電源ボタンを押した瞬間からログインプロンプトが出るまで」に何が起きているのかを追跡します。

ブートプロセスの理解は、起動失敗のトラブルシュートで「どの段階で止まったか」を切り分ける土台になります。本番障害でこの知識の有無は復旧時間を左右します。

今ここマップ

LinuC 101 試験対策シリーズ（全12回）

  第1回 Linuxの起動・接続・停止
▶ 第2回 ブートプロセスの仕組み           ← いまここ
  第3回 systemdマスター講座
  第4回 プロセス管理とハードウェア基礎
  第5回 仮想マシンとコンテナの基礎
  第6回 パッケージ管理マスター
  第7回 ファイル操作の実践
  第8回 パーミッション・所有者・特殊権限
  第9回 コマンドライン・リダイレクト・パイプ
  第10回 テキスト処理（grep / sed / awk）
  第11回 vi/vim 入門
  第12回 ディスク・パーティション・ファイルシステム

この記事で身につくこと

1. BIOS/UEFI → ブートローダ → カーネル → init（systemd） の流れを言葉で説明できる
2. UEFI環境でのブートエントリを efibootmgr で確認できる
3. GRUB2の役割と主要ファイル（/etc/default/grub、/boot/grub2/grub.cfg）の関係を理解している
4. grubby でカーネルパラメータを永続的に追加・削除できる
5. journalctl -b や dmesg で起動時ログを確認できる

そもそも「ブート」とは何か

ブート（boot）の語源は “bootstrap”。「自分の靴ひもを引っ張って自分を持ち上げる」という比喩です。電源を入れた直後の何もない状態から、コンピュータが自身を一段階ずつ起動して最終的にOSが動き始める—この多段階の自己起動処理を「ブート」と呼びます。

Linux のブートは 4つのステージに分けて考えると整理しやすくなります。

なぜこんな多段階処理になっているのかというと、各段階で責任分界があるためです。ファームウェアはハードウェアの最低限の初期化のみ、ブートローダはカーネル選択のみ、カーネルは汎用的なハードウェア抽象化のみ、init は実運用環境の整備のみ。各層が役割を限定することで、Linuxはあらゆるハードウェア・ディストリビューションで動作する柔軟性を獲得しています。

第1章：BIOS と UEFI

1.1 ファームウェアとは

マザーボードに組み込まれた最初に走るプログラム、それがファームウェアです。歴史的には BIOS（Basic Input/Output System）が長く使われてきましたが、2010年代以降のマシンはほぼ全て UEFI（Unified Extensible Firmware Interface）に移行しています。

項目	BIOS	UEFI
登場年代	1981年（IBM PC）	2005年〜
パーティション方式	MBR（最大2TB）	GPT（実質無制限）
ブートローダ配置	MBRの先頭446バイト	ESP（EFI System Partition）の.efiファイル
セキュアブート	非対応	対応
起動速度	遅い	速い
設定UI	テキストのみ	グラフィカル可

1.2 自分の環境がBIOSかUEFIか確認する

実行コマンド（linuc-almaで実行）：

$ hostnamectl

実行結果：

 Static hostname: linuc-alma
       Icon name: computer-vm
         Chassis: vm 🖴
      Machine ID: 9675dfbf54f14d9ebfa704b59841fc8f
         Boot ID: 44ba742031594ff8a3b3facbf1a6ee39
  Virtualization: microsoft
Operating System: AlmaLinux 9.6 (Sage Margay)
     CPE OS Name: cpe:/o:almalinux:almalinux:9::baseos
          Kernel: Linux 5.14.0-570.12.1.el9_6.x86_64
    Architecture: x86-64
 Hardware Vendor: Microsoft Corporation
  Hardware Model: Virtual Machine
Firmware Version: Hyper-V UEFI Release v4.1

最下行 Firmware Version: Hyper-V UEFI Release v4.1 から、この環境が UEFI であることが分かります。物理サーバーでも、近年の機種はほぼ UEFI です。

もう1つの判別方法として、/sys/firmware/efi/ ディレクトリの存在を確認する方法があります。

実行コマンド：

$ ls /sys/firmware/efi/ 2>/dev/null && echo "UEFI" || echo "BIOS"

1.3 UEFIブートエントリを確認する

UEFI環境では、NVRAM（不揮発メモリ）にブートエントリが保存されます。efibootmgr コマンドで確認できます。

実行コマンド：

$ sudo efibootmgr -v

実行結果：

BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0002,0000,0001,0003
Boot0000* EFI Network	AcpiEx(VMBus,,)/VenHw(...)/MAC(...)/IPv4(...)
Boot0001* EFI SCSI Device	AcpiEx(VMBus,,)/VenHw(...)/SCSI(0,0)
Boot0002* EFI SCSI Device	AcpiEx(VMBus,,)/VenHw(...)/SCSI(0,1)
Boot0003* EFI Network	AcpiEx(VMBus,,)/VenHw(...)/MAC(...)/IPv4(...)
Boot0004* AlmaLinux	HD(1,GPT,c586501b-...)/File(\EFI\almalinux\shimx64.efi)

読み方のポイント：

• BootCurrent: 0004 — 今回の起動で使われたエントリ番号
• BootOrder: 0004,0002,0000,0001,0003 — 試行する順番
• Boot0004* AlmaLinux — AlmaLinuxのエントリ。\EFI\almalinux\shimx64.efi がESP内のローダ実体

「shim」（シム）は Secure Boot 対応のための薄いローダで、Microsoft 署名済みの shim → ディストリビューション署名の GRUB2 → カーネル、という3段階で署名検証されます。

第2章：GRUB2 — Linuxの標準ブートローダ

2.1 GRUB2 の役割

UEFIから制御を渡された後、GRUB2（GRand Unified Bootloader 2）がブートローダとして動きます。GRUB2の主な仕事は3つです。

• カーネル選択メニューの表示（複数カーネルがあるとき）
• 選択されたカーネルと initramfs を /boot から読み込み
• カーネルパラメータ（コマンドライン引数）を渡してカーネルを起動

2.2 設定ファイルは2層構造

GRUB2 の設定は 「人が編集する側」と「自動生成される側」の2層に分かれています。これを混同するとハマります。

ファイル	役割	編集
/etc/default/grub	主要設定（タイムアウト・既定エントリ・カーネル引数等）	✅ 人が直接編集
/etc/grub.d/	grub.cfg生成スクリプト群	△ 上級者向け（基本触らない）
/boot/grub2/grub.cfg	GRUB2が実際に読む完成形	❌ 直接編集禁止（自動生成）
/boot/loader/entries/*.conf	BLS方式のカーネルエントリ	△ 通常 grubby 経由で編集

実行コマンド：

$ cat /etc/default/grub

実行結果：

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

主要な設定項目の意味：

• GRUB_TIMEOUT=5 — メニュー表示時間（秒）
• GRUB_DEFAULT=saved — 前回起動したエントリを記憶（grub-set-default で変更可）
• GRUB_CMDLINE_LINUX="..." — 全カーネルに渡される共通の起動パラメータ
• GRUB_ENABLE_BLSCFG=true — BLS（Boot Loader Spec）方式を有効化

では、「自動生成される側」の grub.cfg も覗いてみます。

実行コマンド：

$ sudo head -10 /boot/grub2/grub.cfg

実行結果：

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
set pager=1

冒頭で「DO NOT EDIT THIS FILE」と明示されています。手動編集すると、次の grub2-mkconfig 実行時に上書き消失します。

2.3 BLS（Boot Loader Spec）方式

AlmaLinux 9 / RHEL 9 系では BLS方式が既定です。各カーネルエントリは /boot/loader/entries/ 配下の独立した .conf ファイルになっています。

実行コマンド：

$ sudo ls /boot/loader/entries/

実行結果：

9675dfbf54f14d9ebfa704b59841fc8f-0-rescue.conf
9675dfbf54f14d9ebfa704b59841fc8f-5.14.0-570.12.1.el9_6.x86_64.conf

ファイル名は {Machine ID}-{kernel-version}.conf 形式。Machine ID（/etc/machine-id に保存）をプレフィックスに使うことで、複数Linuxマルチブート時の競合を回避します。

実行コマンド：

$ sudo sh -c 'cat /boot/loader/entries/*5.14*.conf'

実行結果：

title AlmaLinux (5.14.0-570.12.1.el9_6.x86_64) 9.6 (Sage Margay)
version 5.14.0-570.12.1.el9_6.x86_64
linux /vmlinuz-5.14.0-570.12.1.el9_6.x86_64
initrd /initramfs-5.14.0-570.12.1.el9_6.x86_64.img
options root=/dev/mapper/almalinux-root ro resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap
grub_users $grub_users
grub_arg --unrestricted
grub_class almalinux

title（GRUBメニュー表示名）、linux（カーネル本体パス）、initrd（初期RAMディスクパス）、options（カーネル引数）が1ファイル1エントリで管理されます。シンプルで構造化されています。

2.4 grub.cfg の再生成

/etc/default/grub を変更したら grub2-mkconfig でgrub.cfgを再生成します（本記事では実行しません。コマンド形のみ提示）。

$ sudo grub2-mkconfig -o /boot/grub2/grub.cfg

第3章：grubby — RHEL系の推奨ツール

BLS方式採用後、AlmaLinux/RHEL/Rocky系では grubby がカーネル管理の公式推奨ツールになりました。grub.cfg やBLSエントリを直接いじらず、コマンドで安全に追加・削除できます。

3.1 既定カーネルの確認

実行コマンド：

$ sudo grubby --default-kernel

実行結果：

/boot/vmlinuz-5.14.0-570.12.1.el9_6.x86_64

3.2 既定カーネルの詳細

実行コマンド：

$ sudo grubby --info=DEFAULT

実行結果：

index=0
kernel="/boot/vmlinuz-5.14.0-570.12.1.el9_6.x86_64"
args="ro resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap"
root="/dev/mapper/almalinux-root"
initrd="/boot/initramfs-5.14.0-570.12.1.el9_6.x86_64.img"
title="AlmaLinux (5.14.0-570.12.1.el9_6.x86_64) 9.6 (Sage Margay)"
id="9675dfbf54f14d9ebfa704b59841fc8f-5.14.0-570.12.1.el9_6.x86_64"

カーネル本体・引数・rootデバイス・initramfs・タイトル・エントリIDが一覧できます。

3.3 カーネルパラメータの永続追加（コマンド形のみ）

例：全カーネルに quiet（起動メッセージ抑制）を追加するコマンド形：

$ sudo grubby --update-kernel=ALL --args="quiet"

削除するコマンド形：

$ sudo grubby --update-kernel=ALL --remove-args="quiet"

本記事では起動状態を変えないため実行しません。実機で試す際は事前にスナップショットを取得し、必ず --info=DEFAULT で結果を確認してください。typo は起動失敗の原因になります。

第4章：カーネルと initramfs

4.1 /boot ディレクトリの構成

カーネルや initramfs は /boot 配下に置かれます。

実行コマンド：

$ ls -la /boot/

実行結果（抜粋）：

合計 160816
-rw-------.  1 root root  9431032  5月 13  2025 System.map-5.14.0-570.12.1.el9_6.x86_64
-rw-r--r--.  1 root root   229167  5月 13  2025 config-5.14.0-570.12.1.el9_6.x86_64
drwx------.  3 root root     4096  1月  1  1970 efi
drwx------.  3 root root       50  5月  9 18:47 grub2
-rw-------.  1 root root 85047700  5月  9 18:46 initramfs-0-rescue-9675dfbf54f14d9ebfa704b59841fc8f.img
-rw-------.  1 root root 40102961  5月  9 18:47 initramfs-5.14.0-570.12.1.el9_6.x86_64.img
drwxr-xr-x.  3 root root       21  5月  9 18:45 loader
-rwxr-xr-x.  1 root root 14919040  5月  9 18:46 vmlinuz-0-rescue-9675dfbf54f14d9ebfa704b59841fc8f
-rwxr-xr-x.  1 root root 14919040  5月 13  2025 vmlinuz-5.14.0-570.12.1.el9_6.x86_64

ファイル種別の整理：

• vmlinuz-* — 圧縮済みのカーネル本体（実体は ELF ではなく bzImage）
• initramfs-*.img — 初期RAMディスク（cpio + gzip圧縮アーカイブ）
• System.map-* — カーネルシンボルテーブル
• config-* — カーネルビルド時の設定
• -rescue- 付きのエントリ — レスキュー用カーネル（同じバージョンの控え）

4.2 initramfs の中身

initramfs は、カーネル起動直後に展開される最小限のファイルシステム。本物のルートFS（多くは LVM や暗号化ボリューム）をマウントするためのドライバ・ツールが詰まっています。lsinitrd で中を覗けます。

実行コマンド：

$ sudo lsinitrd | head -30

実行結果（抜粋）：

Image: /boot/initramfs-5.14.0-570.12.1.el9_6.x86_64.img: 39M
========================================================================
Early CPIO image
========================================================================
drwxr-xr-x   3 root     root            0 Mar 31  2025 .
-rw-r--r--   1 root     root            2 Mar 31  2025 early_cpio
drwxr-xr-x   3 root     root            0 Mar 31  2025 kernel
drwxr-xr-x   3 root     root            0 Mar 31  2025 kernel/x86
drwxr-xr-x   2 root     root            0 Mar 31  2025 kernel/x86/microcode
-rw-r--r--   1 root     root       100684 Mar 31  2025 kernel/x86/microcode/AuthenticAMD.bin
========================================================================
Version: dracut-057-87.git20250311.el9_6

Arguments:  -f

dracut modules:
bash
systemd
fips
systemd-initrd
systemd-sysusers
nss-softokn
dbus-broker
dbus
i18n

「Early CPIO image」には CPU マイクロコードが含まれており、CPU バグ修正をカーネル起動前に適用します。「dracut modules」リストは、initramfs に組み込まれたモジュール一覧です。

4.3 ルートファイルシステム構成

ディスクのレイアウトを確認しておきます。

実行コマンド：

$ lsblk

実行結果：

NAME               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                  8:0    0   50G  0 disk
├─sda1               8:1    0  600M  0 part /boot/efi
├─sda2               8:2    0    1G  0 part /boot
└─sda3               8:3    0 48.4G  0 part
  ├─almalinux-root 253:0    0 44.5G  0 lvm  /
  └─almalinux-swap 253:1    0  3.9G  0 lvm  [SWAP]
sr0                 11:0    1 1024M  0 rom

UEFI標準的な3パーティション構成です：

• sda1：ESP（EFI System Partition）— UEFIブートローダ格納
• sda2：/boot — カーネル・initramfs・GRUB2格納
• sda3：LVM物理ボリューム — ルートFSとスワップ

第5章：systemd の起動 — PID 1 の責務

カーネルが initramfs 経由でルートFSをマウントしたら、/sbin/init（実体は /usr/lib/systemd/systemd）が PID 1として起動します。これが Linux で最初のユーザー空間プロセスです。

systemd は default.target（既定では multi-user.target）を起点に、依存関係に基づいて各種サービスを並列起動します。

systemd の動作・unitファイル・ターゲット間の依存関係などの詳細は 次回（第3回 systemdマスター講座）で詳しく扱います。本記事では「カーネルから制御を受け取る最終ステージ」という位置付けの理解で十分です。

第6章：起動ログを読む

サーバーが想定通り起動したか／何時間かかったか／どこで時間を食っているか、を後追いで確認するのは現場の必須スキルです。3つのコマンドで覚えてください。

6.1 journalctl -b — 現在ブートのログ

実行コマンド：

$ journalctl -b | head -5

実行結果（抜粋）：

 5月 09 19:04:09 linuc-alma kernel: Linux version 5.14.0-570.12.1.el9_6.x86_64 (mockbuild@x64-builder02.almalinux.org) (gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5), GNU ld version 2.35.2-63.el9) #1 SMP PREEMPT_DYNAMIC Tue May 13 06:11:55 EDT 2025
 5月 09 19:04:09 linuc-alma kernel: The list of certified hardware and cloud instances for Red Hat Enterprise Linux 9 can be viewed at the Red Hat Ecosystem Catalog, https://catalog.redhat.com.
 5月 09 19:04:09 linuc-alma kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-570.12.1.el9_6.x86_64 root=/dev/mapper/almalinux-root ro resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap
 5月 09 19:04:09 linuc-alma kernel: BIOS-provided physical RAM map:
 5月 09 19:04:09 linuc-alma kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable

3行目に注目してください。Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-... — これがGRUB2からカーネルに渡された引数です。「実際にどのカーネルで／どんなパラメータで起動したか」が一発で分かります。

6.2 journalctl –list-boots — ブート履歴

実行コマンド：

$ journalctl --list-boots

実行結果：

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
  0 44ba742031594ff8a3b3facbf1a6ee39 Sat 2026-05-09 19:04:09 JST Sat 2026-05-09 21:20:50 JST

IDX=0 が現在のブート、IDX=-1 が前回ブート、と数えます。前回のブートログを見たければ：

$ journalctl -b -1     # 1つ前のブート
$ journalctl -b -2     # 2つ前のブート

BOOT ID 直接指定もできます：journalctl -b 44ba7420...

6.3 dmesg — カーネルリングバッファ

dmesg はカーネルが起動初期に出力したログを表示します。AlmaLinux 9 では journalctl と内容がほぼ重複しますが、表示形式が違います。

実行コマンド：

$ sudo dmesg | head -5

実行結果（抜粋）：

[    0.000000] Linux version 5.14.0-570.12.1.el9_6.x86_64 (mockbuild@x64-builder02.almalinux.org) (gcc (GCC) 11.5.0 20240719 (Red Hat 11.5.0-5), GNU ld version 2.35.2-63.el9) #1 SMP PREEMPT_DYNAMIC Tue May 13 06:11:55 EDT 2025
[    0.000000] The list of certified hardware and cloud instances for Red Hat Enterprise Linux 9 can be viewed at the Red Hat Ecosystem Catalog, https://catalog.redhat.com.
[    0.000000] Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-570.12.1.el9_6.x86_64 root=/dev/mapper/almalinux-root ro resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable

左の [ 0.000000] はカーネル起動からの経過秒数（秒.マイクロ秒）。journalctl が実時刻を出すのに対し、dmesgはカーネル時刻基準です。「起動○秒目に何が起きたか」を見るときは dmesg が便利です。

6.4 systemd-analyze — 起動時間分析

「うちのサーバーは起動が遅い」と言われたら、systemd-analyze で原因を切り分けます。

実行コマンド：

$ systemd-analyze

実行結果：

Startup finished in 513ms (kernel) + 1.538s (initrd) + 12.545s (userspace) = 14.597s
multi-user.target reached after 12.530s in userspace.

kernel・initrd・userspace の3段階それぞれの所要時間が出ます。userspace段階で時間がかかっている場合はサービスのどれかが遅い、ということが分かります。

遅いサービスを特定するには blame：

実行コマンド：

$ systemd-analyze blame | head -5

実行結果（抜粋）：

10.046s rsyslog.service
 1.841s sys-subsystem-net-devices-eth0.device
 1.841s sys-devices-LNXSYSTM:00-LNXSYBUS:00-ACPI0004:00-MSFT1000:00-81a90cd5\x2dbdf7\x2d4f98\x2db5f2\x2d6770cfdeba7d-net-eth0.device
 1.826s dev-disk-by\x2dpartuuid-8aa53884\x2d913a\x2d4dd8\x2daf1c\x2d374648ec6bfc.device
 1.826s dev-disk-by\x2did-wwn\x2d0x6002248030aadd0678dcb142b3e775a3\x2dpart3.device

この検証環境では rsyslog.service が10秒もかかっています。本番でこの値だと「ログ転送先が応答しない」「DNS逆引きでブロック」などの可能性を疑います。

現場での使いどころ

• カーネル更新後の起動失敗対応：再起動でハングしたら、UEFI画面でレスキューカーネル選択 → 旧カーネルで起動 → grubby --info=ALL で新旧比較 → 問題のあるパラメータ削除
• パフォーマンス調査の起点：「夜間バッチが遅い」と言われた → systemd-analyze で起動状況確認 → 必要ならカーネル引数で noapic 等を試す
• セキュリティパラメータの永続化：grubby --update-kernel=ALL --args="audit=1" で監査ログを必ず有効化
• デバッグ用カーネルパラメータ：障害時に systemd.unit=rescue.target や single をブート時に追加してシングルユーザーモード突入
• クラウド環境でも同じ知識：AWS EC2、Azure VM のいずれも UEFI + GRUB2 + systemd でほぼ同じ。OSレベルの知識は移植可能

やってみよう

検証環境（linuc-alma）で以下を順番に実行してください。すべて読み取り系のため安全です。

理解度チェック

○か×で答えてください。回答と解説は次回冒頭で振り返ります。

1. UEFIブートエントリは /etc/efibootmgr.conf に保存される。
2. /boot/grub2/grub.cfg は人が直接編集すべきファイルである。
3. AlmaLinux 9 では BLS（Boot Loader Spec）方式が既定で、カーネルエントリは /boot/loader/entries/*.conf に保存される。
4. journalctl -b -1 は前回ブートのログを表示する。
5. systemd-analyze blame はサービス別の起動所要時間をランキング表示する。

次回予告

第3回は「systemdマスター講座：サービス管理・unitファイル・ターゲット」です。今回最後に登場した「PID 1 として起動する systemd」の中身に入ります。systemctl でのサービス操作、unit ファイルの構造、target 間の依存関係まで—現代のLinux運用の中核となる知識を体系的に学んでいきます。

LinuC 101 試験対策シリーズ 全12回

• 第1回 Linuxの起動・接続・停止：systemctl・login・shutdownの基本
• 第2回 ブートプロセスの仕組み：BIOS/UEFI → GRUB → systemd の流れ（本記事）
• 第3回 systemdマスター講座：サービス管理・unitファイル・ターゲット
• 第4回 プロセス管理とハードウェア基礎（ps, top, lsblk, lspci, lsusb）
• 第5回 仮想マシンとコンテナの基礎：KVM・Docker・Podman 入門
• 第6回 パッケージ管理マスター：dnf / apt / rpm / dpkg の実践
• 第7回 ファイル操作の実践：cp, mv, find, リンク, FHS
• 第8回 パーミッション・所有者・特殊権限（SUID/SGID/Sticky）
• 第9回 コマンドライン・リダイレクト・パイプの基礎
• 第10回 テキスト処理の三種の神器：grep / sed / awk + 正規表現
• 第11回 vi/vim 入門：現場で使えるエディタ操作
• 第12回 ディスク・パーティション・ファイルシステム（fdisk, mkfs, mount, LVM）