今天我得到了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 程序通常是一个 shell 脚本。请注意,如果使用 initramfs,启动过程将花费更长的时间,甚至可能会显着延长。
我使用 gzip 和 cpio 工具打开它/boot/initramfs-linux.img
,它包含整个/usr/lib/systemd
文件夹。它不应该只包含内核吗?为什么 systemd 也存在于 initramfs 中?将内核放在 RAM 中并从磁盘加载 systemd 不是更快吗?
答案1
直接原因是确实有一些包(我相信它是内核包,与systemd无关)有一个安装脚本。这是合理的,因为您的 initramfs 可能包含一些钩子/二进制/内核模块/该包中的任何内容,因此需要重建它,否则您将使用旧版本(请注意,大多数 initramfs 包含 nessceary 内核模块来挂载真正的根,其中旧版本无法在下次启动时与新内核一起运行)。
initramfs不包含(虽然它可以包含任何文件,但没有意义)内核,内核已经通过bootloader加载到RAM中,initramfs仅用作第一个挂载的文件系统。
在典型的系统上,initramfs 的工作是提供 init 程序(可能包括其他依赖库或脚本解释器)来运行第一个 PID=1 进程,该进程挂载“真实根文件系统”(您在计算机上使用的普通根文件系统)硬盘分区)”然后pivot_root到它,在真正的根文件系统上执行init。
Systemd 作为一个设计为 PID=1 运行的程序,提供了在 initramfs 中作为 init 运行的功能以及在真实根文件系统中作为 init 运行的功能。
答案2
内核被放入 RAM 中,并将单独的 initramfs 解压到其 rootfs (=ramfs) 中,这是内核的第一个文件系统。
Initramfs 可以用作迷你Linux 系统,例如用于嵌入式应用程序。
如果使用systemd-init,systemd文件将位于initramfs中。
HOOKS
mkinitcpio.conf
包含在钩子脚本,将文件放入 initramfs(内核模块、程序、启动脚本……),但不是钩子脚本他们自己。有systemd-init
钩子作为busybox
钩子的替代品。
pacman -Syu linux
更新最新的内核/boot
,但也会触发 initramfs 的重新创建。
pacman -Syu systemd
也可以触发 initramfs 的重新创建(最后一个链接),但它不会像内核安装一样自动完成。这是因为systemd-init
是 的替代方案busybox
。 Archlinuxbusybox
默认使用文件和相应的钩子。
链接: