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
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
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
/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.