Linuxの起動プロセス

Linux のブートプロセスには複数の段階があり、その派生元であるBSDやその他のUnixスタイルのブートプロセスと多くの点で似ています。Linux のブートプロセスはコンピュータアーキテクチャに大きく依存しますが、それらのアーキテクチャは同様の段階とソフトウェアコンポーネントを共有しています。 ^[1]これには、システムの起動、ブートローダの実行、 Linux カーネルイメージのロードと起動、さまざまな起動スクリプトとデーモンの実行が含まれます。^[2]これらは、システムの起動、ブートローダ段階、カーネル段階、および init プロセスの 4 つのステップに分類されます。^[3] Linux システムが電源投入またはリセットされると、そのプロセッサは、パワーオンセルフテストなどのシステム初期化用の特定のファームウェア/プログラムを実行し、リセットベクターを呼び出してフラッシュ/ROM (組み込み Linux デバイスの場合) 内の既知のアドレスにあるプログラムを起動し、その後、ブートローダを RAM にロードして後で実行します。^[2] IBM PC 互換 パーソナルコンピュータ(PC)では、このファームウェア/プログラムはBIOSまたはUEFIモニターのいずれかであり、マザーボードに格納されています。^[2]組み込みLinuxシステムでは、このファームウェア/プログラムはブートROMと呼ばれます。^{[4] [5]} RAMにロードされた後、ブートローダ（第1段階ブートローダまたはプライマリブートローダとも呼ばれる）が実行され、第2段階ブートローダ^[2]（セカンダリブートローダとも呼ばれる）がロードされます。^[6]第2段階ブートローダはカーネルイメージをメモリにロードし、解凍して初期化し、このカーネルイメージに制御を渡します。^[2]第2段階ブートローダは、システムハードウェアのチェック、ルートデバイスのマウント、必要なカーネルモジュールのロードなど、システム上でいくつかの操作も実行します。 ^[2]最後に、最初のユーザー空間プロセス（initプロセス）が開始され、その他の高レベルのシステム初期化が実行されます（起動スクリプトが含まれます）。^[2]

これらのステージとコンポーネントごとに、さまざまなバリエーションとアプローチがあります。たとえば、GRUB、coreboot、またはDas U-Boot をブートローダとして使用できます (歴史的な例としてはLILO、SYSLINUX、Loadlinがあります)。一方、起動スクリプトは従来のinitスタイルにすることも、 systemdやUpstartなどの最新の代替手段を使用してシステム構成を実行することもできます。

システムの起動は、Linuxが起動されているハードウェアに応じて異なる手順で行われます。^[7]

IBM PC 互換ハードウェアは、Linux が一般的に使用されるアーキテクチャの 1 つです。これらのシステムでは、BIOSまたはUEFIファームウェアが重要な役割を果たします。

BIOSシステムでは、BIOSはそれぞれ電源投入時セルフテスト（POST）を実行します。これは、システムハードウェアをチェックし、次にローカルデバイスを列挙し、最後にシステムを初期化します。^[7]システムの初期化では、BIOSはOSを保存しているシステム上の起動可能なデバイスを検索することから始めます。起動可能なデバイスには、フロッピーディスク、CD-ROM、USBフラッシュドライブ、ハードディスク上のパーティション（ハードディスクにWindowsとFedoraなどの複数のOSを保存している場合）、ローカルネットワーク上のストレージデバイスなどがあります。 ^[7] Linuxを起動するハードディスクには、マスターブートレコード（MBR）が保存されます。これには、RAMにロードするための第1段階/プライマリブートローダが含まれています。^[7]

UEFIシステムでは、LinuxカーネルはEFIブートスタブを介してUEFIファームウェアによって直接実行できますが^[8]、通常はGRUB 2またはsystemd-bootをブートローダとして使用します。^{[9] [10]}

組み込みLinuxシステムのシステム起動段階は、オンチップブートROM上のファームウェア/プログラムを実行することから始まります。次に、eMMC、eUFS、NANDフラッシュなどのストレージデバイスからブートローダ/オペレーティングシステムがロードされます。 ^[5]システム起動のシーケンスはプロセッサによって異なりますが^[5]、すべてハードウェアの初期化とシステムハードウェアのテスト手順が含まれます。^[7]たとえば、i.MX7DプロセッサとOS（U-Bootを含む）を格納するブート可能なデバイスを備えたシステムでは、オンチップブートROMが最初にDDRメモリコントローラをセットアップし、これによりブートROMのプログラムがブート可能なデバイス上の外部ブートローダからSoC構成データを取得できるようになります。^[5]次に、オンチップブートROMは、ブートローダ段階のためにU-BootをDRAMにロードします。^[11]

