Linuxの起動シーケンスを徹底解説｜BIOS/UEFIからsystemd起動までの仕組み

はじめに
Linux起動シーケンス概要
Linux起動シーケンス詳細
Linuxの起動処理に関するログ確認
1. UEFIおよびGRUBの起動
2. Linuxカーネルの起動
Linux起動に関するトラブル事例
参考情報
1. BIOSとUEFIの違い
まとめ

はじめに

Linuxサーバの電源ボタンを押してからログイン画面が表示されるまでの間には、多くのコンポーネントが連携しながら動作しています。

普段は意識することが少ないものの、起動の仕組みを理解しておくと、サーバが起動しないトラブルや性能問題の調査に役立ちます。また、Linuxカーネルやシステム管理の理解を深めるうえでも重要な知識です。

本記事では、UEFI、GRUB、Linuxカーネル、initramfs、systemdといった各コンポーネントの役割を追いながら、Linuxがどのように起動するのかを詳しく解説します。

Linux起動シーケンス概要

Linuxの起動は以下の流れで進みます。まずは大まかな流れを理解してください。

Linux起動シーケンス詳細

それでは、Linuxが起動するまでに各コンポーネントがどんな処理を実施しているか、詳細に説明していきます。

電源投入

サーバの電源を投入すると、電源回路が各部品に電力を供給します。その後、CPUがリセット状態から解除されて命令実行を開始され、BIOS/UEFIファームウェアのコードが実行されます。

BIOS/UEFI

サーバの電源を投入すると、最初に実行されるのはLinuxカーネルやブートローダではありません。まず、マザーボード上のフラッシュメモリに保存されているUEFI（Unified Extensible Firmware Interface）が起動します。UEFIの役割は、OSを起動するための準備を行い、最終的にブートローダへ制御を引き渡すことです。

ハードウェア初期化

最初にUEFIは、CPUやストレージコントローラ、PCIデバイスなどのハードウェアを初期化します。電源投入直後のハードウェアはまだ利用可能な状態ではないため、UEFIが各デバイスを設定し、システムが正常に動作できる環境を整えます。

RAM（メモリ）初期化

UEFIはRAM（メモリ）を利用可能な状態にします。以降に実行されるブートローダやLinuxカーネルは、ディスク上のプログラムをそのまま実行するのではなく、一度RAMへ読み込んでから実行されます。そのため、RAMの初期化は起動シーケンスにおいて非常に重要な処理です。

自己診断 (POST)

続いて、POST（Power-On Self Test）と呼ばれる自己診断を実行します。POSTでは、CPUやメモリ、ストレージなどの主要コンポーネントが正常に認識できるかを確認します。メモリ故障時にビープ音が鳴るのは、このPOSTの段階で異常が検知されているためです。

起動デバイス検知

次に、UEFIは設定された起動順序に従って起動デバイスを探索します。例えば、NVMe SSD、SATA SSD、USBメモリ、PXEブートなどの候補から、起動可能なデバイスを探します。

ブートローダのメモリロード

　起動デバイスが見つかると、UEFIはEFI System Partition（ESP）内に保存されているブートローダ（Linux OSをメモリに読み込んで起動するプログラム）を読み込みます。Linux環境では一般的にGRUB2が利用されており、UEFIはGRUB2の実行ファイルをディスクからメモリ（RAM）へロードします。

ここまでの処理が完了すると、UEFIの役割は終了し、制御はGRUB2へ引き渡されます。その後、GRUB2がLinuxカーネルとinitramfsをメモリへロードし、Linuxの起動処理が開始されます。

ブートローダ（GRUB2）

Linux環境では一般的にGRUB2（GRand Unified Bootloader Version 2）が利用されています。GRUBはLinuxカーネルを起動するための橋渡し役です。主な役割は以下のとおりです。

起動するカーネルの選択
カーネルパラメータの設定
initramfsの読み込み
複数OS環境でのOS選択

