Arch ブートプロセス

関連記事

• Master Boot Record
• GUID Partition Table
• Unified Extensible Firmware Interface
• mkinitcpio
• init
• systemd
• fstab
• 自動起動

Arch Linux を起動するためには、GRUB や Syslinux などの Linux 対応のブートローダを、Master Boot Record もしくは GUID Partition Table にインストールする必要があります。ブートローダは、ブートプロセスが始まる前にカーネルや初期 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 仕様では、[Wikipedia:ja:Unified_Extensible_Firmware_Interface 互換性サポートモジュール (CSM)] によるレガシー BIOS ブートがサポートされています。UEFI で CSM が有効な場合、UEFI はすべてのドライブの CSM ブートエントリを生成します。CSM ブートエントリがブート元として選択された場合、UEFI の CSM はドライブの MBR ブートストラップコードからのブートを試みます。

ノート: Intel は CSM のサポートを徐々に終了しつつあります。将来的に、この機能に頼ることは不可能になるかもしれません。[1]

システムの初期化

BIOS

1. システムの電源が入れられ POST が実行される
2. BIOS がブートに必要なシステムハードウェア (ディスクやキーボードコントローラなど) を初期化する
3. (BIOS のディスク順で) 最初のディスクの最初の440バイト (Master Boot Record) が BIOS によって実行される
4. BIOS から MBR ブートコードにコントロールが移り、次のステージのコードが起動する (通常はブートローダーのコード)
5. 起動した(2番目の)コード(ブートローダー)はサポートと設定ファイルを読み込む
6. 設定ファイルのデータに基づき、ブートローダーはカーネルと initramfs をシステムメモリ (RAM) にロードしてカーネルを起動する

UEFI

1. システムのスイッチが入る - power-on self-test (POST) が実行されます。
2. POST 後に、UEFI は起動に必要なハードウェア(ディスク、キーボード、コントローラなど)を初期化します。
3. ファームウェアは NVRAM 内のブートエントリを読み込み、どの EFI アプリケーションを起動するかや、どこから(例えば、どのディスクやパーティションから)起動するかを判断します。
   • ブートエントリは単にディスクであることもあります。この場合、ファームウェアは EFI システムパーティションをそのディスク上から探し、フォールバックブートパス \EFI\BOOT\BOOTx64.EFI(IA32 (32-bit) UEFI のシステムでは BOOTIA32.EFI)から EFI アプリケーションを見つけようとします。これは UEFI の起動可能リムーバブルメディアの動作です。
4. ファームウェアが EFI アプリケーションを起動します。
   • そのアプリケーションはブートローダや、EFISTUB を使用する Arch カーネル自体であることもあります。
   • そのアプリケーションは他の EFI アプリケーション(UEFI シェル や、systemd-boot や rEFInd などの ブートマネージャ)であることもあります。

セキュアブート が有効化されている場合、ブートプロセスでは EFI バイナリの正統性を署名によって検証します。

ノート: 一部の UEFI システムはフォールバックブートパスからしか起動できません。

UEFI でのマルチブート

それぞれの OS やベンダーは互いに影響を与えずに EFI システムパーティション 内に固有のファイルを保持することができるので、UEFI を用いたマルチブートは単に、特定のオペレーティングシステムのブートローダに対応する異なる EFI アプリケーションを起動する問題になります。ゆえに、他の OS をロードするためにブートローダのチェインロードメカニズムに頼る必要がありませｎ。

Windows と Arch のデュアルブート も参照してください。

ブートローダー

ブートローダーは、ファームウェア(BIOS または UEFI) によって起動されるソフトウェアです。カーネルは必要な カーネルパラメータ と 初期RAMディスク を設定ファイルに基づいてロードします。UEFI の場合、EFI ブートスタブを使用して、UEFI からカーネル自体を直接起動できます。ブート前にカーネルパラメータを編集するために、別のブートローダやブートマネージャを使うこともできます。

