【ITニュース解説】Linux Boot Process: From Power-On to Login

Linuxシステムが起動するプロセスは、コンピュータの電源が投入されてからユーザーがログインできるようになるまでの間に、ファームウェア、ブートローダー、カーネル、そしてsystemdという主要な段階を、まるでリレーのように次々と処理を引き継ぎながら進行する。この一連の仕組みを理解することは、システムエンジニアを目指す上で非常に重要となる。

まず、電源が投入されると、コンピュータのファームウェア（BIOSまたはUEFI）が起動する。この段階で、POST（Power-On Self-Test）と呼ばれる自己診断テストが実行され、CPU、メモリ、基本的なチップセット、ストレージコントローラ、キーボードといった主要なハードウェアコンポーネントが正しく動作するかどうかが確認される。POSTが完了すると、ファームウェアはシステムを起動するためのデバイス（SSD、HDD、USBメモリ、ネットワークなど）を、設定された優先順位に基づいて探索する。BIOSシステムでは、ディスクの先頭にあるMBR（Master Boot Record）と呼ばれる領域からプライマリブートローダーという小さなプログラムを読み込む。一方、UEFIシステムでは、EFIシステムパーティション（ESP）内に格納されている「EFI実行ファイル」を直接ロードする。

次に、ブートローダーの役割が始まる。BIOSベースのシステムでMBRから読み込まれるプライマリブートローダーは、そのサイズが非常に小さく、直接OSを起動するほどの機能は持たない。そのため、その主な役割は、より高機能なセカンダリブートローダー（例えばGRUBなど）をディスク上の別の場所から見つけてメモリにロードすることである。UEFIシステムの場合、ファームウェアがESPから直接、GRUBやsystemd-bootといったセカンダリブートローダーのEFI実行ファイルをロードする。このセカンダリブートローダーこそが、複数のOSがインストールされている場合に選択メニューを表示したり、Linuxカーネルに渡す起動時の設定（カーネルパラメータ）を受け付けたりする。そして、最終的にLinuxカーネル本体と、初期RAMディスクであるinitramfs（イニットラムエフエス）をメモリにロードする。カーネルパラメータは、例えば「root=UUID=…」で実際のルートファイルシステム（OS本体が格納されている場所）の場所をカーネルに伝えたり、「ro/rw」でルートファイルシステムを読み取り専用か読み書き可能かでマウントするかどうかを指定したり、「quiet/verbose」で起動時のメッセージの表示量を制御したりする。また、緊急時のための「systemd.unit=rescue.target」といった特別なモードで起動するパラメータもある。

カーネルとinitramfsがメモリにロードされると、いよいよカーネルの初期化が始まる。まず、圧縮されたカーネルイメージがメモリ上で展開され、実行を開始する。カーネルは、CPUのマルチプロセッシング機能（SMP）の有効化、メモリ管理、ページテーブルの設定、PCIやUSBなどのデバイスバスの初期化、割り込みコントローラやタイマーの構成といった基本的なハードウェアのセットアップを行う。この時点ではまだ、すべてのデバイスドライバがロードされているわけではない。そこでinitramfsの出番となる。initramfsは、最小限のルートファイルシステム環境であり、ディスクコントローラやファイルシステムへのアクセスに必要な基本的なドライバやツールを一時的に提供する。カーネルはinitramfs内のスクリプトを実行し、そこに含まれるドライバを使って、実際のルートファイルシステムを発見してメモリ上にマウントする。この準備が整うと、システムはinitramfs環境から実際のルートファイルシステムへと実行環境を切り替える（pivot_rootまたはswitch_root）。そして、カーネルはユーザー空間で最初に起動するプロセスであり、すべてのプロセスの親となる「PID 1」のプログラムを実行する。現在のほとんどのLinuxシステムでは、このPID 1は「systemd」である。

