How to pass arguments to a Linux kernel `init=` bootparam?

Question

Update:

I have succeeded in creating a very simple demo of using the init= bootparam to specify that a custom binary (written in golang and compiled) should be used in place of the standard init. The binary in that project is compiled for the ARM processor of the Raspberry Pi, but the source should compile for any platform.

---

Original Post:

I've successfully put init=/bin/bash in my bootparams and gotten a root shell on boot. Now I'd like to use bootparams to run a "first boot" setup script.

NOTE:

I know there are lots of alternatives that can be offered. Leave those as comments on the question if you'd like. But, I cannot use them; this question is not about them; they are not answers to this question. So, please don't post alternatives as answers.* It's not helpful to people who came here for this question.

Things I've tried that failed:

• init="/bin/bash -c 'mount /dev/mmcblk0p1 /boot; date > /boot/test.txt'"
• init='/bin/bash -c "mount /dev/mmcblk0p1 /boot; date > /boot/test.txt"'
• init="/bin/bash"
• init='/bin/bash'

So I'm going to assume that even quoting your init= param is not an option.

1. Correct me if I am wrong here.

I have read The Linux Kernel documentation on the matter. It 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.

...

init=    [KNL]
         Format: <full_path>
         Run specified binary instead of /sbin/init as init
         process.

Lesson learned:

That Format: <full_path> would explain why it doesn't like me putting a full command (or multiple) in the init=

I have also read BOOTPARAM(7) (search for "passed to the init process") where they say:

Anything of the form 'foo=bar' that is not accepted as a setup function as described above is then interpreted as an environment variable to be set. A (useless?) example would be to use 'TERM=vt100' as a boot argument.

Any remaining arguments that were not picked up by the kernel and were not interpreted as environment variables are then passed onto PID 1, which is usually the init(1) program. The most common argument that is passed to the init process is the word 'single' which instructs it to boot the computer in single user mode, and not launch all the usual daemons. Check the manual page for the version of init(1) installed on your system to see what arguments it accepts.

2. Are there any working examples of using this info to pass arguments to a custom specified init=?

If there is, it's hard to find and this question will serve to make it show up in Google results. If there is not, we'll create a working example for the community.

Solution 1

Yes, this is how you traditionally tell a regular init system what state to boot into. If you're running sysv-init (or pretty much any widely used init system other than systemd), you can put a number between 1 and 5 at the end of the kernel arguments and it will boot into that run level (1 is always single-user mode, the others are system defined, 3 or 4 is what most Linux distros have conventionally used as the default). If you're using systemd, you can pass single or emergency at the end of the kernel arguments to boot into those modes respectively.

Using this mechanism for passing arbitrary arguments however is somewhat difficult because the kernel does the absolute minimum of parsing, which means in particular that:

• Arguments with whitespace in them can't be passed at all, because the kernel doesn't parse quoted strings (that is, 'some string' gets parsed as two arguments 'some and string').
• You can't reference any environment variables at all, because the kernel doesn't do variable substitution (which is normally done by the shell you're running the command from before it even starts the command).
• In general, the arguments have to be correctly interpretable under the POSIX C locale (essentially US ASCII), which throws internationalization out the window unless you want to use something like base64 or punycode.
• There is an upper limit on how much data can be passed in kernel arguments, but I forget what it is.

These limitations combined are why you can't find anything on Google about doing this type of thing, no systems integration engineer in their right mind does it, because it's far more effort to work around the above limitations than it is to just write a script containing all the required arguments and call that instead.

Solution 2

Use -- to separate kernel parameters from arguments to init.

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.

Comments

[Admin]

bash -c '$@' bash /bin/echo -arg1 -arg2 works in the shell. So maybe init=/bin/bash -- -c $@ bash /path/to/executable -arg1 -arg2.

[Admin]

however remember that the kernel would panic once executable has finished.

[Admin]

2) whether or not you specify a custom init= is not quite relevant. For an example of an init system which accepts various arguments passed using this mechanism, see the original sysvinit. git.savannah.nongnu.org/cgit/sysvinit.git/tree/src/… It accepted arguments like "single". I am fairly confident the -s option the source code mentions would have been equally striaghtforward to pass on the kernel command line.