GRUBの設定情報は主にgrub.cfgに保存されています。OSアップデートによってカーネルが追加されると、GRUBメニューも更新されます。

grub.cfgの設定値をみてみましょう。私の環境では /etc/default/grub に設定ファイルが作成されています。/etc/default/grub は grub.cfg を生成するための元設定ファイル

[root@localhost ~]# 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="crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
[root@localhost ~]#

特に確認したいのは、GRUB_CMDLINE_LINUX となります。本項目は、GRUBがLinuxカーネルを起動する際に渡すカーネルパラメータを定義する設定項目です。

Linuxカーネルは起動時に様々な設定情報を必要とします。どのデバイスをルートファイルシステムとして利用するのか、kdump用のメモリをどれだけ確保するのか、どの機能を有効化するのかといった情報です。例えば、rd.lvm.lv=almalinux/root、rd.lvm.lv=almalinux/swap の設定により、VG：almalinux、LV：root, swap を利用して起動する動作となります。

また、起動時にeキーを押すことで、一時的にカーネルパラメータを変更することもできます。トラブルシューティング時には頻繁に利用される機能です。

Linuxカーネル

GRUBによってLinuxカーネルがメモリ上へロードされると、OS本体の初期化処理が始まります。

ここでいう「初期化」とは、各機能を利用できる状態にするための準備処理を指します。例えば、メモリ管理機能であれば利用可能なメモリ領域を把握し、プロセス管理機能であればプロセスを管理するための内部データ構造を準備します。初期化が完了することで、LinuxはOSとして必要な機能を利用できるようになります。

LinuxカーネルはOSの中核となるプログラムであり、CPU・メモリ・デバイスなどのハードウェア資源を管理します。Linuxカーネルは以下のような基本機能を初期化します。

CPU管理
メモリ管理
プロセス管理
割り込み制御
スケジューラ
デバイス管理

さらにPCIデバイスの検出を行い、ストレージやネットワークアダプタなどを認識します。例えば以下のようなデバイスが検出されます。

SCSIディスク
SATAディスク
NVMe SSD
NIC
USBデバイス

initramfs

カーネル初期化の次に登場するのがinitramfsです。

initramfs（Initial RAM Filesystem）は、メモリ上に展開される一時的なルートファイルシステムです。カーネルは起動直後、まだ本来のルートファイルシステムへアクセスできないため、まずinitramfsが起動してルートファイルシステムへアクセスするための準備を行います。

具体的には以下の処理を実施します。

ストレージドライバのロード
RAID構成の認識
Device Mapperの初期化
LVMの認識
Multipathの認識
ルートファイルシステムの探索

特に商用システムではLVMやMultipathが利用されることが多く、initramfsはそれらを利用可能な状態にしてから本番環境へ処理を引き継ぎます。このため、initramfsが破損するとKernel Panicが発生し、OSが起動できなくなることがあります。

ルートファイルシステム

必要なストレージ構成が認識されると、本来利用するルートファイルシステムがマウントされます。ここで処理の主体はinitramfsから実際のルートファイルシステムへ移行します。この切り替えにはswitch_rootという仕組みが利用されます。これにより、一時環境であるinitramfsの役目は終了し、本番のLinuxシステムへ制御が渡されます。ここから先は通常のファイルシステム構造が利用可能になります。

systemd起動

ルートファイルシステムの準備が完了すると、最初のユーザ空間プロセスが起動します。現在の主要なLinuxディストリビューションではsystemdが利用されています。systemdはPID 1として起動します。PIDとはプロセスIDのことであり、PID 1はLinux全体の親プロセスです。

systemdは以下のような役割を持っています。

サービス管理
依存関係管理
ログ管理
マウント管理
システム状態管理

Linux起動後に動作するほぼすべてのサービスは、systemdによって管理されています。
現場では init というワードが使われることがあります。以下の定義になりますので覚えておいてください。

init = 「最初に起動するPID 1プロセス」の総称
systemd = initシステムの実装のひとつ

各種サービス起動

