システムの起動

BIOSとUEFI：ファームウェアによる起動の開始

電源を入れた直後、まずマザーボード上のファームウェアであるBIOS（Basic Input/Output System）またはUEFI（Unified Extensible Firmware Interface）が動作します。ファームウェアは、画面やキーボードなどの基本的なハードウェアを初期化し、メモリなどの自己診断（POST、Power-On Self-Test）を行った後、あらかじめ設定された起動デバイスからブートローダを読み込んで実行を引き継ぎます^{UEFIはBIOSより新しい規格で、多くの現行PC・サーバーで採用されています。UEFI環境でも、互換性のためにBIOS相当の起動方式（レガシーBIOSモード）に切り替えられる機種があります。[1]}。

BIOSとUEFIでは、ブートローダを見つけて読み込む方法が異なります。

MBRはパーティションの位置や大きさを表す情報に制約があるため、一般的な512バイトセクターでは利用できるディスク容量が約2TiB（一般に約2TBと表現）までに制限されます。

これに対してGPTは、より広い範囲を表せるため、2TBを超える大容量ディスクを利用できます。

ただし、約2TBという制限はBIOS自体ではなく、主にMBR形式の制限です。BIOSとGPT、またはUEFIとMBRを組み合わせられる場合もありますが、一般にはBIOSではMBR、UEFIではGPTが使用されます。

このように、BIOSではブートローダを段階的に読み込むのに対し、UEFIではEFIシステムパーティション上のファイルを直接実行します。UEFIとGPTの組み合わせは、起動処理を扱いやすくし、大容量ディスクにも対応できます。

ブートローダ：カーネルへの命令とオプションの受け渡し

ブートローダは、ファームウェアから実行を引き継ぎ、ディスク上からLinuxカーネルと後述のinitramfsをメモリへ読み込んで、カーネルに実行を引き渡すプログラムです。現在のLinuxディストリビューションで最も広く使われているブートローダはGRUB 2（GRand Unified Bootloader version 2）です^{出題範囲の用語一覧には「bootloader」という一般的な語のみが挙げられており、特定の製品名は明記されていません。本記事では、実務・学習の両面で広く使われているGRUB 2を具体例として説明します。[2]}。

起動時にブートローダへ共通のコマンドを与える

GRUB 2が表示する起動メニューでは、通常、キーボード操作によっていくつかの操作ができます。

eキーで編集した内容は、その回の起動限りの一時的な変更です。恒久的に変更したい場合は、/etc/default/grubファイルを編集した後、設定を再生成するコマンド（Debian系ではupdate-grub、Red Hat系ではgrub2-mkconfig）を実行する必要があります^{update-grubは多くのDebian系ディストリビューションでgrub-mkconfig -o /boot/grub/grub.cfgを呼び出す簡易コマンドとして提供されています。Red Hat系でのgrub2-mkconfigの出力先は、ディストリビューションのバージョンやBIOS/UEFI起動によって異なるため、使用している環境の設定を確認してください。[3]}。

カーネルへオプションを渡す

GRUB 2の編集画面でlinuxから始まる行、または一部のUEFI向けGRUB実装で用いられるlinuxefiから始まる行の末尾に文字列を追記すると、その内容がカーネルの起動オプション（カーネルパラメータ）としてカーネルに渡されます。

恒久的に反映する場合は、ブートローダの節と同様に/etc/default/grubのGRUB_CMDLINE_LINUX（またはGRUB_CMDLINE_LINUX_DEFAULT）にパラメータを追記してから設定を再生成します。

Secure Boot

Secure Bootは、UEFIがOS起動時にブートローダーなどの電子署名を検証する仕組みです。 信頼された鍵で署名されたプログラムだけを実行し、不正なプログラムの起動を防ぎます。

Linuxを起動するには、Secure Bootに対応した署名済みブートローダーが必要です。 未対応のOSやブートローダーを使用する場合は、UEFIの設定でSecure Bootを無効化することがあります。

カーネルの読み込みとinitramfs

ブートローダは、カーネル本体に加えてinitramfs（initial RAM filesystem）という、圧縮されたファイルの集合もメモリへ読み込みます。initrdは本来はinitramfsとは異なる初期RAMディスクの仕組みを指しますが、initramfsのイメージファイルが慣例的にinitrdという名前で置かれる場合もあります。カーネルは、initramfsの内容を一時的なルートファイルシステムとしてメモリ上に展開してから、本来のルートファイルシステムへの切り替えを行います。