[Admin]

IMO this is very difficult to answer while respecting your wishes. I think the "correct" solution would be to put your firstboot code in a script file, ending with exec /sbin/init, and simply pass that script as the init. It sounds like you don't want that for some reason though.

[Admin]

Your wishes and your opinion that "alternatives are not answers to this question" are contrary to the goals of this site. Sometimes the best, or even the only, answer to a question is "don't do that" or "there is no way that can be made to work", both followed by a "here's why" explanation and a "do this instead".

[Admin]

@cas in fairness, if the alternative is to tell systemd to look for its target file on /boot where I am able to modify files, then that would be acceptable. What I'm trying to avoid is where people say things like "don't touch your kernel parameters".

[Admin]

The problem is, when you specify init=/bin/bash -c <some command>, the system will execute that command as process #1, and once the command is complete, process #1 dies - which results in a kernel panic, as process #1 is not supposed to just die.

[JdeBP]

You can use the numbers with systemd too. It is just that run levels are "obsolete" and not a systemd mechanism. The numbers are just mapped onto the native mechanisms. unix.stackexchange.com/a/394238/5132 Single-user mode was superseded in van Smoorenburg init by the emergency/rescue split nearly a quarter of a century ago, in 1995. unix.stackexchange.com/a/392612/5132

[mbaljeetsingh]

I have written a script. I just can't call it because it is on a filesystem that is not mounted. So, I need to some minimal preparation before I can run the script.

[mbaljeetsingh]

But, even as I test I have created a file /test.sh (that's on the filesystem that does get mounted) containing only 2 lines: #!/bin/bash and /bin/date > /test.txt and I still get nothing.

[telcoM]

If you try init=/test.sh, then when your /test.sh is executed, the real root filesystem has either not been mounted yet, or if you aren't using initramfs (or initrd), it is most likely mounted read-only. So your /test.txt either does not get written (because read-only file system) or gets written to a non-persistent RAM image of initramfs, which will be removed from memory as the system switches over to the real root filesystem.

[mbaljeetsingh]

@telcoM shouldn't output to stdout show up before the kernel panic? I haven't been able to get any echo output either.

[user2948306]

@BrunoBronosky you don't want a kernel panic, so why not design your test to avoid it? It's trivial: start with a script #!/bin/sh and ending exec /bin/sh (or maybe even /bin/sh ?). If that panics, I think there's something very wrong, maybe you forgot to chmod a+rx /test.sh. And look at the panic message if your text console is big enough: there's a specific message for not being able to exec init initially: "Failed to execute /init Kernel panic - not syncing. No init found". As opposed to the panic if init dies after being started

[user2948306]

@BrunoBronosky if init dies after being started, the message is just "Kernel panic - not syncing: Attempted to kill init!"... hmm. Except my search points out you'll also see that message if you're using an initrd, since then it's the initrd that execs init=. If the initrd fails to do so, the initrd PID1 will most likely die and show an error message before the resulting kernel panic, like "run-init: /sbin/init: No such file or directory".

[mbaljeetsingh]

I ultimately decided to write a binary using golang and have updated the question to reference it. I think the problem I had was that I had to choose to either mount my /boot partition which I can write to while the machine is off (but does not contain a shell binary) or mount my / partition which has bash, but I cannot write to while the machine is off. It was easier to write a binary rather than make it work with script and interpreter on separate partitions. Thanks for all the help here.

[eMPee584]

Ah cool, this (available since v3.15 "Shuffling Zombie Juror" in 2014) works surprisingly well.. allows crazy stuff like testing different read-ahead values without rebuilding our schulstick.org image.. init=/bin/sh -- -c "echo 'Setting read_head_kb for ?da to 2048'; for RA in /sys/block/?da/queue/read_ahead_kb; do echo \$RA; cat \$RA; echo 2048 > \$RA; cat \$RA; done; lsmod|sort; exec /sbin/init (ampersand in $variables have to be escaped to not have them eaten by grub's parsing)