systemdは設定されたターゲットに従ってサービスを起動します。ターゲットとは、従来のランレベルに相当する概念です。代表的なターゲットには以下があります。

rescue.target
単一ユーザモード
multi-user.target
テキストログイン環境
graphical.target
GUI環境

systemdは依存関係を解析しながら、必要なサービスを並列起動します。例えば以下のようなサービスが起動されます。

NetworkManager
sshd
chronyd
firewalld
監視エージェント
データベース
Webサーバ

以上がLinux起動の一連の流れでした。ここまでくれば sshd が起動しているので、ユーザからSSH接続してログイン可能となります。

Linuxの起動処理に関するログ確認

VirtualBox上で構築したAlmaLinux9において、ログを確認して実際に起動する流れをみてみましょう。

UEFIおよびGRUBの起動

ただし、UEFIやGRUBはLinuxカーネルより前に実行されるため、通常の dmesg や journalctl には記録されません。そのため、Linux上で確認できる最初のログはカーネル起動を示すログからになります。

一方で、/proc/cmdline や efibootmgr -v を確認することで、GRUBやUEFIが起動処理に関与した痕跡を確認できますので、確認してみましょう。

/proc/cmdline はLinuxカーネルが起動時に受け取ったカーネルパラメータを確認するためのファイルです。catコマンドで /proc/cmdline の内容を確認してみましょう。

[root@localhost ~]# cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-570.12.1.el9_6.x86_64 root=/dev/mapper/almalinux-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/almalinux-swap rd.lvm.lv=almalinux/root rd.lvm.lv=almalinux/swap
[root@localhost ~]#

「BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-570.12.1.el9_6.x86_64」の出力により、GRUBがロードしたLinuxカーネルの情報が分かります。

次は efibootmgr -v コマンドを実行してみましょう。UEFIに登録されている起動エントリと、そのエントリが参照するEFIプログラムの場所を表示することが可能です。

[root@localhost ~]# efibootmgr -v
BootCurrent: 0004
Timeout: 0 seconds
BootOrder: 0004,0000,0001,0002,0003
Boot0000* UiApp FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(462caa21-7614-4503-836e-8ab6f4662331)
Boot0001* UEFI VBOX CD-ROM VB2-01700376         PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0)N.....YM....R,Y.
Boot0002* UEFI VBOX HARDDISK VBa8a86760-33611b8a        PciRoot(0x0)/Pci(0xd,0x0)/Sata(0,65535,0)N.....YM....R,Y.
Boot0003  EFI Internal Shell    FvVol(7cb8bdc9-f8eb-4f34-aaea-3ee4af6516a1)/FvFile(7c04a583-9e3e-4f1c-ad65-e05268d0b4d1)
Boot0004* AlmaLinux     HD(1,GPT,6e652488-b850-40f2-901e-9f78c15f4de4,0x800,0x12c000)/File(\EFI\almalinux\shimx64.efi)
[root@localhost ~]#

今回の環境では、以下のようなエントリが登録されていました。

BootCurrent: 0004
BootOrder: 0004,0000,0001,0002,0003

Boot0004* AlmaLinux
HD(1,GPT,…)/File(\EFI\almalinux\shimx64.efi)

この情報から、現在のシステムは Boot0004 という起動エントリを利用して起動していることが分かります。

また、BootOrder には UEFI が起動時に参照する優先順位が記録されており、最初に Boot0004 が試行されます。Boot0004 の内容を見ると、UEFI は GPT ディスク上の EFI System Partition（ESP）に保存されている以下のプログラムを実行するよう設定されています。

\EFI\almalinux\shimx64.efi

この shimx64.efi は Secure Boot に対応するためのブートローダであり、その後 GRUB を起動します。

Linuxカーネルの起動

それでは、Linuxカーネルの起動について見ていきましょう。