MBR の一部である第 1 ステージ ブートローダは、ベンダー固有のプログラム コードとパーティション テーブルを含む 512 バイトのイメージです。^[6]導入部分で前述したように、第 1 ステージ ブートローダは第 2 ステージ ブートローダを見つけてロードします。^[6]これは、パーティション テーブルでアクティブなパーティションを検索することによって行われます。^[6]アクティブなパーティションが見つかった後、第 1 ステージ ブートローダはテーブル内の残りのパーティションをスキャンし続け、すべてが非アクティブであることを確認します。^[6]このステップの後、アクティブなパーティションのブート レコードが RAM に読み込まれ、第 2 ステージ ブートローダとして実行されます。^[6]第 2 ステージ ブートローダの仕事は、Linux カーネル イメージをメモリとオプションの初期 RAM ディスクにロードすることです。^[12]カーネル イメージは実行可能なカーネルではなく、カーネルの「圧縮ファイル」であり、zlibを使用してzImage または bzImage形式に圧縮されています。^[13]

x86 PCでは、第1ステージと第2ステージのブートローダがGRand Unified Bootloader (GRUB)、以前はLinux Loader ( LILO )に統合されています。^{[12]現在使用されている} GRUB 2は、さまざまなオペレーティングシステムの自動検出と自動構成が可能な点でGRUB 1と異なります。stage1は、BIOSによってマスターブートレコード(MBR)からロードされ、実行されます。中間ステージローダ(stage1.5、通常はcore.img)は、stage1ローダによってロードされ、実行されます。第2ステージローダ(stage2、/boot/grub/ファイル)は、stage1.5によってロードされ、ユーザーがオペレーティングシステムを選択したり、起動パラメータを調べて編集したりできるGRUB起動メニューを表示します。メニューエントリが選択され、オプションのパラメータが指定されると、GRUBはLinuxカーネルをメモリにロードし、制御を渡します。GRUB 2は、別のブートローダをチェーンロードすることもできます。UEFIシステムでは、stage1 と stage1.5 は通常、同じ UEFI アプリケーション ファイルです ( x64 UEFI システムの場合は grubx64.efi など)。

GRUB 以外にも、人気のあるブートローダーがいくつかあります。

• systemd-boot (旧称 Gummiboot) は、最小限の設定を必要とするsystemdに含まれるブートローダーです( UEFIシステムのみ)。
• SYSLINUX/ISOLINUX は、FAT ファイルシステムから完全な Linux インストールを起動することに特化したブートローダーです。ブートまたはレスキュー フロッピー ディスク、ライブ USB、その他の軽量ブート システムによく使用されます。ISOLINUX は、通常、Linuxライブ CDおよびブート可能なインストール CD で使用されます。
• rEFInd、UEFIシステム用のブート マネージャー。
• coreboot はUEFIまたはBIOSの無料実装であり、通常はシステム ボードとともに導入され、必要に応じてベンダーによってフィールド アップグレードが提供されます。coreboot の一部はシステム BIOS となり、起動後もメモリ内に常駐します。
• Das U-Boot は組み込みシステム用のブートローダです。BIOS/UEFI を持たず、カスタム メソッドを使用してブートローダをメモリに読み込んで実行するシステムで使用されます。

現在では一般的に使用されていない歴史的なブートローダには、次のものがあります。

• LILO は、ファイルシステムのレイアウトを理解したり解析したりしません。代わりに、/etc/lilo.confカーネルと RAM ディスク (initrd または initramfs) の場所に関する生のオフセット情報 (マッパー ツール) をマップする構成ファイル () がライブ システム内に作成されます。構成ファイルには、それぞれのブートパーティションやカーネルパス名などのデータ、および必要に応じてカスタマイズされたオプションが含まれており、ブートローダ コードとともに MBR ブートセクターに書き込まれます。このブートセクターが読み込まれ、BIOS によって制御されると、LILO はメニュー コードをロードして描画し、保存された値とユーザー入力を使用して Linux カーネルを計算してロードするか、他のブートローダをチェーン ロードします。
• GRUB 1には、実行時に共通ファイルシステムを読み取り、設定ファイルにアクセスするロジックが含まれています。^[14]これにより、GRUB 1は設定ファイルをMBRに埋め込むのではなく、ファイルシステムから読み取ることができるようになりました。これにより、実行時に設定を変更したり、オフセットに頼らずに人間が読める形式でディスクやパーティションを指定したりできるようになりました。また、コマンドラインインターフェイスも含まれているため、GRUBの設定が間違っていたり破損していたり​​した場合に、修正や変更が容易になります。^[15]
• Loadlinは、実行時に実行中のDOSまたはWindows 9xカーネルを Linux カーネルに置き換えることができるブートローダです。これは、ソフトウェアを介してスイッチを入れる必要があり、そのような構成プログラムが独自のものであり、DOS でしか使用できないハードウェアの場合に役立ちます。Linux には多数のハードウェア デバイス用のドライバーがあるため、このブート方法は現在ではあまり必要ありませんが、モバイル デバイスでは使用されています。別の使用例としては、Linux が BIOS でブートに使用できないストレージ デバイスにある場合です。DOS または Windows は、BIOS の制限を補うために適切なドライバーをロードし、そこから Linux をブートできます。

