Are all kernel argument really used by the kernel?

Question

Why does Linux allow ‘init=/bin/bash’?

I read this, answers are saying it's KERNEL running this init program.

Then I started to wonder, Linux usually comes with a initramfs, which will eventually mount and pivot_root to real root filesystem. So what does this init argument mean? The path in the initramfs? Or like I guessed, it's not read by the kernel but by init of initramfs to exec the real init.

Also, the root=UUID=xxxx argument, is that really read by kernel or just by init of initramfs to find the real root filesystem?

It seems like I can pass any argument I want as kernel arguments, so are they all read by the kernel or at least some of them are only meaningful to userspace programs?

Answer 1

Parameters passed on the kernel command line don’t have to be meaningful for the kernel: the kernel parameters documentation says

The kernel parses parameters from the kernel command line up to “--”; if it doesn’t recognize a parameter and it doesn’t contain a ‘.’, the parameter gets passed to init: parameters with ‘=’ go into init’s environment, others are passed as command line arguments to init. Everything after “--” is passed as an argument to init.

This doesn’t apply to init and root which really are kernel parameters, and are handled by the kernel. They can also be acted upon by user-space, since they appear in /proc/cmdline. (Thus for example systemd takes the quiet kernel parameter into account to reduce its output.)

When the kernel is booted with an initramfs, the root parameter isn’t used by the kernel directly, and the init parameter is only used if rdinit fails. init startup is handled in kernel_init, which works as follows:

• if there’s a “ramdisk execute command” (either the value given to rdinit on the kernel command line, or /init) which is accessible, the kernel attempts to run that;
• if that fails, and there’s an “execute command” (the value given to init on the kernel command line), the kernel attempts to run that, and panics if it can’t;
• as a last resort, the kernel tries to run /sbin/init, /etc/init, /bin/init, and /bin/sh; if none of those can be run, it panics.

When there’s an initramfs, all of this happens there, and the target volume isn’t mounted by the kernel. What happens after the kernel runs the first init program (typically, the /init script in the initramfs) is up to the program, not the kernel. Arguments which aren’t passed to init are still available in /proc/cmdline if the /proc file system is mounted.

Answer 2

Passing custom kernel arguments is one way to customize a system during a KickStart install, for example a PXE server could set:

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

where lab is then used in the KickStart configuration to do different things than for other system builds:

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

Here to setup a different filesystem layout than used on other system types. Hopefully different labels are used for local customizations than are used by the kernel, given the single namespace involved.