Linuxの起動ログを確認するには、journalctl -b -o short-monotonic コマンドを利用します。-b は現在の起動分のログのみを表示するオプションで、-o short-monotonic はシステム起動からの経過時間を付与してログを表示する形式です。これにより、「Linuxカーネルの起動」「デバイス認識」「systemdによるサービス起動」といった一連の処理が、起動後何秒で実行されたのかを時系列で確認できます。

主要なログにしぼって順番に見ていきましょう。

UEFI→GRUB→Linuxカーネルへの制御移譲

[root@localhost ~]# journalctl -b -o short-monotonic
[    0.000000] localhost 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 PREE>

最初に現れるログです。UEFI→GRUB→Linuxカーネルへ制御の移譲が完了し、Linuxカーネルが実行を開始したことを示しています。

[    0.000000] localhost kernel: Command line: BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.14.0-570.12.1.el9_6.x86_64 root=/dev/mapper/almalinux-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper>

これはGRUBがカーネルへ渡したパラメータです。/proc/cmdline にも同じ内容が表示されていましたね。

メモリ初期化

[    0.000000] localhost kernel: BIOS-provided physical RAM map:
[    0.000000] localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x000000007e1b6fff] usable
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007e1b7000-0x000000007e1fffff] reserved
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007e200000-0x000000007eceefff] usable
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007ecef000-0x000000007ef6efff] reserved
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007ef6f000-0x000000007ef7efff] ACPI data
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007ef7f000-0x000000007effefff] ACPI NVS
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007efff000-0x000000007f36afff] usable
[    0.000000] localhost kernel: BIOS-e820: [mem 0x000000007f36b000-0x000000007ffeffff] reserved
[    0.000000] localhost kernel: BIOS-e820: [mem 0x00000000ffc00000-0x00000000ffffffff] reserved

UEFI/BIOSから受け取ったメモリマップです。
Linuxカーネルは、利用可能なRAM、予約領域を把握し、メモリ管理機能を初期化しています。

UEFI起動確認

[    0.000000] localhost kernel: efi: EFI v2.7 by EDK II
[    0.000000] localhost kernel: efi: ACPI=0x7ef7e000 ACPI 2.0=0x7ef7e014 SMBIOS=0x7effd000 MOKvar=0x7ecfa000
[    0.000000] localhost kernel: efi: Remove mem115: MMIO range=[0xffc00000-0xffffffff] (4MB) from e820 map

UEFI環境で起動していることが確認できます。

デバイス認識

[    2.562044] localhost kernel: device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
[    2.562758] localhost kernel: device-mapper: uevent: version 1.0.3
[    2.563275] localhost kernel: device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev

Device Mapperが初期化されています。

[    2.596498] localhost systemd[1]: Finished dracut pre-udev hook.

dracutがudev起動前の準備を完了したことを示しています。

[    2.604511] localhost systemd[1]: Starting Rule-based Manager for Device Events and Files...
[    2.621782] localhost systemd-udevd[341]: Using default interface naming scheme 'rhel-9.0'.
[    2.630242] localhost systemd[1]: Started Rule-based Manager for Device Events and Files.
[    2.630318] localhost systemd[1]: dracut pre-trigger hook was skipped because no trigger condition checks were met.

udevが起動していることが確認できます。

[    2.630334] localhost systemd[1]: Starting Coldplug All udev Devices...
[    2.754276] localhost systemd[1]: Finished Coldplug All udev Devices.
[    2.754339] localhost systemd[1]: nm-initrd.service was skipped because of an unmet condition check (ConditionPathExists=/run/NetworkManager/initrd/neednet).
[    2.754357] localhost systemd[1]: Reached target Network.
[    2.754372] localhost systemd[1]: nm-wait-online-initrd.service was skipped because of an unmet condition check (ConditionPathExists=/run/NetworkManager/initrd/neednet).
[    2.777130] localhost systemd[1]: Starting dracut initqueue hook...