initramfsが必要になる代表的な理由は、カーネルが本来のルートファイルシステムにアクセスするために必要なドライバ（ストレージコントローラのドライバ、LVM・RAID・暗号化ボリュームを扱うためのツール等）が、起動時点ではまだ用意されていない場合があるためです^{出典：openSUSE公式ドキュメント「Introduction to the Boot Process」。initramfsは、これらのドライバやツールを一時的な環境として提供し、本来のルートファイルシステムを認識・マウントできる状態を整えます。[4]}。

必要なドライバの読み込みや、本来のルートファイルシステムを扱うための準備が整うと、initramfs上の/initが本来のルートファイルシステムへ切り替え、本来のルートファイルシステム上のinitを実行します。このとき、通常はPID 1の実行プログラムが置き換わる形で、起動処理が引き継がれます^{出典：openSUSE公式ドキュメント「Introduction to the Boot Process」。同ドキュメントでは、systemdを採用する環境では、initramfs上でも一度systemdが動き、本来のルートファイルシステムへの切り替え後に本来のルートファイルシステム上のsystemdが起動処理を引き継ぐ、という流れが説明されています。[5]}。

init：システムが最初に起動するプロセス

initは、起動処理を担う、PID（プロセスID）が1のプロセスの呼び名です。initramfsを使用する場合、カーネルはまずinitramfs上の/initを起動し、本来のルートファイルシステムへの切り替え後は、その上のinitが起動処理を引き継ぎます。initは、ユーザー空間の他のすべてのプロセスの直接・間接の親となり、システムが動作を続ける限り存在し続けます。「init」という名前は特定の1つのプログラムだけを指すわけではなく、採用している仕組みに応じて実体が異なります。

SysVinitとsystemdの理解

SysVinitは、Unix系OSで伝統的に使われてきた、シェルスクリプトを順番に実行する方式のinit実装です^{SysV init方式のランレベル・/etc/inittab・telinitコマンドの詳細な使い方は「ブートプロセスとsystemd」の技術解説記事で扱っています。[6]}。これに対しsystemdは、サービス間の依存関係をもとに可能な限り並行して起動を進めることや、必要になった時点で初めてサービスを起動する「ソケットアクティベーション」のような仕組みを取り入れた、比較的新しい実装です。現在の主要なディストリビューションの多くはsystemdを採用していますが、組み込み機器や一部のディストリビューションではSysVinitや、SysVinit互換の仕組みが使われ続けている場合もあります^{すべてのディストリビューションが必ずsystemdを採用しているとは限らない点に注意してください。[7]}。

Upstartの知識

Upstartは、Canonical社の開発者によって作られた、SysVinitに代わるイベント駆動型のinit実装です。従来のSysVinitが、あらかじめ決められた順序でスクリプトを実行する同期的な仕組みだったのに対し、Upstartはハードウェアの挿抜（USBデバイスの接続等）のような「イベント」の発生に応じて非同期に処理を行える点を特徴としていました^{出典：Upstartの開発経緯（Wikipedia「Upstart (software)」）。[8]}。

UpstartはUbuntu 6.10（2006年）でSysVinitに代わって採用され、Ubuntu 9.10（2009年）では起動処理全体がUpstart対応になりました。しかし2014年、Debianの技術委員会がsystemdを採用する決定を行ったことをきっかけに、Ubuntuも上流（Debian）との一貫性を保つ方針でsystemdへの移行を進め、Ubuntu 15.04（2015年）でデフォルトのinitがsystemdに切り替わりました^{Upstartの最終リリースは2014年9月のバージョン1.13.2で、2018年12月以降は保守のみの状態が続いています。[9]}。出題範囲ではUpstartについて「知識を示す（Awareness）」ことが求められているにとどまり、SysVinitやsystemdほど詳細な操作方法までは求められていません。

ブートイベントをログファイルで確認する

システムの起動中に何が起きたかを確認するための代表的なコマンドがdmesgとjournalctlです。両者は扱う対象・保存期間が異なります。

dmesg

dmesg [オプション]

使用例：

dmesg -T | less

journalctlでブートごとのログを確認する

journalctlの一般的な検索・絞り込みオプション（-uによるユニット指定、-pによる優先度の絞り込み等）は「システムロギング」の技術解説記事で扱っています。ここでは、ブート（起動）ごとのログを確認するためのオプションに絞って補足します。

使用例：

journalctl --list-boots
journalctl -b -1 -p err

-b -1のように過去の起動分を参照できるのは、永続化されたジャーナルが残っている場合に限られます。前述のとおり、ジャーナルの永続化が有効になっていない環境では、過去の起動分のログは参照できません。