所有内核参数真的都被内核使用了吗？

Question

为什么 Linux 允许“init=/bin/bash”？

我读过这篇文章，答案是说它是内核运行这个初始化程序。

然后我开始想，Linux通常带有一个initramfs，它最终会挂载并pivot_root到真正的根文件系统。那么这个init论点是什么意思呢？ initramfs 中的路径？或者就像我猜测的那样，它不是由内核读取的，而是由 initramfs 的 init 读取来执行真正的 init 的。

另外，root=UUID=xxxx争论是真的由内核读取还是仅由 initramfs 的 init 读取来查找真正的根文件系统？

似乎我可以传递任何我想要的参数作为内核参数，那么它们都是由内核读取的还是至少其中一些仅对用户空间程序有意义？

Answer 1

在内核命令行上传递的参数不必对内核有意义：内核参数文档说

内核从内核命令行解析参数到“--”；如果它无法识别参数并且不包含“.”，则该参数将传递给 init：带有“=”的参数进入 init 的环境，其他参数作为命令行参数传递给 init。 “--”之后的所有内容都作为参数传递给 init。

这不适用于init和rootwhich 实际上是内核参数，并且由内核处理。它们也可以由用户空间进行操作，因为它们出现在/proc/cmdline. （因此，例如 systemd 会quiet考虑内核参数来减少其输出。）

当内核使用 initramfs 启动时，该root参数不是用过的直接由内核调用，并且仅在失败init时才使用该参数。启动处理在rdinitinitkernel_init，其工作原理如下：

• rdinit如果存在可访问的“ramdisk 执行命令”（内核命令行上指定的值，或者/init），则内核会尝试运行该命令；
• 如果失败，并且有一个“执行命令”（内核命令行上给出的值init），内核会尝试运行它，如果不能运行，则会出现恐慌；
• 作为最后的手段，内核尝试运行/sbin/init、/etc/init、/bin/init和/bin/sh；如果这些都不能运行，恐慌。

当有 initramfs 时，所有这些都发生在那里，并且目标卷不会由内核安装。会发生什么后内核运行的第一个init程序（通常是/initinitramfs 中的脚本）由程序决定，而不是内核。如果安装了文件系统，则未传递给的参数init仍然可用。/proc/cmdline/proc

Answer 2

传递自定义内核参数是在 KickStart 安装期间自定义系统的一种方法，例如 PXE 服务器可以设置：

linuxefi /c7/vmlinuz ks=http://.../ks/c7 lab ksdevice=eth0 net.ifnames=0 biosdevname=0

然后，在 KickStart 配置中使用wherelab来执行与其他系统构建不同的操作：

%pre
...
case " $(cat /proc/cmdline)" in
   ...
   *\ lab*)
      filesystems_lab
      ;;
   *)
      filesystems_common
      ;;
...

此处设置与其他系统类型不同的文件系统布局。考虑到涉及的单个命名空间，希望本地自定义使用的标签与内核使用的标签不同。