警告: ブートローダーはカーネルと initramfs イメージにアクセスできなければなりません。アクセスできなければシステムはブートしません。したがって、通常のセットアップでは、/boot へのアクセスをサポートしている必要があります。つまり、ブロックデバイスからスタックされたブロックデバイス (LVM、RAID、dm-crypt、LUKSなど) まで、カーネルやinitramfsイメージが存在するファイルシステムまで、すべてをサポートしなければなりません。

ノート: マイクロコード の更新を読み込むには、ブートローダの設定を調整する必要があります。 [2]

機能比較

ノート:

• GPT は UEFI 仕様の一部であるため、すべての UEFI ブートローダーは GPT ディスクをサポートします。BIOS システム上の GPT は、HybridMBRで "hybrid booting" を使うか、新しい GPTのみ プロトコルを使うことで可能です。ただしこのプロトコルは特定の BIOS 実装で問題を引き起こす可能性があります。詳細については、[3] を参照してください。
• ファイルシステムのサポートで言及されている暗号化は filesystem-level encryption であり ブロックレベルの暗号化 とは関係ありません。

名前	ファームウェア		パーティションテーブル		マルチブート	ファイルシステム					備考
	BIOS	UEFI	MBR	GPT		Btrfs	ext4	ReiserFS	VFAT	XFS
EFISTUB	–	Yes	Yes	Yes	–	–	–	–	ファームウェアから継承1	–	カーネルはEFI実行可能ファイルに変換され、UEFI ファームウェアまたは別のブートローダーから直接ロードされます。
Unified カーネルイメージ	–	Yes	Yes	Yes	–	–	–	–	ファームウェアから継承1	–	systemd-stub(7) やカーネル、initramfs、カーネルコマンドラインを EFI 実行ファイルにパックしたものです。UEFI ファームウェアや他のブートローダから直接読み込めます。
Clover	UEFI をエミュレート	Yes	Yes	Yes	Yes2	No	暗号化非対応	No	ファームウェアから継承1	No	rEFIt のフォークは、macOS on non-Apple hardware を実行するように変更されました。
GRUB	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	BIOS / GPT 構成では、BIOSシステム が必要です。 RAID、LUKS1、LVMをサポートします(シンプロビジョニングボリュームはサポートしません)
Limine	Yes	Yes	Yes	Yes	Yes	No	暗号化非対応	No	Yes	No
rEFInd	No	Yes	Yes	Yes	Yes2	暗号化非対応	暗号化非対応	テールパッキング機能は非対応	ファームウェアから継承1	No	明示的な構成なしでカーネルとパラメーターの自動検出をサポートします。そして、fastboot をサポートします[4]。
Syslinux	Yes	部分的	Yes	Yes	部分的	マルチデバイスボリューム、圧縮、暗号化は非対応	暗号化非対応	No	Yes	MBR のみ。スパース inode 非対応	特定の ファイルシステム 機能はサポートされていません。[5] ファイルシステムドライバーがありません [6] は、インストールされているファイルシステムにのみアクセスできます。
systemd-boot	No	Yes	手動インストールのみ	Yes	Yes2	サイドロード可3	サイドロード可3	サイドロード可3	ファームウェアから継承1	サイドロード可3	ESP または拡張ブートローダーパーティション(XBOOTLDRパーティション)以外のパーティションからバイナリを起動することはできません。 Unified カーネルイメージは、esp/EFI/Linux に置かれた場合、自動検出をサポートします。
GRUB Legacy	Yes	No	Yes	No	Yes	No	No	Yes	Yes	XFS v4 のみ	廃止。GRUB に移行。
LILO	Yes	No	Yes	No	Yes	No	暗号化非対応	Yes	Yes	Yes	廃止 制限による (Btrfs、GPT、RAIDなど)

