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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(英語版と同期してブートローダーを翻訳して追加)
(英語版と動悸して機能比較を追加)
41行目: 41行目:
   
 
{{Note|[[マイクロコード]] の更新を読み込むには、ブートローダの設定を調整する必要があります。 [https://www.archlinux.org/news/changes-to-intel-microcodeupdates/]}}
  
{{Note|[[マイクロコード]] の更新を読み込むには、ブートローダの設定を調整する必要があります。 [https://www.archlinux.org/news/changes-to-intel-microcodeupdates/]}}
  +
  +
=== 機能比較 ===
  +
  +
{{Note|
  +
GPT は UEFI 仕様の一部であるため、すべての UEFI ブートローダーは GPT ディスクをサポートします。BIOS システム上の GPT は、[https://www.rodsbooks.com/gdisk/hybrid.html HybridMBR]で "hybrid booting" を使うか、新しい [http://repo.or.cz/syslinux.git/blob/HEAD:/doc/gpt.txt GPTのみ] プロトコルを使うことで可能です。ただしこのプロトコルは特定の BIOS 実装で問題を引き起こす可能性があります。詳細については、[http://www.rodsbooks.com/gdisk/bios.html#bios書籍] を参照してください。
  +
* ファイルシステムのサポートで言及されている暗号化は [[wikipedia:Filesystem-level encryption|filesystem-level encryption]] であり [[dm-crypt|ブロックレベルの暗号化]] とは関係ありません。
  +
}}
  +
  +
{| class="wikitable sortable"
  +
! rowspan="2"| 名前
  +
! colspan="2"| ファームウェア
  +
! colspan="2"| [[パーティショニング#パーティションテーブル|パーティションテーブル]]
  +
! rowspan="2"| マルチブート
  +
! colspan="5"| [[ファイルシステム]]
  +
! rowspan="2"| 備考
  +
|-
  +
! BIOS !! [[UEFI]]
  +
! [[MBR]] !! [[GPT]]
  +
! [[Btrfs]] !! [[ext4]] !! ReiserFS !! [[VFAT]] !! [[XFS]]
  +
|-
  +
! [[EFISTUB]]
  +
| {{-}} || {{Yes}}
  +
| {{Yes}} || {{Yes}}
  +
| {{-}}
  +
| {{-}} || {{-}} || {{-}} || {{G|Inherited from firmware<sup>1</sup>}} || {{-}}
  +
| Kernel turned into EFI executable to be loaded directly from [[UEFI]] firmware or another boot loader.
  +
|-
  +
! [[Clover]]
  +
| {{G|Emulates UEFI}} || {{Yes}}
  +
| {{Yes}} || {{Yes}}
  +
| {{Yes}}<sup>2</sup>
  +
| {{No}} || {{Y|Without encryption}} || {{No}} || {{G|Inherited from firmware<sup>1</sup>}} || {{No}}
  +
| Fork of rEFIt modified to run [[wikipedia:Hackintosh|macOS on non-Apple hardware]].
  +
|-
  +
! [[GRUB]]
  +
| {{Yes}} || {{Yes}}
  +
| {{Yes}} || {{Yes}}
  +
| {{Yes}}
  +
| {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
  +
| On BIOS/GPT configuration requires a [[BIOS boot partition]]. <br/>Supports RAID, LUKS1 and LVM (but not thin provisioned volumes).
  +
|-
  +
! [[rEFInd]]
  +
| {{No}} || {{Yes}}
  +
| {{Yes}} || {{Yes}}
  +
| {{Yes}}<sup>2</sup>
  +
| {{Y|Without encryption}} || {{Y|Without encryption}} || {{Y|Without tail-packing feature}} || {{G|Inherited from firmware<sup>1</sup>}} || {{No}}
  +
| Supports auto-detecting kernels and parameters without explicit configuration.
  +
|-
  +
! [[Syslinux]]
  +
| {{Yes}} || {{Y|[[Syslinux#Limitations of UEFI Syslinux|Partial]]}}
  +
| {{Yes}} || {{Yes}}
  +
| {{Y|[[Syslinux#Chainloading|Partial]]}}
  +
| {{Y|Without: multi-device volumes, compression, encryption}} || {{Y|Without encryption}} || {{No}} || {{Yes}} || {{Y|MBR only; without sparse inodes}}
  +
| No support for certain [[file system]] features.[https://wiki.syslinux.org/wiki/index.php?title=Filesystem] <br/>Does not have file system drivers[https://bugzilla.syslinux.org/show_bug.cgi?id=33], can only access the file system it was installed to.
  +
|-
  +
! [[systemd-boot]]
  +
| {{No}} || {{Yes}}
  +
| {{Y|[https://github.com/systemd/systemd/issues/1125 Manual install only]}} || {{Yes}}
  +
| {{Yes}}<sup>2</sup>
  +
| {{No}} || {{No}} || {{No}} || {{G|Inherited from firmware<sup>1</sup>}} || {{No}}
  +
| Cannot launch binaries from partitions other than the [[ESP]] or the Extended Boot Loader Partition (XBOOTLDR partition).
  +
|-
  +
! {{Grey|[[GRUB Legacy]]}}
  +
| {{Yes}} || {{No}}
  +
| {{Yes}} || {{No}}
  +
| {{Yes}}
  +
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Y|XFS v4 only}}
  +
| [https://www.gnu.org/software/grub/grub-legacy.html Discontinued] in favor of [[GRUB]].
  +
|-
  +
! {{Grey|[[LILO]]}}
  +
| {{Yes}} || {{No}}
  +
| {{Yes}} || {{No}}
  +
| {{Yes}}
  +
| {{No}} || {{Y|Without encryption}} || {{Yes}} || {{Yes}} || {{Yes|http://xfs.org/index.php/XFS_FAQ#Q:_Does_LILO_work_with_XFS.3F}}
  +
| [https://web.archive.org/web/20180323163248/http://lilo.alioth.debian.org/ Discontinued] due to limitations (e.g. with Btrfs, GPT, RAID).
  +
|}
  +
  +
# ファイルシステムのサポートはファームウェアから継承されます。 UEFI 仕様では、FAT12、FAT16、および FAT32 ファイルシステムのサポートが義務付けられていますが、ベンダーはオプションで追加のファイルシステムのサポートを追加できます。[https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf#G17.1345080] たとえば、Apple [[Mac]] のファームウェアは HFS+ ファイルシステムをサポートしています。 ファームウェアが起動時に [[Unified Extensible Firmware Interface#UEFIドライバー| UEFIドライバー]] をロードするためのインターフェースを提供する場合、ファイルシステムドライバーを(個別に取得して)ロードすることにより、追加のファイルシステムのサポートを追加できます。
  +
#A [https://www.rodsbooks.com/efi-bootloaders/principles.html boot manager] 他の EFI アプリケーション、たとえば {{ic | 1 = CONFIG_EFI_STUB = y}} および Windows {{ic|bootmgfw.efi}} で構築された Linux カーネルイメージのみを起動できます。
  +
  +
[[Wikipedia:Comparison of boot loaders]] も参照してください。
   
 
== カーネル ==
  
== カーネル ==

2020年8月30日 (日) 19:56時点における版

関連記事

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

ブートプロセス

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 – Kernel turned into EFI executable to be loaded directly from UEFI firmware or another boot loader.
Clover Emulates UEFI Yes Yes Yes Yes2 No Without encryption No Inherited from firmware1 No Fork of rEFIt modified to run macOS on non-Apple hardware.
GRUB Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes On BIOS/GPT configuration requires a BIOS boot partition.
Supports RAID, LUKS1 and LVM (but not thin provisioned volumes).
rEFInd No Yes Yes Yes Yes2 Without encryption Without encryption Without tail-packing feature Inherited from firmware1 No Supports auto-detecting kernels and parameters without explicit configuration.
Syslinux Yes Partial Yes Yes Partial Without: multi-device volumes, compression, encryption Without encryption No Yes MBR only; without sparse inodes No support for certain file system features.[3]
Does not have file system drivers[4], can only access the file system it was installed to.
systemd-boot No Yes Manual install only Yes Yes2 No No No Inherited from firmware1 No Cannot launch binaries from partitions other than the ESP or the Extended Boot Loader Partition (XBOOTLDR partition).
GRUB Legacy Yes No Yes No Yes No No Yes Yes XFS v4 only Discontinued in favor of GRUB.
LILO Yes No Yes No Yes No Without encryption Yes Yes Yes Discontinued due to limitations (e.g. with Btrfs, GPT, RAID).
  1. ファイルシステムのサポートはファームウェアから継承されます。 UEFI 仕様では、FAT12、FAT16、および FAT32 ファイルシステムのサポートが義務付けられていますが、ベンダーはオプションで追加のファイルシステムのサポートを追加できます。[5] たとえば、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

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 に戻ります。

参照

「https://wiki.archlinux.jp/index.php?title=Arch_ブートプロセス&oldid=17594」から取得