現在出力されている全デバイスをスキャンしています。また、Starting dracut initqueue hook… は、initramfs内のdracutがルートファイルシステムの探索を開始したことを示すログです。dracutはLVMやストレージデバイスの認識が完了するのを待ちながら、起動に必要なルートファイルシステムを探します。ルートファイルシステムが見つかると、その後 switch_root により本来のOS環境へ制御が引き渡されます。

仮想ディスク認識

[    3.282970] localhost kernel: libata version 3.00 loaded.
[    3.285354] localhost kernel: ata_piix 0000:00:01.1: version 2.13
[    3.311944] localhost kernel: ahci 0000:00:0d.0: version 3.0

ディスク制御用のデバイスドライバをロードしています。

[    3.538289] localhost kernel: ata2.00: ATAPI: VBOX CD-ROM, 1.0, max UDMA/133
[    3.542586] localhost kernel: scsi 1:0:0:0: CD-ROM            VBOX     CD-ROM           1.0  PQ: 0 ANSI: 5

VirtualBoxの仮想CD-ROMドライブを認識しています。インストールメディアやISOイメージが接続されている場合はここに表示されます。

    3.721747] localhost kernel: ata3.00: ATA-6: VBOX HARDDISK, 1.0, max UDMA/133

LinuxカーネルがVirtualBoxの仮想ハードディスクを検出していることを示す重要なログです。

[    3.859265] localhost kernel: sd 2:0:0:0: [sda] 41943040 512-byte logical blocks: (21.5 GB/20.0 GiB)
[    3.859701] localhost kernel: sd 2:0:0:0: [sda] Write Protect is off
[    3.860028] localhost kernel: sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    3.860039] localhost kernel: sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    3.860353] localhost kernel: sd 2:0:0:0: [sda] Preferred minimum I/O size 512 bytes
[    3.922419] localhost kernel:  sda: sda1 sda2 sda3
[    3.923033] localhost kernel: sd 2:0:0:0: [sda] Attached SCSI disk

Linuxカーネルがハードディスクを/dev/sdaとして認識したことを示しています。また、/dev/sda1、/dev/sda2、/dev/sda3のパーティションも検出しています。

ルートファイルシステムのマウント

[    5.280958] localhost dracut-initqueue[438]: Scanning devices sda3  for LVM logical volumes almalinux/root
[    5.281254] localhost dracut-initqueue[438]: almalinux/swap
[    5.314490] localhost dracut-initqueue[438]:   almalinux/root linear
[    5.314573] localhost dracut-initqueue[438]:   almalinux/swap linear
[    5.376705] localhost systemd[1]: Found device /dev/mapper/aStarting Switch Rootlmalinux-root.
[    5.378792] localhost systemd[1]: Reached target Initrd Root Device.
[    5.453402] localhost systemd[1]: Found device /dev/mapper/almalinux-swap.
[    5.470491] localhost systemd[1]: Starting Resume from hibernation using device /dev/mapper/almalinux-swap...
~~Truncated~~
[    5.505293] localhost systemd[1]: Finished dracut initqueue hook.

このログでは、initramfs内のdracutがLVMを認識し、ルートファイルシステムである /dev/mapper/almalinux-root を発見しています。Linuxはルートファイルシステムが見つかるまで起動を続行できないため、この処理は起動シーケンスの中でも特に重要な段階です。また、スワップ領域も認識され、ハイバネーションからの復帰が必要かどうかの確認が行われています。

[    5.511307] localhost systemd[1]: Starting File System Check on /dev/mapper/almalinux-root...
[    5.555762] localhost systemd-fsck[484]: /usr/sbin/fsck.xfs: XFS file system.
[    5.559914] localhost systemd[1]: Finished File System Check on /dev/mapper/almalinux-root.

ルートファイルシステムの整合性を確認しています。

[    5.562343] localhost systemd[1]: Mounting /sysroot...
[    6.003953] localhost kernel: SGI XFS with ACLs, security attributes, scrub, quota, no debug enabled
[    6.016107] localhost kernel: XFS (dm-0): Mounting V5 Filesystem b3755490-b910-4bcd-8e47-a0037f2f09ab
[    6.074677] localhost kernel: XFS (dm-0): Ending clean mount
[    6.088476] localhost systemd[1]: Mounted /sysroot.