1. ファイルシステムのサポートはファームウェアから継承されます。 UEFI 仕様では、FAT12、FAT16、および FAT32 ファイルシステムのサポートが義務付けられていますが、ベンダーはオプションで追加のファイルシステムのサポートを追加できます。[7] たとえば、Apple Mac のファームウェアは HFS+ ファイルシステムをサポートしています。 ファームウェアが起動時に UEFIドライバー をロードするためのインターフェースを提供する場合、ファイルシステムドライバーを(個別に取得して)ロードすることにより、追加のファイルシステムのサポートを追加できます。
2. A boot manager 他の EFI アプリケーション、たとえば CONFIG_EFI_STUB = y および Windows bootmgfw.efi で構築された Linux カーネルイメージのみを起動できます。
3. systemd-boot は UEFI ファイルシステムドライバの読み込みをサポートしています。ドライバは efifs により提供され、esp/EFI/systemd/drivers/ に配置する必要があります。

Wikipedia:Comparison of boot loaders も参照してください。

カーネル

ブートローダー は、カーネルを含んでいる vmlinux イメージを起動します。

カーネルは、マシンのハードウェアとプログラムとの間を仲介する低いレベル(カーネル空間)で機能します。カーネルは、ユーザスペースに移行する前にまずハードウェアの列挙と初期化を行います。より詳細な説明は Wikipedia:ja:カーネル と Wikipedia:ja:Linuxカーネル を見てください。

initramfs

/ のルートファイルシステムは空の rootfs として始まります。これは ramfs や tmpfs の特殊なインスタンスです。これは一時的なルートファイルシステムで、initramfs (initial RAM file system) イメージがここへ解凍されます。

initramfs の目的は root ファイルシステムにアクセスできる位置にシステムをブートストラップすることです (詳しくは FHS を見て下さい)。これは IDE, SCSI, SATA, USB/FW (外部ハードウェアから起動する場合) などのデバイスのために必要なモジュールがカーネルに入っていない場合 initramfs からモジュールをロードできなくてはならないということを意味しています; (プログラムやスクリプトから明示的に指定されるか udev を通すかして) 正しいモジュールがロードされると、ブートプロセスが再開されます。従って、initramfs に含めなくてはならないのは root ファイルシステムにアクセスするために必要なモジュールだけで、使用する全てのモジュールを入れる必要はありません。ほとんどのモジュールは後の init プロセス中に、udev によってロードされます。

まず、カーネルは組み込みの initramfs を一時的なルートファイルシステムに解凍します。Arch Linux の公式カーネルでは組み込みの initramfs として空のアーカイブが用いられます(Linux のビルドの際のデフォルトです)。そして、カーネルは、ブートローダーから渡されたコマンドラインにより指定された外部の initramfs ファイルを解凍します。この際、組み込みの initramfs にあったファイルは上書きされます。このような外部の initramfs イメージは mkinitcpio や dracut、booster によって生成でき、Arch の初期ユーザ空間のセットアップの方法として推奨されています。

初期ユーザ空間

初期ユーザ空間の段階は一時的なルートファイルシステムがマウントされている状態で行われ、initramfs により提供されたファイルで動作します。

初期ユーザ空間の機能は設定可能ですが、一般的に以下のようなことを行います:

• systemd-modules-load(8) がカーネルモジュールを読み込みます。例えば、本物のルートファイルシステムをマウントするために必要なブロックデバイスモジュールなどです。
• 必要ならば、本物のルートファイルシステムの復号処理を行います。
• early KMS が必要な場合、DRM モジュールを読み込みます。

初期ユーザー空間の最終段階として、本物のルートファイルシステムが /sysroot にマウントされ、それに切り替わります。本物のルートファイルシステムから 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 runtime configuration fileを実行し、通常、ウィンドウマネージャやデスクトップ環境を開始します。ユーザが終了すると、xinit、 startx、 シェル、 ログインの順序で終了して getty、またはディスプレイマネージャに戻ります。

参照

• Early Userspace in Arch Linux
• Inside the Linux boot process
• Boot with GRUB
• Wikipedia:Linux startup process
• Wikipedia:ja:initrd
• Boot Linux Grub Into Single User Mode