「Arch ブートプロセス」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(言語間リンク更新, 関連記事追加)
1行目: 1行目:
 
[[Category:ブートプロセス]]
 
[[Category:ブートプロセス]]
 
[[Category:Arch について]]
 
[[Category:Arch について]]
[[ar:Arch Boot Process]]
+
[[ar:Arch boot process]]
[[cs:Arch Boot Process]]
+
[[bs:Arch boot process]]
[[en:Arch Boot Process]]
+
[[cs:Arch boot process]]
[[es:Arch Boot Process]]
+
[[en:Arch boot process]]
  +
[[es:Arch boot process]]
 
[[fr:Processus de boot]]
 
[[fr:Processus de boot]]
[[it:Arch Boot Process]]
+
[[it:Arch boot process]]
[[ru:Arch Boot Process]]
+
[[pt:Arch boot process]]
[[zh-hans:Arch Boot Process]]
+
[[zh-hans:Arch boot process]]
 
{{Related articles start}}
 
{{Related articles start}}
 
{{Related|ブートローダー}}
 
{{Related|ブートローダー}}
15行目: 16行目:
 
{{Related|Unified Extensible Firmware Interface}}
 
{{Related|Unified Extensible Firmware Interface}}
 
{{Related|mkinitcpio}}
 
{{Related|mkinitcpio}}
  +
{{Related|init}}
 
{{Related|systemd}}
 
{{Related|systemd}}
 
{{Related|fstab}}
 
{{Related|fstab}}

2020年11月5日 (木) 20:02時点における版

関連記事

Arch Linux を起動するためには、GRUBSyslinux などの Linux 対応のブートローダを、Master Boot Record もしくは GUID Partition Table にインストールする必要があります。ブートローダは、ブートプロセスが始まる前にカーネルや初期 RAM ディスクをロードする仕事を行います。BIOSUEFI で起動の流れはかなり異なっています。このページや関連するページに詳しい説明があります。

ブートプロセス

BIOS

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

UEFI

次のページを参照してください: Unified Extensible Firmware Interface#UEFI のブートプロセス

ブートローダー

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

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

機能比較

ノート:

GPT は UEFI 仕様の一部であるため、すべての UEFI ブートローダーは GPT ディスクをサポートします。BIOS システム上の GPT は、HybridMBRで "hybrid booting" を使うか、新しい GPTのみ プロトコルを使うことで可能です。ただしこのプロトコルは特定の BIOS 実装で問題を引き起こす可能性があります。詳細については、[2] を参照してください。

名前 ファームウェア パーティションテーブル マルチブート ファイルシステム 備考
BIOS UEFI MBR GPT Btrfs ext4 ReiserFS VFAT XFS
EFISTUB Yes Yes Yes Inherited from firmware1 カーネルはEFI実行可能ファイルに変換され、UEFI ファームウェアまたは別のブートローダーから直接ロードされます。
Clover Emulates UEFI Yes Yes Yes Yes2 No Without encryption No Inherited from firmware1 No rEFIt のフォークは、macOS on non-Apple hardware を実行するように変更されました。
GRUB Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes BIOS / GPT 構成では、BIOSシステム が必要です。
RAID、LUKS1、LVMをサポートします(シンプロビジョニングボリュームはサポートしません)
rEFInd No Yes Yes Yes Yes2 Without encryption Without encryption Without tail-packing feature Inherited from firmware1 No 明示的な構成なしでカーネルとパラメーターの自動検出をサポートします。
Syslinux Yes Partial Yes Yes Partial Without: multi-device volumes, compression, encryption Without encryption No Yes MBR only; without sparse inodes 特定の ファイルシステム 機能はサポートされていません。[3]
ファイルシステムドライバーがありません [4] は、インストールされているファイルシステムにのみアクセスできます。
systemd-boot No Yes Manual install only Yes Yes2 No No No Inherited from firmware1 No ESP または拡張ブートローダーパーティション(XBOOTLDRパーティション)以外のパーティションからバイナリを起動することはできません。
GRUB Legacy Yes No Yes No Yes No No Yes Yes XFS v4 only [5] GRUB を支持
LILO Yes No Yes No Yes No Without encryption Yes Yes Yes 廃止 制限による (Btrfs、GPT、RAIDなど)
  1. ファイルシステムのサポートはファームウェアから継承されます。 UEFI 仕様では、FAT12、FAT16、および FAT32 ファイルシステムのサポートが義務付けられていますが、ベンダーはオプションで追加のファイルシステムのサポートを追加できます。[6] たとえば、Apple Mac のファームウェアは HFS+ ファイルシステムをサポートしています。 ファームウェアが起動時に UEFIドライバー をロードするためのインターフェースを提供する場合、ファイルシステムドライバーを(個別に取得して)ロードすることにより、追加のファイルシステムのサポートを追加できます。
  2. A boot manager 他の EFI アプリケーション、たとえば CONFIG_EFI_STUB = y および Windows bootmgfw.efi で構築された Linux カーネルイメージのみを起動できます。

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

initvirtual 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を実行しこれは通常 ウィンドウマネージャ を開始します。ユーザがウィンドウマネージャを終了すると、xinitstartx、 シェル、 ログイン、の順序で終了して getty に戻ります。

参照