systemdが起動すると、システムの残りの部分の起動と管理を担う。systemdは、サービス（バックグラウンドで動作するプログラム）、ソケット、タイマー、マウントポイント、そしてシステムの特定の状態を表す「ターゲット」といった様々なシステムリソースを、「ユニットファイル」という設定ファイルで定義している。systemdの大きな特徴は、これらのユニットを依存関係（例: あるサービスは別のサービスが起動した後でなければ起動しない）に基づいて並列に起動できることだ。これにより、起動プロセスが高速化される。従来のSysV initシステムにおける「ランレベル」は、systemdでは「ターゲット」に置き換えられた。例えば、「rescue.target」はシングルユーザーモードでの起動を、「multi-user.target」はサーバーのようなテキストベースの環境での起動を、「graphical.target」はデスクトップ環境での起動をそれぞれ意味する。systemdの管理には「systemctl」コマンドが用いられ、サービスの起動・停止・状態確認、ユニットの有効化・無効化などを行う。また、「journalctl」コマンドでシステムログを確認したり、「systemd-analyze」コマンドで起動時間を分析したりすることもできる。例えば、ネットワークが必要なサービスは「network-online.target」が起動した後でなければ開始されないように、依存関係が細かく設定されている。

systemdによるシステムの初期化が完了すると、ユーザーがログインできる状態になる。サーバーのようなコマンドラインインターフェース（CUI）環境では、systemdは仮想ターミナル（TTY）ごとに「agetty@ttyX.service」を起動し、ユーザーが文字ベースでログインできるようにする。一方、デスクトップ環境では、GDM、SDDM、LightDMなどのディスプレイマネージャーがグラフィカルなログイン画面を表示し、ユーザー認証が成功すると、GNOMEやKDEなどのデスクトップセッションが開始される。ログイン後、ユーザー固有のサービスや自動起動アプリケーションが立ち上がり、ユーザーランドの初期化が完了する。

これらの起動プロセス中に問題が発生することもある。例えば、ファームウェアのブート順序設定が間違っていたり、ブートローダー（GRUBなど）が破損してカーネルをロードできなかったりするケースだ。GRUBの問題は、ライブメディア（USBメモリなど）からシステムを起動し、chroot環境を使ってGRUBを再インストールし、設定ファイルを再生成することで解決できる場合が多い。また、カーネルがルートファイルシステムを見つけられずに「カーネルパニック」を起こす場合は、「root=」カーネルパラメータで指定されたUUIDが正しいかを確認したり、initramfsを再構築して、必要なストレージコントローラのドライバが組み込まれているかを確かめたりする必要がある。緊急時には、ブートローダーのメニューからカーネルパラメータに「systemd.unit=rescue.target」などを追加して起動し、システムログを「journalctl -b -p err」で確認したり、問題のあるサービスを「systemctl disable --now」コマンドで一時的に無効化したりして回復を試みる。

各段階で役立つコマンドを知っておくことも重要である。UEFI環境では「efibootmgr -v」でUEFIのブートエントリを確認でき、「lsblk -f」でファイルシステムとそのUUIDを確認できる。ブートローダー関連では「grub-install」でGRUBをインストールし、「grub-mkconfig -o /boot/grub/grub.cfg」で設定ファイルを生成する。カーネルやinitramfs関連では「uname -a」でカーネルのバージョンを確認し、「lsinitramfs」や「dracut -f」でinitramfsの内容確認や再生成を行う。systemdに関しては、「systemd-analyze blame」や「systemd-analyze critical-chain」で起動に時間のかかっているサービスを特定したり、「systemctl list-dependencies」でユニットの依存関係を確認したり、「journalctl -b」で起動時のログを閲覧したりできる。

このように、Linuxの起動プロセスは、電源投入からログインに至るまで、ファームウェア、ブートローダー、カーネル、そしてsystemdという予測可能な複数の段階を経て進行する。これらの各段階で何が起きているのか、そしてどのようなツールやコマンドがあるのかを理解することで、「システムが起動しない」という漠然とした問題を、具体的な原因究明と解決策の適用へと繋がる、対処可能な課題へと変えることができるのだ。