カーネルステージはブートローダステージの後に行われます。Linuxカーネルは、メモリ管理、タスクスケジューリング、I/O、プロセス間通信、システム全体の制御など、すべてのオペレーティングシステムプロセスを処理します。これは2段階でロードされます。最初の段階では、カーネル（圧縮されたイメージファイルとして）がメモリにロードされて解凍され、基本的なメモリ管理、最小限のハードウェアセットアップなどのいくつかの基本的な機能が設定されます。^[13]カーネルイメージは自己解凍されることに注意してください。これはカーネルイメージのルーチンの一部です。^[13]一部のプラットフォーム（ARM 64ビットなど）では、カーネルの解凍はU-Bootなどのブートローダによって実行する必要があります。^[16]

これらの手順の詳細については、 i386マイクロプロセッサの例を参照してください。その bzImage が呼び出されると、関数start()(の./arch/i386/boot/head.S) が呼び出され、基本的なハードウェア セットアップが行われ、次に (startup_32()にある./arch/i386/boot/compressed/head.S)が呼び出されます。 ^{[13] は} startup_32()環境 (スタックなど) の基本的なセットアップを行い、Block Started by Symbol (BSS) をクリアしてから、 decompress_kernel()(にある./arch/i386/boot/compressed/misc.c) を呼び出してカーネルを解凍します。^[13startup_32() ] 次に、にある別の関数によってカーネルの起動が実行されます./arch/i386/kernel/head.S。^[13]カーネルの起動関数startup_32()(スワッパーまたはプロセス 0 とも呼ばれます) は、メモリ管理(ページング テーブルとメモリ ページング) を確立し、 CPUの種類と浮動小数点機能などの追加機能を検出し、start_kernel()にあるの呼び出しによってアーキテクチャ固有ではない Linux カーネル機能に切り替えます./init/main.c。^[13]

start_kernel()広範囲にわたる初期化機能を実行します。割り込み処理( IRQ ) を設定し、メモリをさらに構成し、ブートローダ段階で一時ルートファイルシステムとして以前にロードされた初期 RAM ディスク("initrd") をマウントします。 ^[13] RAM 内の一時ルートファイルシステムとして機能する initrd により、カーネルを完全にブートし、他のデバイス (ハードディスクなど) に依存せずにドライバモジュールをメモリから直接ロードできます。^[13] initrd には、SATA ドライバなどの周辺機器とのインターフェイスに必要なモジュールが含まれており、 ^[13]多数のハードウェア構成をサポートしています。 [13]カーネルに静的にコンパイルされた一部のドライバと initrd からロードされる他のドライバを分割することで、カーネルを小さくすることができます。^{[13] initramfs}は初期ユーザー空間とも呼ばれ、Linux カーネルのバージョン 2.5.46 以降で使用可能になりました。^[17]以前はカーネルが起動プロセス中に実行していた機能をできるだけ多く置き換えることを目的としています。初期ユーザー空間の一般的な用途は、メインのユーザー空間ファイルシステムをロードするために必要なデバイスドライバーを検出し、それらを一時ファイルシステムからロードすることです。多くのディストリビューションは、 dracut を使用してinitramfs イメージを生成および維持します。

ルートファイルシステムは、pivot_root()一時的なルートファイルシステムをアンマウントし、実際のファイルシステムがアクセス可能になったら、実際のファイルシステムに置き換える呼び出しによって後で切り替えられます。^[13]一時的なルートファイルシステムによって使用されたメモリは、その後再利用されます。^{[説明が必要]}

最後に、kernel_thread(in arch/i386/kernel/process.c) が呼び出され、Initプロセス（最初のユーザー空間プロセス）が開始され、その後 を介してアイドルタスクが開始されますcpu_idle()。^[13]

したがって、カーネルステージではデバイスを初期化し、ブートローダによって指定されたルートファイルシステムを読み取り専用としてマウントし、システムによって実行される最初のプロセス（PID = 1）として指定されているInit（ ）を実行します。^[18]ファイルシステムをマウントするとカーネルによってメッセージが印刷され、Initプロセスを開始するとInitによってメッセージが印刷されます。^[18]/sbin/init

Red Hatによれば、この段階での詳細なカーネルプロセスは次のように要約される。^[14]

