Arch ブートプロセス
関連記事
Arch Linux を起動するためには、Linux 対応のブートローダーをセットアップする必要があります。ブートローダは、ブートプロセスが始まる前にカーネルや初期 RAM ディスクをロードする仕事を行います。BIOS と UEFI で起動の流れはかなり異なっています。このページや関連するページに詳しい説明があります。
目次
ファームウェアの種類
ファームウェアは、システムの電源を入れた時に一番最初に実行されるプログラムのことです。
BIOS
BIOS (Basic Input-Outout System) は、ほとんどの場合マザーボード内のフラッシュメモリに保存され、システムストレージとは独立しています。元々は IBM PC がハードウェアの初期化やブートプロセスを処理するために作成されました。2010 年より、BIOS にあるような技術的な制約が存在しない UEFI に徐々に置き換えられています。
UEFI
Unified Extensible Firmware Interface は、パーティションテーブルとファイルシステムの両方の読み取りをサポートしています。UEFI は Master Boot Record (MBR) 内のブートコードを起動しません (たとえ、それが有ろうと無かろうと)。代わりに、起動は NVRAM 内のブートエントリに頼っています。
UEFI 仕様では FAT12、FAT16、および FAT32 ファイルシステム (UEFI 仕様バージョン2.8、セクション13.3.1.1 を参照) のサポートが義務付けられていますが、規格に準拠しているベンダーは任意でファイルシステムのサポートを追加できます。たとえば、Apple の一部のファームウェアでは HFS+ か APFS のサポートがあります。UEFI の実装では、光ディスク用の ISO 9660 もサポートされています。
UEFIは、ブートローダー 、ブートマネージャ、 UEFI シェル などの EFI アプリケーションを起動します。これらのアプリケーションは通常、 EFI システムパーティション にファイルとして保存されます。各ベンダーは、EFI システムパーティションの /EFI/vendor_name フォルダにファイルを格納できます。アプリケーションを起動するには、NVRAM に、または UEFI シェルからブートエントリを追加します。
UEFI 仕様では、互換性サポートモジュール (CSM) によるレガシー BIOS ブートがサポートされています。UEFI で CSM が有効な場合、UEFI はすべてのドライブの CSM ブートエントリを生成します。CSM ブートエントリがブート元として選択された場合、UEFI の CSM はドライブの MBR ブートストラップコードからのブートを試みます。
システムの初期化
BIOS
- システムの電源が入れられ POST が実行される。
- BIOS が、ブートに必要なシステムハードウェア (ディスクやキーボードコントローラなど) を初期化する。
- BIOS のディスク順で最初のディスクの最初の440バイト (Master Boot Record) が BIOS によって実行される。
- MBR ブートコード内の、ブートローダの最初のステージが、2番めのステージコードを以下のどれかから実行する:
- MBR の次のディスクセクタ。つまり、post-MBR gap と呼ばれる部分(MBR パーティションテーブルにしか存在しません)。
- パーティション、あるいはパーティションレスディスクの ボリュームブートレコード (VBR)。
- GPT でパーティショニングされたディスク上の GRUB の場合、GRUB 固有の BIOS ブートパーティション (GPT には存在しない MBR の後ろの隙間の代わりとして使用されます)。
- ブートローダー本体が起動される。
- ブートローダーがオペレーティングシステムのカーネルをチェインロード、または直接ロードして、オペレーティングシステムをロードする。
UEFI
- システムのスイッチが入り、power-on self-test (POST) が実行される。
- POST 後に、UEFI は起動に必要なハードウェア(ディスク、キーボード、コントローラなど)を初期化する。
- ファームウェアは NVRAM 内のブートエントリを読み込み、どの EFI アプリケーションを起動するかや、どこから(例えば、どのディスクやパーティションから)起動するかを判断する。
- ブートエントリは単にディスクであることもあります。この場合、ファームウェアは EFI システムパーティションをそのディスク上から探し、フォールバックブートパス
\EFI\BOOT\BOOTx64.EFI(IA32 (32-bit) UEFI のシステムではBOOTIA32.EFI)から EFI アプリケーションを見つけようとします。これは UEFI の起動可能リムーバブルメディアの動作です。
- ブートエントリは単にディスクであることもあります。この場合、ファームウェアは EFI システムパーティションをそのディスク上から探し、フォールバックブートパス
- ファームウェアが EFI アプリケーションを起動する。
セキュアブート が有効化されている場合、ブートプロセスでは EFI バイナリの正統性を署名によって検証します。
UEFI でのマルチブート
それぞれの OS やベンダーは互いに影響を与えずに EFI システムパーティション 内に固有のファイルを保持することができるので、UEFI を用いたマルチブートは単に、特定のオペレーティングシステムのブートローダに対応する異なる EFI アプリケーションを起動する問題になります。ゆえに、他の OS をロードするためにブートローダのチェインロードメカニズムに頼る必要がありません。
Windows と Arch のデュアルブート も参照してください。
ブートローダー
ブートローダーは、ファームウェア(BIOS または UEFI)によって起動されるソフトウェアの一部です。ブートローダーは、必要なカーネルパラメータと任意の外部の初期 RAM ディスクイメージと共にカーネルをロードします。UEFI の場合、EFI ブートスタブを使用して、UEFI からカーネル自体を直接起動できます。ブート前にカーネルパラメータを編集するために、別のブートローダやブートマネージャを使うこともできます。
機能比較
| 名前 | ファームウェア | パーティションテーブル | マルチブート | ファイルシステム | 備考 | ||
|---|---|---|---|---|---|---|---|
| BIOS | UEFI | MBR | GPT | ||||
| EFISTUB | – | Yes1 | Yes | Yes | – | ファームウェアから継承2 | カーネルイメージは、UEFI または他の UEFI ブートローダーから直接起動することのできる 有効な EFI 実行ファイルです。 |
| Unified カーネルイメージ | – | Yes3 | Yes | Yes | – | ファームウェアから継承2 | systemd-stub(7) やカーネル、initramfs、カーネルコマンドラインを EFI 実行ファイルにパックしたものです。UEFI ファームウェアや他のブートローダから直接読み込めます。 |
| GRUB | Yes | Yes | Yes | Yes | Yes | 内蔵 | RAID、LUKS1、LVMをサポートします (シンプロビジョニングボリュームはサポートしません)。環境固有の制限については GRUB を見てください。 |
| Limine | Yes | Yes | Yes | Yes | Yes | 制限有り | |
| rEFInd | No | Yes | Yes | Yes | Yes4 | 拡張可能2,5 | 明示的な構成なしでカーネルとパラメーターの自動検出をサポートします。そして、fastboot をサポートします[2]。 |
| Syslinux | Yes | 部分的1 | Yes | Yes | 部分的 | 制限有り | ファイルシステムの特定の機能はサポートされていません。 Syslinux がインストールされているファイルシステムにしかアクセスできません。 |
| systemd-boot | No | Yes3 | 手動 | Yes | Yes4 | 拡張可能2,5 | systemd-boot がインストールされている ESP、または、同じディスク上の Extended Boot Loader Partition (XBOOTLDR パーティション) 内のバイナリしか起動できません。esp/EFI/Linux/ 内の unified カーネルイメージ を自動的に検出します。
|
| GRUB Legacy | Yes | No | Yes | No | Yes | 制限有り | 開発停止。GRUB に移行。 |
| LILO | Yes | No | Yes | 部分的 | Yes | 制限有り | (Btrfs、GPT、RAID、暗号化などの) 制限により開発停止。 |
- バイナリはセキュアブートのために署名することはできますが、検証はされません。なので、信用の鎖はここで切れてしまいます。
- ファイルシステムのサポートはファームウェアから継承されます。UEFI 仕様では、FAT12、FAT16、および FAT32 ファイルシステムのサポートが義務付けられていますが [3]、ベンダーはオプションで追加のファイルシステムのサポートを追加できます。たとえば、Apple Mac のファームウェアは HFS+ ファイルシステムをサポートしています。 ファームウェアが起動時に UEFIドライバー をロードするためのインターフェースを提供する場合、ファイルシステムドライバーを(個別に取得して)ロードすることにより、追加のファイルシステムのサポートを追加できます。
- Mixed mode ブートをサポートしています。つまり、32 ビット IA32 UEFI 上で 64 ビット x86_64 Linux カーネルをブートできます。
- ブートマネージャー。他の EFI アプリケーション、たとえば
CONFIG_EFI_STUB = yフラグありでビルドされた Linux カーネルイメージおよび Windows Boot Manager (bootmgfw.efi) のみを起動できます。 - UEFI ファイルシステムドライバの読み込みをサポートしています。
Wikipedia:Comparison of boot loaders も参照してください。
カーネル
ブートローダー は、カーネルを含んでいる vmlinux イメージを起動します。
カーネルは、マシンのハードウェアとプログラムとの間を仲介する低いレベル(カーネル空間)で機能します。カーネルは、ユーザスペースに移行する前にまずハードウェアの列挙と初期化を行います。より詳細な説明は Wikipedia:ja:カーネル と Wikipedia:ja:Linuxカーネル を見てください。
initramfs
/ のルートファイルシステムは空の rootfs として始まります。これは ramfs や tmpfs の特殊なインスタンスです。これは一時的なルートファイルシステムで、initramfs (initial RAM file system) イメージがここへ解凍されます。
Initramfs の主な目的は root ファイルシステムにアクセスできる位置にシステムをブートストラップすることです (詳しくは FHS を見て下さい)。これには、dm-crypt、dm-verify、systemd-repart(8) などを通して rootfs が存在しているであろうストレージスタックのセットアップなどが含まれます。また、udev を介して永続的なブロックデバイスの命名を実際のデバイスに解決することも行われます。これは IDE, SCSI, SATA, USB/FW (外部ハードウェアから起動する場合) などのデバイスのために必要なモジュールがカーネルに入っていない場合 initramfs からモジュールをロードできなくてはならないということを意味しています; (プログラムやスクリプトから明示的に指定されるか udev を通すかして) 正しいモジュールがロードされると、ブートプロセスが再開されます。従って、initramfs に含めなくてはならないのは root ファイルシステムにアクセスするために必要なモジュールだけで、使用する全てのモジュールを入れる必要はありません。ほとんどのモジュールは後の init プロセス中に、ルート (/) を実際のルートファイルシステムに切り替えた後で udev によってロードされます。
まず、カーネルは組み込みの initramfs を一時的なルートファイルシステムに解凍します。Arch Linux の公式カーネルでは組み込みの initramfs として空のアーカイブが用いられます(Linux のビルドの際のデフォルトです)。そして、カーネルは、ブートローダーから渡されたコマンドラインにより指定された外部の initramfs ファイルを解凍します。この際、組み込みの initramfs にあったファイルは上書きされます。このような外部の initramfs イメージは mkinitcpio や dracut、booster によって生成でき、Arch の初期ユーザ空間のセットアップの方法として推奨されています。
Initramfs には、ルートファイルシステムをセットアップする以外の役割もあります。rootfs がマウントされる前にしか行うことができないタスク (fsck やハイバネートからの復帰など) が存在するのです。
また、Linux カーネルは、カーネルが開始された最初のルートファイルシステムを留めておきます。Initramfs が使用されなかった場合、シャットダウン時に実際のルートファイルシステムが正しくアンマウントされない可能性があります。
初期ユーザ空間
初期ユーザ空間の段階は一時的なルートファイルシステムがマウントされている状態で行われ、initramfs により提供されたファイルで動作します。
初期ユーザ空間の機能は設定可能ですが、一般的に以下のようなことを行います:
- systemd-modules-load(8) がカーネルモジュールを読み込みます。例えば、本物のルートファイルシステムをマウントするために必要なブロックデバイスモジュールなどです。
- 必要ならば、本物のルートファイルシステムの復号処理を行います。
- DRM モジュールをロードします。KMS の早期開始は、ツリー内のモジュールに対してはデフォルトで有効化されています。
初期ユーザー空間の最終段階として、本物のルートファイルシステムが /sysroot/ (systemd ベースの initramfs の場合) または /new_root/ (busybox ベースの場合) にマウントされ、それに切り替わります。本物のルートファイルシステムから init プログラムを実行することにより、後期ユーザ空間が始まります。
後期ユーザ空間
init プロセスにより後期ユーザ空間のスタートアップが実行されます。Arch では公式には、ユニットとサービスの概念の上に構築された systemd が用いられます。しかし、ここで言及している機能は他の init システムと重なります。
getty
init プロセスは 仮想コンソール(典型的には6つ)ごとに getty を1回呼び出します。getty はそれぞれのターミナルを初期化して、認証されていないユーザからターミナルを保護します。ユーザ名とパスワードが与えられると、getty はそれらを /etc/passwd と /etc/shadow と照合し、login(1) を呼び出します。
ログイン
ログイン プログラムは、環境変数を設定し、/etc/passwd に基づいてユーザーのシェルを起動することによって、ユーザーのセッションを開始します。ログイン プログラムは、ログインに成功するとログインシェルを実行する直前に /etc/motd (message of the day) の内容を表示します。利用規約を表示してユーザーに地域のポリシーや伝えたいことを思い出させるのに適した場所です。
シェル
ユーザーの シェル が起動されると、通常はユーザーにプロンプトを表示する前に bashrc などの実行時設定ファイルが実行されます。アカウントが ログイン時に_X_を起動 に設定されている場合、実行時設定ファイルは startx または xinit を呼び出します。
ディスプレイマネージャ
さらに、init は、指定した仮想コンソールで getty の代わりにディスプレイマネージャを起動するように設定できます。そうするには、該当する systemd service ファイルを手動で有効化する必要があります。そうしたら、ディスプレイマネージャーがグラフィカルセッションを起動します。
グラフィカルセッション
xinit はユーザの xinitrc ランタイム設定ファイルを実行し、通常、ウィンドウマネージャやデスクトップ環境を開始します。ユーザが終了すると、xinit、 startx、 シェル、 ログインの順序で終了して getty、またはディスプレイマネージャに戻ります。
参照
- Early Userspace in Arch Linux
- Inside the Linux boot process
- Wikipedia:Linux startup process
- Wikipedia:initrd
- NeoSmart: The BIOS/MBR Boot Process
- Kernel Newbie Corner: initrd and initramfs
- Rod Smith - Managing EFI Boot Loaders for Linux
- Lennart Poettering - Linux Boot Partitions and How to Set Them Up