initramfsがルートファイルシステムをマウントする処理を示しています。今回の環境では、LVM上の論理ボリューム /dev/mapper/almalinux-root に格納されたXFSファイルシステムが /sysroot にマウントされています。

switch_root（OS本体のルートファイルシステムへの制御移譲）

[    6.377428] localhost systemd[1]: Starting Switch Root...
[    6.401897] localhost systemd[1]: Switching root.

initramfsから本来のルートファイルシステムへ切り替える処理を示しています。起動直後のLinuxは、メモリ上に展開された最小構成のinitramfs上で動作しています。ルートファイルシステムの認識とマウントが完了すると、switch_root によってOS本体が格納されたルートファイルシステムへ制御が移されます。この処理を境に、Linuxは本格的なOS起動フェーズへ移行します。

systemd起動

[    6.857481] localhost systemd[1]: systemd 252-51.el9.alma.1 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT -QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK +XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified)

ルートファイルシステムへの切り替え（switch_root）が完了し、本番環境のsystemdがPID 1として起動したことを示すログです。systemdはLinuxにおける初期プロセス（init）であり、OS起動後のサービス管理を担当します。このログが表示されると、Linuxはカーネルとinitramfsによる初期化フェーズを終え、本格的なOS起動フェーズへ移行したことが分かります。

[    8.053196] localhost systemd[1]: Starting Remount Root and Kernel File Systems
[    8.403525] localhost systemd[1]: Finished Remount Root and Kernel File Systems.

ルートファイルシステムが再マウントされています。

[ 9.000367] localhost systemd[1]: Started Rule-based Manager for Device Events and Files.

管理機能の起動

[ 9.000367] localhost systemd[1]: Started Rule-based Manager for Device Events and Files.

デバイス管理サービスが起動されています。

[ 13.401255] localhost systemd[1]: Starting Network Manager...

NetworkManagerが起動されています。

SSH起動

[ 15.186258] localhost.localdomain systemd[1]: Starting OpenSSH server daemon...

OpenSSHが起動され、SSH接続を受け付ける準備が完了しています。

マルチユーザモードへの到達完了（Linux起動完了）

[ 17.002933] localhost.localdomain systemd[1]: Reached target Multi-User System.

systemdがマルチユーザモード（multi-user.target）への到達を完了したことを示すログです。これはネットワークやSSHなどの主要なサービスが起動し、システムが通常運用可能な状態になったことを意味します。GUIを使用しないサーバ環境では、このログが表示されるとLinuxの起動がほぼ完了したと考えることができます。

Linux起動に関するトラブル事例

Linuxの起動シーケンスを理解しておくと、起動障害が発生した際に問題箇所を切り分けやすくなります。起動処理は前述の通り「UEFI → GRUB2 → Linuxカーネル → initramfs → ルートファイルシステム → systemd」という流れで進むため、どの段階で停止しているかを確認することが重要です。

GRUB2が起動しない

電源投入後にGRUBメニューが表示されない場合は、EFI System Partition（ESP）の破損やGRUB関連ファイルの消失が考えられます。

例えば、誤ってEFIパーティション内のファイルを削除した場合や、ブートエントリが破損した場合には、OSを起動できなくなります。このような場合はインストールメディアからレスキューモードで起動し、GRUB2の再インストールや設定の再生成を行います。

Linuxカーネルが起動しない

GRUBメニューは表示されるものの、カーネルロード後に停止する場合は、カーネルイメージの破損や不適切なカーネルパラメータが原因である可能性があります。

GRUBメニューで「e」キーを押すと、一時的にカーネルパラメータを編集できます。問題調査時には rhgb quiet を削除し、起動ログを表示させることで原因を特定しやすくなります。

また、複数のカーネルがインストールされている環境では、旧バージョンのカーネルを選択して起動できる場合があります。

