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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(同期)
 
(8人の利用者による、間の55版が非表示)
1行目: 1行目:
 
[[Category:ブートプロセス]]
  
[[Category:ブートプロセス]]
 
[[Category:Arch について]]
  
[[Category:Arch について]]
−
[[ar:Arch Boot Process]]
 +
[[bs:Arch boot process]]
−
[[cs:Arch Boot Process]]
 +
[[en:Arch boot process]]
−
[[en:Arch Boot Process]]
 +
[[es:Arch boot process]]
−
[[es:Arch Boot Process]]
 +
[[fr:Arch boot process]]
−
[[fr:Processus de boot]]
 +
[[pt:Arch boot process]]
−
[[it:Arch Boot Process]]
 +
[[ru:Arch boot process]]
−
[[ru:Arch Boot Process]]
 +
[[zh-hans:Arch boot process]]
−
[[zh-CN:Arch Boot Process]]
  
 
{{Related articles start}}
  
{{Related articles start}}
−
{{Related|ブートローダー}}
  
 
{{Related|Master Boot Record}}
  
{{Related|Master Boot Record}}
 
{{Related|GUID Partition Table}}
  
{{Related|GUID Partition Table}}
 
{{Related|Unified Extensible Firmware Interface}}
  
{{Related|Unified Extensible Firmware Interface}}
 
{{Related|mkinitcpio}}
  
{{Related|mkinitcpio}}
  +
{{Related|init}}
 
{{Related|systemd}}
  
{{Related|systemd}}
 
{{Related|fstab}}
  
{{Related|fstab}}
 
{{Related|自動起動}}
  
{{Related|自動起動}}
 
{{Related articles end}}
  
{{Related articles end}}
−
Arch Linux を起動するためには、[[GRUB|GRUB]] や [[Syslinux|Syslinux]] などの Linux 対応のブートローダを、[[Master Boot Record|Master Boot Record]] もしくは [[GUID Partition Table|GUID Partition Table]] にインストールする必要があります。ブートローダは、ブートプロセスが始まる前にカーネルや[[mkinitcpio|初期 RAM ディスク]]をロードする仕事を行います。[[Wikipedia:ja:BIOS|BIOS]] と [[Unified Extensible Firmware Interface|UEFI]] で起動の流れはかなり異なっています。このページや関連するページに詳しい説明があります。
  
   
  +
