☰

systemdアップデートがinitramfsの構築をトリガーするのはなぜですか？

tag-icon • tag-icon linux systemd initramfs
systemdアップデートがinitramfsの構築をトリガーするのはなぜですか？

systemd-242.0-3今日のアップデートを受け取りました（いくつかの関連アップデートも含まれています）。パッケージをインストールした後、端末はinitramfsが最初からビルドされたことを示します。出力は次のとおりです。

:: Running post-transaction hooks...
(1/9) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
  -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 5.0.9-arch1-1-ARCH
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [filesystems]
  -> Running build hook: [keyboard]
  -> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful

~によるとリニアFS:

起動時に、ブートローダはカーネルとinitramfsイメージをメモリにロードし、カーネルを起動します。カーネルは initramfs が存在するかどうかを確認し、見つかった場合はそれを / にマウントして /init を実行します。 initプログラムは通常シェルスクリプトです。 initramfsを使用すると、起動プロセスに時間がかかることがあり、かなりかかることがあります。

gzipとcpioツールを使用して開き、フォルダ全体が/boot/initramfs-linux.img含ま/usr/lib/systemdれています。カーネルだけを含めてはいけませんか？ initramfsにもsystemdが存在するのはなぜですか？カーネルをRAMに入れてディスクからシステムをロードする方が速くないですか？

ベストアンサー1

即時の理由は、いくつかのパッケージ（私の考えではカーネルパッケージだと思い、systemdとは関係ありません）にインストールスクリプトがあるからです。 initramfsには、そのパッケージにフック/バイナリ/カーネルモジュールなどが含まれている可能性があるため、再構築する必要があります。それ以外の場合は、以前のバージョンを使用します（ほとんどのinitramfsにはフックする必要なカーネルモジュールが含まれていることに注意してください）。次回の起動時に、古いバージョンが新しいカーネルで実行できない実際のルート）。

initramfsにはカーネルは含まれていませんが（すべてのファイルを含めることはできますが意味はありません）、カーネルはすでにブートローダを介してRAMにロードされており、initramfsは最初のマウントされたファイルシステムとしてのみ使用されます。

一般的なシステムでは、initramfsの作業は、「実際のルートファイルシステム」（で使用される）をマウントする最初のPID = 1プロセスを実行するためにinitプログラム（他の依存ライブラリまたはスクリプトソルバーを含めることができます）を提供することです。です。コンピュータの「通常のルートファイルシステム）ハードディスクパーティション」を選択し、ピボットルートに移動して物理ルートファイルシステムでinitを実行します。

PID = 1で実行するように設計されたプログラムであるSystemdは、initramfsではinitで、実際のルートファイルシステムではinitで実行される機能を提供します。

おすすめ記事