initramfsで停止する

比較的よく遭遇するトラブルです。
例えば、LVMやMultipathの設定変更後に initramfs の再生成を行わなかった場合、起動時にルートファイルシステムを発見できず、dracut（Linux起動時に利用されるinitramfsを生成するツール）のシェルへ移行することがあります。

代表的なメッセージとしては以下のようなものがあります。

Warning: /dev/mapper/root does not exist
Warning: /dev/almalinux/root does not exist
Entering emergency mode

この場合は、GRUBのカーネルパラメータやLVM構成を確認し、必要に応じて dracut コマンドでinitramfsを再生成します。

ファイルシステムをマウントできない

ストレージ障害や /etc/fstab の設定ミスが原因で発生します。

例えば、存在しないUUIDやデバイス名を /etc/fstab に記載すると、起動時にマウント処理が失敗し、Emergency Modeへ移行する場合があります。起動後に突然発生するトラブルとしては比較的多く、システム変更作業後は /etc/fstab の記述内容を十分に確認することが重要です。

systemdで停止する

ルートファイルシステムのマウントまでは成功しているものの、サービス起動時に問題が発生するケースです。
例えば、以下のような原因が考えられます。

NetworkManagerの設定不整合
NFSマウント先への接続失敗
依存サービスの起動失敗
誤ったsystemd Unitファイルの配置

この場合は、レスキューモードで起動するか、Emergency Modeからログを確認してみてください。

参考情報

BIOSとUEFIの違い

BIOSとUEFIの最も大きな違いは、OSを起動する仕組みと対応できるディスク構成です。

BIOSはMBR（Master Boot Record）からブートローダーを起動する古い方式であり、ディスク容量やパーティション数に制限があります。一方、UEFIはGPT（GUID Partition Table）と呼ばれる新しいパーティション方式を利用でき、大容量ディスクへの対応やセキュリティ機能の強化など、多くの改善が行われています。

現在のサーバーやPCでは、ほぼすべてがUEFIを採用しており、Linuxサーバーの構築でもUEFI環境が一般的です。

項目	BIOS	UEFI
登場時期	1980年代	2000年代
ブート方式	MBRから起動	EFI System Partition（ESP）から起動
パーティション形式	MBR	GPT
最大ディスク容量	約2TB	9.4ZB（理論値）
パーティション数	最大4個（プライマリ）	128個以上
設定画面	テキストベース	GUI対応
Secure Boot	非対応	対応
起動速度	比較的遅い	比較的高速
ネットワーク機能	限定的	豊富
現在の利用状況	レガシー環境中心	現在の標準

まとめ

Linuxの起動シーケンスは、一見すると複雑に見えますが、大きく分けると「UEFI → GRUB → Linuxカーネル → initramfs → ルートファイルシステム → systemd」という流れで進みます。Linuxカーネルは以下のような基本機能を初期化します。

起動直後はUEFIがハードウェアを初期化し、GRUBがLinuxカーネルとinitramfsをメモリへロードします。LinuxカーネルはCPUやメモリ、デバイスの初期化を行い、その後initramfsへ制御を引き渡します。initramfsはルートファイルシステムを探索・マウントし、switch_rootによって本来のOS環境へ切り替えます。最後にsystemdが起動し、各種サービスを立ち上げることでシステムが利用可能な状態となります。

また、本記事では実際の起動ログを確認しながら、各フェーズでどのような処理が行われているのかを見てきました。起動トラブルが発生した場合は、「どの段階で処理が停止しているか」を把握することが重要です。例えば、GRUBが表示されない場合はUEFIやブートローダの問題、ルートファイルシステムが認識できない場合はinitramfsやストレージ構成の問題が考えられます。

Linux管理者やインフラエンジニアにとって、起動シーケンスの理解はトラブルシューティングの基礎となります。本記事が、Linuxの起動処理を理解し、障害発生時の切り分けに役立てるきっかけになれば幸いです。