Arch Linux を起動するためには、Linux 対応の[[#ブートローダー|ブートローダー]]をセットアップする必要があります。ブートローダは、ブートプロセスが始まる前にカーネルや[[#initramfs|初期 RAM ディスク]]をロードする仕事を行います。[[Wikipedia:ja:BIOS|BIOS]] と [[Unified Extensible Firmware Interface|UEFI]] で起動の流れはかなり異なっています。このページや関連するページに詳しい説明があります。
−
== ブートプロセス ==
  
  +
  +
== ファームウェアの種類 ==
  +
  +
ファームウェアは、システムの電源を入れた時に一番最初に実行されるプログラムのことです。
  +
  +
{{Tip|BIOS や (U)EFI という語は、ファームウェアという語の代わりにしばしば用いられます。}}
   
 
=== BIOS ===
  
=== BIOS ===
  +
−
# システムの電源が入れられ [[Wikipedia:ja:Power On Self Test|POST]] が実行される
  
  +
[[Wikipedia:ja:BIOS|BIOS]] (Basic Input-Outout System) は、ほとんどの場合マザーボード内のフラッシュメモリに保存され、システムストレージとは独立しています。元々は [[Wikipedia:IBM PC|IBM PC]] がハードウェアの初期化やブートプロセスを処理するために作成されました。2010 年より、BIOS にあるような技術的な制約が存在しない [[#UEFI|UEFI]] に徐々に置き換えられています。
−
# BIOS がブートに必要なシステムハードウェア (ディスクやキーボードコントローラなど) を初期化する
  
−
# (BIOS のディスク順で) 最初のディスクの最初の440バイト ([[Master Boot Record|Master Boot Record]]) が BIOS によって実行される
  
−
# BIOS から MBR ブートコードにコントロールが移り、次のステージのコードが起動する (通常は[[ブートローダー]]のコード)
  
−
# 起動した（2番目の）コード（ブートローダー）はサポートと設定ファイルを読み込む
  
−
# 設定ファイルのデータに基づき、ブートローダーはカーネルと initramfs をシステムメモリ (RAM) にロードしてカーネルを起動する
  
   
 
=== UEFI ===
  
=== UEFI ===
  +
−
次のページを参照してください: [[Unified Extensible Firmware Interface#UEFI のブートプロセス]]
  
  +
[[Unified Extensible Firmware Interface]] は、パーティションテーブルとファイルシステムの両方の読み取りをサポートしています。UEFI は [[パーティショニング#Master Boot Record (bootstrap code)|Master Boot Record (MBR) 内のブートコード]]を起動しません (たとえ、それが有ろうと無かろうと)。代わりに、起動は [[Wikipedia:Non-volatile random-access memory|NVRAM]] 内のブートエントリに頼っています。
  +
  +
UEFI 仕様では [[FAT|FAT12、FAT16、および FAT32]] ファイルシステム ([https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format-1 UEFI 仕様バージョン2.8、セクション13.3.1.1] を参照) のサポートが義務付けられていますが、規格に準拠しているベンダーは任意でファイルシステムのサポートを追加できます。たとえば、Apple の一部のファームウェアでは [[Wikipedia:HFS+|HFS+]] か [[Wikipedia:APFS|APFS]] のサポートがあります。UEFI の実装では、光ディスク用の [[Wikipedia:ja:ISO 9660|ISO 9660]] もサポートされています。
  +
  +
UEFIは、[[#ブートローダー|ブートローダー]] 、ブートマネージャ、 [[Unified_Extensible_Firmware_Interface#UEFI シェル |UEFI シェル]] などの EFI アプリケーションを起動します。これらのアプリケーションは通常、 [[EFI システムパーティション]] にファイルとして保存されます。各ベンダーは、EFI システムパーティションの {{ic|/EFI/''vendor_name''}} フォルダにファイルを格納できます。アプリケーションを起動するには、NVRAM に、または UEFI シェルからブートエントリを追加します。
  +
  +
UEFI 仕様では、[[Wikipedia:ja:Unified_Extensible_Firmware_Interface|互換性サポートモジュール (CSM)]] によるレガシー [[#BIOS|BIOS]] ブートがサポートされています。UEFI で CSM が有効な場合、UEFI はすべてのドライブの CSM ブートエントリを生成します。CSM ブートエントリがブート元として選択された場合、UEFI の CSM はドライブの MBR ブートストラップコードからのブートを試みます。
  +
  +
{{Note|Intel は CSM のサポートを徐々に終了しつつあります。将来的に、この機能に頼ることは不可能になるかもしれません。[https://www.intel.com/content/dam/support/us/en/documents/intel-nuc/Legacy-BIOS-Boot-Support-Removal-for-Intel-Platforms.pdf]}}
  +
  +
== システムの初期化 ==
  +
  +
=== BIOS ===
  +
  +
# システムの電源が入れられ [[Wikipedia:ja:Power On Self Test|POST]] が実行される。
  +
# BIOS が、ブートに必要なシステムハードウェア (ディスクやキーボードコントローラなど) を初期化する。
  +
# BIOS のディスク順で最初のディスクの最初の440バイト ([[Master Boot Record|Master Boot Record]]) が BIOS によって実行される。
  +
# MBR ブートコード内の、ブートローダの最初のステージが、2番めのステージコードを以下のどれかから実行する:
  +
#* MBR の次のディスクセクタ。つまり、post-MBR gap と呼ばれる部分(MBR パーティションテーブルにしか存在しません)。
  +
#* パーティション、あるいはパーティションレスディスクの [[Wikipedia:Volume boot record|ボリュームブートレコード (VBR)]]。
  +
#* GPT でパーティショニングされたディスク上の [[GRUB]] の場合、GRUB 固有の [[BIOS ブートパーティション]] (GPT には存在しない MBR の後ろの隙間の代わりとして使用されます)。
  +
# [[#ブートローダー|ブートローダー]]本体が起動される。
  +
# ブートローダーがオペレーティングシステムのカーネルをチェインロード、または直接ロードして、オペレーティングシステムをロードする。
  +
  +
=== UEFI ===
  +
  +
# システムのスイッチが入り、[[Wikipedia:ja:Power On Self Test|power-on self-test (POST)]] が実行される。
  +
# POST 後に、UEFI は起動に必要なハードウェア(ディスク、キーボード、コントローラなど)を初期化する。
  +
# ファームウェアは NVRAM 内のブートエントリを読み込み、どの EFI アプリケーションを起動するかや、どこから(例えば、どのディスクやパーティションから)起動するかを判断する。
  +
#* ブートエントリは単にディスクであることもあります。この場合、ファームウェアは [[EFI システムパーティション]]をそのディスク上から探し、フォールバックブートパス {{ic|\EFI\BOOT\BOOTx64.EFI}}([[Unified Extensible Firmware Interface#UEFI ファームウェアのビット数|IA32 (32-bit) UEFI のシステム]]では {{ic|BOOTIA32.EFI}})から EFI アプリケーションを見つけようとします。これは UEFI の起動可能リムーバブルメディアの動作です。
  +
# ファームウェアが EFI アプリケーションを起動する。
  +
#* そのアプリケーションは[[#ブートローダ|ブートローダ]]や、[[EFI ブートスタブ]]を使用する Arch [[カーネル]]自体であることもあります。
  +
#* そのアプリケーションは他の EFI アプリケーション([[UEFI シェル]] や、[[systemd-boot]] や [[rEFInd]] などの [[#ブートローダ|ブートマネージャ]])であることもあります。
  +
  +
[[セキュアブート]] が有効化されている場合、ブートプロセスでは EFI バイナリの正統性を署名によって検証します。
  +
  +
{{Note|一部の UEFI システムはフォールバックブートパスからしか起動できません。}}
  +
  +
==== UEFI でのマルチブート ====
  +
  +
それぞれの OS やベンダーは互いに影響を与えずに [[EFI システムパーティション]] 内に固有のファイルを保持することができるので、UEFI を用いたマルチブートは単に、特定のオペレーティングシステムのブートローダに対応する異なる EFI アプリケーションを起動する問題になります。ゆえに、他の OS をロードするためにブートローダの[[Wikipedia:Chain loading|チェインロード]]メカニズムに頼る必要がありません。
  +
  +
[[Windows と Arch のデュアルブート]] も参照してください。
  +
  +
== ブートローダー ==
  +
  +
ブートローダーは、ファームウェア([[Wikipedia:BIOS|BIOS]] または [[UEFI]])によって起動されるソフトウェアの一部です。ブートローダーは、必要な[[カーネルパラメータ]]と任意の外部の初期 RAM ディスクイメージと共にカーネルをロードします。UEFI の場合、[[EFI ブートスタブ]]を使用して、UEFI からカーネル自体を直接起動できます。ブート前にカーネルパラメータを編集するために、別のブートローダやブートマネージャを使うこともできます。
  +
  +
{{Warning|Arch を正しくブートするには、ブートローダーが、たいてい {{ic|/boot}} ディレクトリ内にあるカーネル及び initramfs イメージへアクセスする必要があります。つまり、ブートローダーは、ブロックデバイスからスタックされたブロックデバイス (LVM、RAID、dm-crypt、LUKSなど) まで、カーネルや initramfs イメージが存在するファイルシステムまで、すべてをサポートしなければなりません。
  +
  +
しかし、そのようなスタックされたブロックデバイスをサポートするブートローダーは稀ですし、ブートローダーによってまだサポートされていない機能がファイルシステムに追加されることもある (例: {{Issue|archlinux/packaging/packages/grub|7}}、{{Bug|79857}}、{{Bug|59047}}、{{Bug|58137}}、{{Bug|51879}}、{{Bug|46856}}、{{Bug|38750}}、{{Bug|21733}}、[[fscrypt]] によって暗号化されたディレクトリ) ので、広くサポートされているファイルシステム ([[FAT32]] など) でフォーマットされた個別の [[パーティショニング#/boot|/boot パーティション]]を使うほうがほとんどの場合、現実的です。
  +
}}
  +
  +
=== 機能比較 ===
  +
  +
{{Note|
  +
* GPT は UEFI 仕様の一部であるため、すべての UEFI ブートローダーは GPT ディスクをサポートします。BIOS システム上の GPT は、[https://www.rodsbooks.com/gdisk/hybrid.html Hybrid MBR] で "hybrid booting" を使うか、新しい [https://repo.or.cz/syslinux.git/blob/HEAD:/doc/gpt.txt GPT-only] プロトコルを使うことで可能です。ただしこのプロトコルは特定の BIOS 実装で問題を引き起こす可能性があります。詳細については、[https://www.rodsbooks.com/gdisk/bios.html#bios rodsbooks] を参照してください。
  +
* [[セキュアブート]]は UEFI 規格の一部なので、全ての UEFI ブートローダーは[[セキュアブート]]をサポートしています。ただし、いくつかの制限があります。
  +
}}
  +
  +
{| class="wikitable sortable"
  +
! rowspan="2" | 名前
  +
! colspan="2" | ファームウェア
  +
! colspan="2" | [[パーティショニング#パーティションテーブル|パーティションテーブル]]
  +
! rowspan="2" | マルチブート
  +
! rowspan="2" | [[ファイルシステム]]
  +
! rowspan="2" | 備考
  +
|-
  +
! BIOS !! [[UEFI]]
  +
! [[MBR]] !! [[GPT]]
  +
|-
  +
! [[EFI ブートスタブ]]
  +
| {{-}}
  +
| {{Yes}}<sup>1</sup>
  +
| {{Yes}} || {{Yes}}
  +
| {{-}}
  +
| {{G|ファームウェアから継承<sup>2</sup>}}
  +
| カーネルイメージは、UEFI または他の UEFI ブートローダーから直接起動することのできる 有効な EFI 実行ファイルです。
  +
|-
  +
! [[Unified カーネルイメージ]]
  +
| {{-}}
  +
| {{Yes}}<sup>3</sup>
  +
| {{Yes}} || {{Yes}}
  +
| {{-}}
  +
| {{G|ファームウェアから継承<sup>2</sup>}}
  +
| {{man|7|systemd-stub}} やカーネル、initramfs、カーネルコマンドラインを EFI 実行ファイルにパックしたものです。UEFI ファームウェアや他のブートローダから直接読み込めます。
  +
|-
  +
! [[GRUB]]
  +
| {{Yes}}
  +
| {{Yes}}<sup>3</sup>
  +
| {{Yes}} || {{Yes}}
  +
| {{Yes}}
  +
| {{G|[[GRUB#サポートされているファイルシステム|内蔵]]}}
  +
| RAID、LUKS (ただし Argon2 PBKDF 以外)、LVM をサポートします (シンプロビジョニングボリュームはサポートしません)。環境固有の制限については [[GRUB]] を見てください。
  +
|-
  +
! [[Limine]]
  +
| {{Yes}}
  +
| {{Yes}}
  +
| {{Yes}} || {{Yes}}
  +
| {{Yes}}
  +
| {{Y|[[Limine#サポートされているファイルシステム|制限有り]]}}
  +
|
  +
|-
  +
! [[rEFInd]]
  +
| {{No}}
  +
| {{Yes}}
  +
| {{Yes}} || {{Yes}}
  +
| {{Yes}}<sup>4</sup>
  +
| {{G|[[rEFInd#サポートされているファイルシステム|拡張可能]]<sup>2,5</sup>}}
  +
| 明示的な構成なしでカーネルとパラメーターの自動検出をサポートします。そして、fastboot をサポートします[https://bbs.archlinux.org/viewtopic.php?id=258805]。
  +
|-
  +
! [[Syslinux]]
  +
| {{Yes}}
  +
| {{Y|[[Syslinux#UEFI Syslinux の制限|部分的]]<sup>1</sup>}}
  +
| {{Yes}} || {{Yes}}
  +
| {{Y|[[Syslinux#チェインロード|部分的]]}}
  +
| {{Y|[[Syslinux#サポートされているファイルシステム|制限有り]]}}
  +
| ファイルシステムの特定の機能はサポートされていません。<br/>Syslinux が[[Syslinux#チェインロード|インストールされている]]ファイルシステムにしかアクセスできません。
  +
|-
  +
! [[systemd-boot]]
  +
| {{No}}
  +
| {{Yes}}<sup>3</sup>
  +
| {{Y|[https://github.com/systemd/systemd/issues/1125 手動]}} || {{Yes}}
  +
| {{Yes}}<sup>4</sup>
  +
| {{G|[[systemd-boot#サポートされているファイルシステム|拡張可能]]<sup>2,5</sup>}}
  +
| systemd-boot がインストールされている [[ESP]]、または、同じディスク上の Extended Boot Loader Partition (XBOOTLDR パーティション) 内のバイナリしか起動できません。<br/>{{ic|''esp''/EFI/Linux/}} 内の [[unified カーネルイメージ]] を自動的に検出します。
  +
|-
  +
! {{Grey|[[GRUB Legacy]]}}
  +
| {{Yes}}
  +
| {{No}}
  +
| {{Yes}} || {{No}}
  +
| {{Yes}}
  +
| {{Y|[[GRUB Legacy#サポートされているファイルシステム|制限有り]]}}
  +
| [https://www.gnu.org/software/grub/grub-legacy.html 開発停止]。[[GRUB]] に移行。
  +
|-
  +
! {{Grey|[[LILO]]}}
  +
| {{Yes}}
  +
| {{No}}
  +
| {{Yes}} || {{Y|[https://salsa.debian.org/joowie-guest/upstream_lilo/-/commit/29a64e6b92cac22d472f4b352de5b1535e4afc5f 部分的]}}
  +
| {{Yes}}
  +
| {{Y|[[LILO#サポートされているファイルシステム|制限有り]]}}
  +
| (Btrfs、GPT、RAID、暗号化などの) 制限により[https://web.archive.org/web/20180323163248/http://lilo.alioth.debian.org/ 開発停止]。
  +
|}
  +
  +
# バイナリは[[セキュアブート]]のために署名することはできますが、検証はされません。なので、信用の鎖はここで切れてしまいます。
  +
# ファイルシステムのサポートはファームウェアから継承されます。UEFI 仕様では、FAT12、FAT16、および FAT32 ファイルシステムのサポートが義務付けられていますが [https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format-1]、ベンダーはオプションで追加のファイルシステムのサポートを追加できます。たとえば、Apple [[Mac]] のファームウェアは HFS+ ファイルシステムをサポートしています。 ファームウェアが起動時に [[Unified Extensible Firmware Interface#UEFI ドライバ|UEFIドライバー]] をロードするためのインターフェースを提供する場合、ファイルシステムドライバーを(個別に取得して)ロードすることにより、追加のファイルシステムのサポートを追加できます。
  +
# Mixed mode ブートをサポートしています。つまり、[[Unified Extensible Firmware Interface#UEFI ファームウェアのビット数|32 ビット IA32 UEFI]] 上で 64 ビット x86_64 Linux カーネルをブートできます。
  +
# [https://www.rodsbooks.com/efi-bootloaders/principles.html ブートマネージャー]。他の EFI アプリケーション、たとえば {{ic | 1 = CONFIG_EFI_STUB = y}} フラグありでビルドされた Linux カーネルイメージおよび [https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-and-uefi#understanding-the-windows-boot-manager Windows Boot Manager] ({{ic|bootmgfw.efi}}) のみを起動できます。
  +
# [[Unified Extensible Firmware Interface#UEFI ドライバ|UEFI ファイルシステムドライバ]]の読み込みをサポートしています。
  +
  +
[[Wikipedia:Comparison of boot loaders]] も参照してください。
   
 
== カーネル ==
  
== カーネル ==
  +
−
カーネルはオペレーティングシステムのコアです。ローレベル (''カーネル空間'') で、マシンのハードウェアとハードウェアを使って実行されるプログラムを橋渡しします。CPU を効率的に利用するために、カーネルはスケジューラーを使ってどのタスクが優先的に実行されるかを決定し、多くのタスクが同時に実行されるのを可能にしています。
  
  +
[[#ブートローダー|ブートローダー]] は、[[カーネル]]を含んでいる [[Wikipedia:ja:vmlinux|vmlinux イメージ]]を起動します。
  +
  +
カーネルは、マシンのハードウェアとプログラムとの間を仲介する低いレベル(''カーネル空間'')で機能します。カーネルは、ユーザスペースに移行する前にまずハードウェアの列挙と初期化を行います。より詳細な説明は [[Wikipedia:ja:カーネル]] と [[Wikipedia:ja:Linuxカーネル]] を見てください。
   
 
== initramfs ==
  
== initramfs ==
−
カーネルがロードされた後、カーネルは [[mkinitcpio|initramfs]] (initial RAM ファイルシステム) を解凍して、initial root ファイルシステムにします。カーネルは最初のプロセスとして {{ic|/init}} を起動します。''初期ユーザー空間''の始まりです。
  
   
  +
{{ic|/}} のルートファイルシステムは空の [https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html rootfs] として始まります。これは ramfs や tmpfs の特殊なインスタンスです。これは一時的なルートファイルシステムで、initramfs (''init''ial ''RAM'' ''f''ile ''s''ystem) イメージがここへ解凍されます。
−
initramfs の目的は root ファイルシステムにアクセスできる位置にシステムをブートストラップすることです (詳しくは [[FHS]] を見て下さい)。これは IDE, SCSI, SATA, USB/FW (外部ハードウェアから起動する場合) などのデバイスのために必要なモジュールがカーネルに入っていない場合 initramfs からモジュールをロードできなくてはならないということを意味しています; (プログラムやスクリプトから明示的に指定されるか [[udev|udev]] を通すかして) 正しいモジュールがロードされると、ブートプロセスが再開されます。従って、initramfs に含めなくてはならないのは root ファイルシステムにアクセスするために必要なモジュールだけで、使用する全てのモジュールを入れる必要はありません。ほとんどのモジュールは後の init プロセス中に、udev によってロードされます。
  
   
  +
Initramfs の主な目的は root ファイルシステムにアクセスできる位置にシステムをブートストラップすることです (詳しくは [[FHS]] を見て下さい)。これには、[[dm-crypt]]、[[dm-verity]]、{{man|8|systemd-repart}} などを通してルートファイルシステムが存在しているであろうストレージスタックのセットアップなどが含まれます。また、[[udev]] を介して[[永続的なブロックデバイスの命名]]を実際のデバイスに解決することも行われます。これは NVMe、SATA、SAS、eMMC、USB (外部ハードウェアから起動する場合) などのデバイスのために必要なモジュールがカーネルに入っていない場合 initramfs からモジュールをロードできなくてはならないということを意味しています; (プログラムやスクリプトから明示的に指定されるか [[udev]] を通すかして) 正しいモジュールがロードされると、ブートプロセスが再開されます。従って、initramfs に含めなくてはならないのは root ファイルシステムにアクセスするために必要なモジュールだけで、使用する全てのモジュールを入れる必要はありません。ほとんどのモジュールは後の init プロセス中に、ルート ({{ic|/}}) を実際のルートファイルシステムに切り替えた後で [[udev]] によってロードされます。
−
== Init プロセス ==
  
   
  +
まず、カーネルは組み込みの initramfs を一時的なルートファイルシステムに解凍します。Arch Linux の[[カーネル#公式サポートカーネル|公式カーネル]]では組み込みの initramfs として空のアーカイブが用いられます(Linux のビルドの際のデフォルトです)。そして、カーネルは、[[#ブートローダー|ブートローダー]]から渡されたコマンドラインにより指定された外部の initramfs ファイルを解凍します。この際、組み込みの initramfs にあったファイルは上書きされます。このような外部の initramfs イメージは [[mkinitcpio]] や [[dracut]]、[[booster]] によって生成でき、Arch の''初期ユーザ空間''のセットアップの方法として推奨されています。
−
初期ユーザー空間の最終段階として、本当の root がマウントされ、initial root ファイルシステムを置き換えます。{{ic|/sbin/init}} が実行され、{{ic|/init}} プロセスを置き換えます。Arch は init プロセスとして [[systemd|systemd]] を使っています。
  
  +
  +
Initramfs には、ルートファイルシステムをセットアップする以外の役割もあります。ルートファイルシステムがマウントされる前にしか行うことができないタスク ([[fsck]] や[[ハイバネート]]からの復帰など) が存在するのです。
  +
  +
また、Linux [[カーネル]]は、カーネルが開始された最初のルートファイルシステムを[https://github.com/torvalds/linux/blob/1b907d0507354b74a4f2c286380cd6059af79248/fs/namespace.c#L4222 留めておきます]。Initramfs が使用されなかった場合、シャットダウン時に実際のルートファイルシステムが正しくアンマウントされない可能性があります。
  +
  +
== 初期ユーザ空間 ==
  +
  +
''初期ユーザ空間''の段階は一時的なルートファイルシステムがマウントされている状態で行われ、[[#initramfs|initramfs]] により提供されたファイルで動作します。
  +
  +
初期ユーザ空間の機能は[[Mkinitcpio#HOOKS|設定可能]]ですが、一般的に以下のようなことを行います:
  +
  +
* {{man|8|systemd-modules-load}} がカーネルモジュールを読み込みます。例えば、本物のルートファイルシステムをマウントするために必要なブロックデバイスモジュールなどです。
  +
* 必要ならば、本物のルートファイルシステムの復号処理を行います。
  +
* DRM モジュールをロードします。[[カーネルモード設定#KMS の早期開始|KMS の早期開始]]は、ツリー内のモジュールに対してはデフォルトで有効化されています。
  +
  +
初期ユーザー空間の最終段階として、本物のルートファイルシステムが {{ic|/sysroot/}} ([[systemd]] ベースの initramfs の場合) または {{ic|/new_root/}} (busybox ベースの場合) にマウントされ、それに切り替わります。本物のルートファイルシステムから [[init]] プログラムを実行することにより、後期ユーザ空間が始まります。
  +
  +
== 後期ユーザ空間 ==
  +
  +
[[init]] プロセスにより後期ユーザ空間のスタートアップが実行されます。Arch では公式には、ユニットとサービスの概念の上に構築された [[systemd]] が用いられます。しかし、ここで言及している機能は他の init システムと重なります。
  +
  +
=== getty ===
  +
  +
init プロセスは [[Wikipedia:Virtual console|仮想コンソール]](典型的には6つ)ごとに [[getty]] を1回呼び出します。''getty'' はそれぞれのターミナルを初期化して、認証されていないユーザからターミナルを保護します。ユーザ名とパスワードが与えられると、''getty'' はそれらを {{ic|/etc/passwd}} と {{ic|/etc/shadow}} と照合し、{{man|1|login}} を呼び出します。
  +
  +
==== ログイン ====
  +
  +
''ログイン'' プログラムは、環境変数を設定し、{{ic|/etc/passwd}} に基づいてユーザーのシェルを起動することによって、ユーザーのセッションを開始します。''ログイン'' プログラムは、ログインに成功するとログインシェルを実行する直前に [[Wikipedia:motd (Unix) |/etc/motd]] (''m''essage ''o''f ''t''he ''d''ay) の内容を表示します。利用規約を表示してユーザーに地域のポリシーや伝えたいことを思い出させるのに適した場所です。
  +
  +
==== シェル ====
  +
  +
ユーザーの [[シェル]] が起動されると、通常はユーザーにプロンプトを表示する前に [[bashrc]] などの実行時設定ファイルが実行されます。アカウントが [[%E3%83%AD%E3%82%B0%E3%82%A4%E3%83%B3%E6%99%82%E3%81%AB_X_%E3%82%92%E8%B5%B7%E5%8B%95]] に設定されている場合、実行時設定ファイルは [[startx]] または [[xinit]] を呼び出します。
  +
  +
=== ディスプレイマネージャ ===
  +
  +
さらに、[[init]] は、指定した仮想コンソールで ''getty'' の代わりに[[ディスプレイマネージャ]]を起動するように設定できます。そうするには、該当する [[systemd#ユニットを使う|systemd service ファイル]]を手動で[[有効化]]する必要があります。そうしたら、ディスプレイマネージャーがグラフィカルセッションを起動します。
  +
  +
==== グラフィカルセッション ====
  +
  +
[[xinit]] はユーザの [[xinitrc]] ランタイム設定ファイルを実行し、通常、[[ウィンドウマネージャ]]や[[デスクトップ環境]]を開始します。ユーザが終了すると、''xinit''、 ''startx''、 シェル、 ログインの順序で終了して [[#getty|getty]]、またはディスプレイマネージャに戻ります。
   
 
== 参照 ==
  
== 参照 ==
  +
−
* [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]
  
  +
* [[Wikipedia:Booting process of Linux]]
−
* [http://www.ibm.com/developerworks/linux/library/l-linuxboot/ Inside the Linux boot process]
  
  +
* [https://web.archive.org/web/20230313210814/https://developer.ibm.com/articles/l-linuxboot/ Inside the Linux boot process]
−
* [http://www.linuxjournal.com/article/4622 Boot with GRUB]
  
  +
* [https://www.rodsbooks.com/efi-bootloaders/ Rod Smith - Managing EFI Boot Loaders for Linux]
−
* [[Wikipedia:Linux startup process]]
  
  +
* [https://neosmart.net/wiki/mbr-boot-process/ NeoSmart: The BIOS/MBR Boot Process]
−
* [[Wikipedia:ja:initrd]]
  
  +
* [https://0pointer.net/blog/linux-boot-partitions.html Lennart Poettering - Linux Boot Partitions and How to Set Them Up]
−
* [http://www.cyberciti.biz/faq/grub-boot-into-single-user-mode/ Boot Linux Grub Into Single User Mode]
  
  +
* [[Wikipedia:initrd]]
  +
* [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ Early Userspace in Arch Linux]
  +
* [https://www.linux.com/learn/kernel-newbie-corner-initrd-and-initramfs-whats Kernel Newbie Corner: initrd and initramfs]
  +
* {{man|7|bootup}} (Systemd initrd とユーザー空間に関する部分についてがほとんど)
  +
  +
{{TranslationStatus|Arch boot process|2024-09-22|816947}}

2024年9月22日 (日) 17:11時点における最新版

関連記事

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

ファームウェアの種類

ファームウェアは、システムの電源を入れた時に一番最初に実行されるプログラムのことです。

ヒント: BIOS や (U)EFI という語は、ファームウェアという語の代わりにしばしば用いられます。

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 ブートストラップコードからのブートを試みます。

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

システムの初期化

BIOS

  1. システムの電源が入れられ POST が実行される。
  2. BIOS が、ブートに必要なシステムハードウェア (ディスクやキーボードコントローラなど) を初期化する。
  3. BIOS のディスク順で最初のディスクの最初の440バイト (Master Boot Record) が BIOS によって実行される。
  4. MBR ブートコード内の、ブートローダの最初のステージが、2番めのステージコードを以下のどれかから実行する:
    • MBR の次のディスクセクタ。つまり、post-MBR gap と呼ばれる部分(MBR パーティションテーブルにしか存在しません)。
    • パーティション、あるいはパーティションレスディスクの ボリュームブートレコード (VBR)。
    • GPT でパーティショニングされたディスク上の GRUB の場合、GRUB 固有の BIOS ブートパーティション (GPT には存在しない MBR の後ろの隙間の代わりとして使用されます)。
  5. ブートローダー本体が起動される。
  6. ブートローダーがオペレーティングシステムのカーネルをチェインロード、または直接ロードして、オペレーティングシステムをロードする。

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 アプリケーションを起動する。

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

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

UEFI でのマルチブート

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

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

ブートローダー

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

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

しかし、そのようなスタックされたブロックデバイスをサポートするブートローダーは稀ですし、ブートローダーによってまだサポートされていない機能がファイルシステムに追加されることもある (例: テンプレート:Issue、FS#79857、FS#59047、FS#58137、FS#51879、FS#46856、FS#38750、FS#21733、fscrypt によって暗号化されたディレクトリ) ので、広くサポートされているファイルシステム (FAT32 など) でフォーマットされた個別の /boot パーティションを使うほうがほとんどの場合、現実的です。

機能比較

ノート:
  • GPT は UEFI 仕様の一部であるため、すべての UEFI ブートローダーは GPT ディスクをサポートします。BIOS システム上の GPT は、Hybrid MBR で "hybrid booting" を使うか、新しい GPT-only プロトコルを使うことで可能です。ただしこのプロトコルは特定の BIOS 実装で問題を引き起こす可能性があります。詳細については、rodsbooks を参照してください。
  • セキュアブートは UEFI 規格の一部なので、全ての UEFI ブートローダーはセキュアブートをサポートしています。ただし、いくつかの制限があります。
名前 ファームウェア パーティションテーブル マルチブート ファイルシステム 備考
BIOS UEFI MBR GPT
EFI ブートスタブ – Yes1 Yes Yes – ファームウェアから継承2 カーネルイメージは、UEFI または他の UEFI ブートローダーから直接起動することのできる 有効な EFI 実行ファイルです。
Unified カーネルイメージ – Yes3 Yes Yes – ファームウェアから継承2 systemd-stub(7) やカーネル、initramfs、カーネルコマンドラインを EFI 実行ファイルにパックしたものです。UEFI ファームウェアや他のブートローダから直接読み込めます。
GRUB Yes Yes3 Yes Yes Yes 内蔵 RAID、LUKS (ただし Argon2 PBKDF 以外)、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、暗号化などの) 制限により開発停止。
  1. バイナリはセキュアブートのために署名することはできますが、検証はされません。なので、信用の鎖はここで切れてしまいます。
  2. ファイルシステムのサポートはファームウェアから継承されます。UEFI 仕様では、FAT12、FAT16、および FAT32 ファイルシステムのサポートが義務付けられていますが [3]、ベンダーはオプションで追加のファイルシステムのサポートを追加できます。たとえば、Apple Mac のファームウェアは HFS+ ファイルシステムをサポートしています。 ファームウェアが起動時に UEFIドライバー をロードするためのインターフェースを提供する場合、ファイルシステムドライバーを(個別に取得して)ロードすることにより、追加のファイルシステムのサポートを追加できます。
  3. Mixed mode ブートをサポートしています。つまり、32 ビット IA32 UEFI 上で 64 ビット x86_64 Linux カーネルをブートできます。
  4. ブートマネージャー。他の EFI アプリケーション、たとえば CONFIG_EFI_STUB = y フラグありでビルドされた Linux カーネルイメージおよび Windows Boot Manager (bootmgfw.efi) のみを起動できます。
  5. 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-verity、systemd-repart(8) などを通してルートファイルシステムが存在しているであろうストレージスタックのセットアップなどが含まれます。また、udev を介して永続的なブロックデバイスの命名を実際のデバイスに解決することも行われます。これは NVMe、SATA、SAS、eMMC、USB (外部ハードウェアから起動する場合) などのデバイスのために必要なモジュールがカーネルに入っていない場合 initramfs からモジュールをロードできなくてはならないということを意味しています; (プログラムやスクリプトから明示的に指定されるか udev を通すかして) 正しいモジュールがロードされると、ブートプロセスが再開されます。従って、initramfs に含めなくてはならないのは root ファイルシステムにアクセスするために必要なモジュールだけで、使用する全てのモジュールを入れる必要はありません。ほとんどのモジュールは後の init プロセス中に、ルート (/) を実際のルートファイルシステムに切り替えた後で udev によってロードされます。

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

Initramfs には、ルートファイルシステムをセットアップする以外の役割もあります。ルートファイルシステムがマウントされる前にしか行うことができないタスク (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、またはディスプレイマネージャに戻ります。

参照

翻訳ステータス: このページは en:Arch boot process の翻訳バージョンです。最後の翻訳日は 2024-09-22 です。もし英語版に 変更 があれば、翻訳の同期を手伝うことができます。
「https://wiki.archlinux.jp/index.php?title=Arch_ブートプロセス&oldid=39062」から取得