Arch ブートプロセス
関連記事
Arch Linux を起動するためには、GRUB や Syslinux などの Linux 対応のブートローダを、Master Boot Record もしくは GUID Partition Table にインストールする必要があります。ブートローダは、ブートプロセスが始まる前にカーネルや初期 RAM ディスクをロードする仕事を行います。BIOS と UEFI で起動の流れはかなり異なっています。このページや関連するページに詳しい説明があります。
目次
ファームウェアの種類
BIOS
BIOS (Basic Input-Outout System) とはシステムの電源を入れた時に最初に実行されるプログラム(ファームウェア)のことです。ほとんどの場合、BIOS はマザーボード内のフラッシュメモリに保存され、システムストレージとは独立しています。
UEFI
Unified Extensible Firmware Interface は、パーティションテーブルとファイルシステムの両方の読み取りをサポートしています。UEFI か MBR か、にかかわらず、UEFI は NVRAM を起動せず、代わりにブートエントリに依存します。
UEFI 仕様では FAT12、FAT16、および FAT32 ファイルシステム (UEFI 仕様バージョン2.8、セクション13.3.1.1 を参照) のサポートが義務付けられていますが、規格に準拠しているベンダーは任意でファイルシステムのサポートを追加できます。たとえば、Apple Mac は独自のHFS+ファイルシステムドライバをサポートしています。UEFI の実装では、光ディスク用の ISO-9660 もサポートされています。
UEFIは、boot loaders 、ブートマネージャ、 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 によって実行される
- BIOS から MBR ブートコードにコントロールが移り、次のステージのコードが起動する (通常はブートローダーのコード)
- 起動した(2番目の)コード(ブートローダー)はサポートと設定ファイルを読み込む
- 設定ファイルのデータに基づき、ブートローダーはカーネルと initramfs をシステムメモリ (RAM) にロードしてカーネルを起動する
UEFI
次のページを参照してください: Unified Extensible Firmware Interface#UEFI のブートプロセス
ブートローダー
ブートローダーは、ファームウェア(BIOS または UEFI) によって起動されるソフトウェアです。カーネルは必要な カーネルパラメータ と 初期RAMディスク を設定ファイルに基づいてロードします。UEFI の場合、EFI ブートスタブを使用して、UEFI からカーネル自体を直接起動できます。ブート前にカーネルパラメータを編集するために、別のブートローダやブートマネージャを使うこともできます。
機能比較
| 名前 | ファームウェア | パーティションテーブル | マルチブート | ファイルシステム | 備考 | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 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 をサポートします[3]。 |
| Syslinux | Yes | 部分的 | Yes | Yes | 部分的 | マルチデバイスボリューム、圧縮、暗号化は非対応 | 暗号化非対応 | No | Yes | MBR のみ。スパース inode 非対応 | 特定の ファイルシステム 機能はサポートされていません。[4] ファイルシステムドライバーがありません [5] は、インストールされているファイルシステムにのみアクセスできます。 |
| 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など) |
- ファイルシステムのサポートはファームウェアから継承されます。 UEFI 仕様では、FAT12、FAT16、および FAT32 ファイルシステムのサポートが義務付けられていますが、ベンダーはオプションで追加のファイルシステムのサポートを追加できます。[6] たとえば、Apple Mac のファームウェアは HFS+ ファイルシステムをサポートしています。 ファームウェアが起動時に UEFIドライバー をロードするためのインターフェースを提供する場合、ファイルシステムドライバーを(個別に取得して)ロードすることにより、追加のファイルシステムのサポートを追加できます。
- A boot manager 他の EFI アプリケーション、たとえば
CONFIG_EFI_STUB = yおよび Windowsbootmgfw.efiで構築された Linux カーネルイメージのみを起動できます。 - systemd-boot は UEFI ファイルシステムドライバの読み込みをサポートしています。ドライバは efifs により提供され、
esp/EFI/systemd/drivers/に配置する必要があります。
Wikipedia:Comparison of boot loaders も参照してください。
カーネル
カーネルはオペレーティングシステムのコアです。ローレベル (カーネル空間) で、マシンのハードウェアとハードウェアを使って実行されるプログラムを橋渡しします。CPU を効率的に利用するために、カーネルはスケジューラーを使ってどのタスクが優先的に実行されるかを決定し、多くのタスクが同時に実行されるのを可能にしています。
initramfs
カーネルがロードされた後、カーネルは initramfs (initial RAM ファイルシステム) を解凍して、initial root ファイルシステムにします。カーネルは最初のプロセスとして /init を起動します。初期ユーザー空間の始まりです。
initramfs の目的は root ファイルシステムにアクセスできる位置にシステムをブートストラップすることです (詳しくは FHS を見て下さい)。これは IDE, SCSI, SATA, USB/FW (外部ハードウェアから起動する場合) などのデバイスのために必要なモジュールがカーネルに入っていない場合 initramfs からモジュールをロードできなくてはならないということを意味しています; (プログラムやスクリプトから明示的に指定されるか udev を通すかして) 正しいモジュールがロードされると、ブートプロセスが再開されます。従って、initramfs に含めなくてはならないのは root ファイルシステムにアクセスするために必要なモジュールだけで、使用する全てのモジュールを入れる必要はありません。ほとんどのモジュールは後の init プロセス中に、udev によってロードされます。
Init プロセス
初期ユーザー空間の最終段階として、本当の root がマウントされ、initial root ファイルシステムを置き換えます。/sbin/init が実行され、/init プロセスを置き換えます。Arch は init プロセスとして systemd を使っています。
getty
init は virtual terminal (典型的には6つ) ごとに getty を1回呼び出し、各ttyを初期化してユーザ名とパスワードを要求します。ユーザ名とパスワードが与えられると、getty はそれらを /etc/passwd と /etc/shadow と照合し、 login を呼び出します。あるいは、システム上にディスプレイマネージャがあれば、getty はそれを起動します。
ディスプレイマネージャ
ディスプレイマネージャ は、tty の getty ログインプロンプトを置き換えるように設定できます。
起動後にディスプレイマネージャを自動的に初期化するには、 systemd からサービスユニットを手動で有効にする必要があります。サービス・ユニットの有効化と起動の詳細は、systemd#ユニットを使う を参照してください。
ログイン
ログイン プログラムは、環境変数を設定し、/etc/passwd に基づいてユーザーのシェルを起動することによって、ユーザーのセッションを開始します。
ログイン プログラムは、ログインに成功するとログインシェルを実行する直前に /etc/motd (message of the day) の内容を表示します。利用規約を表示してユーザーに地域のポリシーや伝えたいことを思い出させるのに適した場所です。
シェル
ユーザーの シェル が起動されると、通常はユーザーにプロンプトを表示する前に bashrc などの実行時設定ファイルが実行されます。アカウントが ログイン時に_X_を起動 に設定されている場合、実行時設定ファイルは startx または xinit を呼び出します。
GUI, xinit or wayland
xinit はユーザの xinitrc runtime configuration fileを実行しこれは通常 ウィンドウマネージャ を開始します。ユーザがウィンドウマネージャを終了すると、xinit、 startx、 シェル、 ログイン、の順序で終了して getty に戻ります。