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

提供: ArchWiki
ナビゲーションに移動 検索に移動
(英語版と動悸して機能比較を追加)
(→‎機能比較: 備考を翻訳)
66行目: 66行目:
 
| {{-}}
  
| {{-}}
 
| {{-}} || {{-}} || {{-}} || {{G|Inherited from firmware<sup>1</sup>}} || {{-}}
  
| {{-}} || {{-}} || {{-}} || {{G|Inherited from firmware<sup>1</sup>}} || {{-}}
  +
| カーネルはEFI実行可能ファイルに変換され、[[UEFI]] ファームウェアまたは別のブートローダーから直接ロードされます。
−
| Kernel turned into EFI executable to be loaded directly from [[UEFI]] firmware or another boot loader.
  
 
|-
  
|-
 
! [[Clover]]
  
! [[Clover]]
72行目: 72行目:
 
| {{Yes}} || {{Yes}}
  
| {{Yes}} || {{Yes}}
 
| {{Yes}}<sup>2</sup>
  
| {{Yes}}<sup>2</sup>
−
| {{No}} || {{Y|Without encryption}} || {{No}} || {{G|Inherited from firmware<sup>1</sup>}} || {{No}}
 +
| {{No}} || {{Y|暗号化なし}} || {{No}} || {{G|Inherited from firmware<sup>1</sup>}} || {{No}}
−
| Fork of rEFIt modified to run [[wikipedia:Hackintosh|macOS on non-Apple hardware]].
 +
| rEFIt のフォークは、[[wikipedia:OSx86|macOS on non-Apple hardware]] を実行するように変更されました。
 
|-
  
|-
 
! [[GRUB]]
  
! [[GRUB]]
80行目: 80行目:
 
| {{Yes}}
  
| {{Yes}}
 
| {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
  
| {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}} || {{Yes}}
  +
| BIOS / GPT 構成では、[[GRUB#BIOS|BIOSシステム]] が必要です。 <br/> RAID、LUKS1、LVMをサポートします(シンプロビジョニングボリュームはサポートしません)
−
| On BIOS/GPT configuration requires a [[BIOS boot partition]]. <br/>Supports RAID, LUKS1 and LVM (but not thin provisioned volumes).
  
 
|-
  
|-
 
! [[rEFInd]]
  
! [[rEFInd]]
86行目: 86行目:
 
| {{Yes}} || {{Yes}}
  
| {{Yes}} || {{Yes}}
 
| {{Yes}}<sup>2</sup>
  
| {{Yes}}<sup>2</sup>
−
| {{Y|Without encryption}} || {{Y|Without encryption}} || {{Y|Without tail-packing feature}} || {{G|Inherited from firmware<sup>1</sup>}} || {{No}}
 +
| {{Y|暗号化なし}} || {{Y|暗号化なし}} || {{Y|Without tail-packing feature}} || {{G|Inherited from firmware<sup>1</sup>}} || {{No}}
  +
| 明示的な構成なしでカーネルとパラメーターの自動検出をサポートします。
−
| Supports auto-detecting kernels and parameters without explicit configuration.
  
 
|-
  
|-
 
! [[Syslinux]]
  
! [[Syslinux]]
93行目: 93行目:
 
| {{Yes}} || {{Yes}}
  
| {{Yes}} || {{Yes}}
 
| {{Y|[[Syslinux#Chainloading|Partial]]}}
  
| {{Y|[[Syslinux#Chainloading|Partial]]}}
−
| {{Y|Without: multi-device volumes, compression, encryption}} || {{Y|Without encryption}} || {{No}} || {{Yes}} || {{Y|MBR only; without sparse inodes}}
 +
| {{Y|Without: multi-device volumes, compression, encryption}} || {{Y|暗号化なし}} || {{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.
 +
| 特定の [[ファイルシステム]] 機能はサポートされていません。[https://wiki.syslinux.org/wiki/index.php?title=Filesystem] <br/>ファイルシステムドライバーがありません [https://bugzilla.syslinux.org/show_bug.cgi?id=33] は、インストールされているファイルシステムにのみアクセスできます。
 
|-
  
|-
 
! [[systemd-boot]]
  
! [[systemd-boot]]
101行目: 101行目:
 
| {{Yes}}<sup>2</sup>
  
| {{Yes}}<sup>2</sup>
 
| {{No}} || {{No}} || {{No}} || {{G|Inherited from firmware<sup>1</sup>}} || {{No}}
  
| {{No}} || {{No}} || {{No}} || {{G|Inherited from firmware<sup>1</sup>}} || {{No}}
  +
| [[ESP]] または拡張ブートローダーパーティション(XBOOTLDRパーティション)以外のパーティションからバイナリを起動することはできません。
−
| Cannot launch binaries from partitions other than the [[ESP]] or the Extended Boot Loader Partition (XBOOTLDR partition).
  
 
|-
  
|-
 
! {{Grey|[[GRUB Legacy]]}}
  
! {{Grey|[[GRUB Legacy]]}}
108行目: 108行目:
 
| {{Yes}}
  
| {{Yes}}
 
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Y|XFS v4 only}}
  
| {{No}} || {{No}} || {{Yes}} || {{Yes}} || {{Y|XFS v4 only}}
−
| [https://www.gnu.org/software/grub/grub-legacy.html Discontinued] in favor of [[GRUB]].
 +
| [https://www.gnu.org/software/grub/grub-legacy.html廃止] [[GRUB]] を支持
 
|-
  
|-
 
! {{Grey|[[LILO]]}}
  
! {{Grey|[[LILO]]}}
114行目: 114行目:
 
| {{Yes}} || {{No}}
  
| {{Yes}} || {{No}}
 
| {{Yes}}
  
| {{Yes}}
−
| {{No}} || {{Y|Without encryption}} || {{Yes}} || {{Yes}} || {{Yes|http://xfs.org/index.php/XFS_FAQ#Q:_Does_LILO_work_with_XFS.3F}}
 +
| {{No}} || {{Y|暗号化なし}} || {{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).
 +
| [https://web.archive.org/web/20180323163248/http://lilo.alioth.debian.org/ 廃止] 制限による (Btrfs、GPT、RAIDなど)
 
|}
  
|}
   

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

関連記事

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 – カーネルはEFI実行可能ファイルに変換され、UEFI ファームウェアまたは別のブートローダーから直接ロードされます。
Clover Emulates UEFI Yes Yes Yes Yes2 No 暗号化なし 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 tail-packing feature Inherited from firmware1 No 明示的な構成なしでカーネルとパラメーターの自動検出をサポートします。
Syslinux Yes Partial Yes Yes Partial Without: multi-device volumes, compression, 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 暗号化なし 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

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=17595」から取得