Mdthbs

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?

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 init and root parameters aren’t used by the kernel directly; as far as the kernel is concerned, they are fall-backs in case the initramfs doesn’t work (but they are still kernel parameters). The initramfs itself is the root file system (at least for booting), and the kernel looks for an init executable in the root directory of the initramfs and runs that. If anything fails (the initramfs isn’t usable, or doesn’t contain /init, or the latter isn’t executable), the kernel will try to mount the device specified by its root parameter, and run /sbin/init or the executable specified by the init parameter.

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.

This famous bit of kernel code below is easy to understand --- it's just comments, panics and filenames!

execute_command contains the init= option: if you give a name there, but running it fails, you get a "Requested init xyz failed" error/panic.

Without a init= option, the kernel tries these four commands, from /sbin/init to /bin/sh. If these standard files are all missing, you get a "No working init found" panic.

And notice:

Try passing init= option to kernel

This is from Mr. Linux himself, unchanged for about 30 years. Initrd came later, in two steps...

So then, why does Linux "allow" init=/bin/bash? As you can see below, the kernel is one line away from panicking. It might be hard to see why, but rather than take care of zero processes and show a blinking cursor, the kernel decides to panic.

    /*

     * We try each of these until one succeeds.

     *

     * The Bourne shell can be used instead of init if we are

     * trying to recover a really broken machine.

     */

    if (execute_command) {

        ret = run_init_process(execute_command);

        if (!ret)

            return 0;

        panic("Requested init %s failed (error %d).",

              execute_command, ret);

    }

    if (!try_to_run_init_process("/sbin/init") ||

        !try_to_run_init_process("/etc/init") ||

        !try_to_run_init_process("/bin/init") ||

        !try_to_run_init_process("/bin/sh"))

        return 0;



    panic("No working init found.  Try passing init= option to kernel. "

          "See Linux Documentation/admin-guide/init.rst for guidance.");

}

In a initrd you need this switch_root/pivot_root/chroot trick to change root and pass PID1 to the real init: default sbin/init, something else or whatever init= wishes.

 switch_root [newrootdir] [init] [args to init]

In any case, initrd makes a complex procedure even more complex...