「カーネルがロードされると、直ちにコンピュータのメモリを初期化して構成し、すべてのプロセッサ、I/O サブシステム、ストレージ デバイスなど、システムに接続されたさまざまなハードウェアを構成します。次に、メモリ内の所定の場所で圧縮された initrd イメージを検索し、解凍してマウントし、必要なすべてのドライバーをロードします。次に、LVMやソフトウェアRAIDなどのファイル システムに関連する仮想デバイスを初期化してから、initrdディスク イメージをアンマウントし、ディスク イメージが占有していたすべてのメモリを解放します。次に、カーネルはルート デバイスを作成し、^{[説明が必要]}ルート パーティションを読み取り専用でマウントし、未使用のメモリを解放します。この時点で、カーネルはメモリにロードされ、操作可能になります。ただし、システムへの意味のある入力を可能にするユーザー アプリケーションがないため、カーネルでできることはあまりありません。」 initramfs スタイルのブートは、説明した initrd ブートと似ていますが、同じではありません。

この時点で、割り込みが有効になっているため、スケジューラはシステム全体の管理を制御してプリエンプティブなマルチタスクを提供でき、init プロセスはユーザー空間でユーザー環境のブートを続行します。

カーネルが起動すると、initプロセス^{[19]が開始されます。initプロセスは、}ファイルシステムのチェックやマウント、他のプロセスの起動など、ユーザー空間のブートストラップを行うデーモンです。initシステムは、起動時に最初に起動するデーモンであり、シャットダウン時に最後に終了するデーモンです。

歴史的には、これは「SysV init」であり、単に「init」と呼ばれていました。最近の Linux ディストリビューションでは、systemdなどのより現代的な代替手段の 1 つが使用される可能性があります。以下は、主要な init プロセスの概要です。

• SysV init (別名単に「init」) は、派生元のUnixおよびBSD init プロセスに似ています。標準的な Linux システムでは、init は、0 から 6 までの値を取り、どのサブシステムを動作可能にするかを決定する、ランレベルと呼ばれるパラメータを使用して実行されます。各ランレベルには、特定のランレベルの設定または終了に関連するさまざまなプロセスをコード化した独自のスクリプトがあり、これらのスクリプトがブート プロセスで必要に応じて参照されます。init スクリプトは通常、などの名前のディレクトリに保存されます"/etc/rc..."。init の最上位構成ファイルは にあります/etc/inittab。^{[20]システム ブート中に、/etc/inittab でデフォルトのランレベルが指定されているかどうかを確認し、指定されていない場合は}システム コンソールを介してランレベルに入るように要求します。次に、モジュールのロード、ルート ファイル システム (読み取り専用でマウントされていた) の整合性のチェック、完全な読み取り/書き込みアクセスのための再マウント、ネットワークの設定など、特定のランレベルの関連するすべてのブート スクリプトを実行します。^[18]指定されたプロセスをすべて生成した後、initは休止状態になり、開始したプロセスが終了または死ぬ、電源障害信号、^{[説明が必要]}、またはランレベルをさらに変更するための要求のいずれかが発生するのを待ちます/sbin/telinit。^[21]

• systemdはSysV initの現代的な代替手段です。initと同様に、systemdは他のデーモンを管理するデーモンです。systemdを含むすべてのデーモンはバックグラウンドプロセスです。systemdを最初に開発したソフトウェアエンジニアであるLennart PoetteringとKay Sievers ^[22]は、いくつかの方法でinitデーモンの効率を超えようとしました。彼らは、依存関係を表現するためのソフトウェアフレームワークを改善し、システムの起動中により多くの処理を並行して実行できるようにし、シェルの計算オーバーヘッドを削減したいと考えました。各デーモンのsystemdの初期化命令は、シェルスクリプトではなく宣言型の構成ファイルに記録されます。プロセス間通信のために、systemdは実行中のデーモンがUnixドメインソケットとD-Busを利用できるようにします。systemdは積極的な並列化も可能です。

• SYSLINUX
• Windowsの起動プロセス

• M. Tim Jones (2006 年 5 月 31 日)。「Linux ブート プロセスの内部」。IBM。2007年10 月 11 日時点のオリジナルよりアーカイブ。2024年 1 月 14 日閲覧。
• アルベルト・リベラル・デ・ロス・リオス（2017）。組み込みプロセッサ用の Linux ドライバー開発 (第 2 版)。編集者サークロ・ロホ；初版（2017年3月3日発行）。ISBN 978-8491600190。

• Linux カーネルソースの読み方、Wikiversity
• Greg O'Keefe - Power Up から Bash Prompt まで ( Wayback Machineより) (2009 年 10 月 23 日アーカイブ)
• Bootchart: ブートプロセスのパフォーマンスの視覚化
• EFI システムのブートストラップ プロセス、LWN.net、2015 年 2 月 11 日、Matt Fleming 著