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.

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.