Bugzilla – Bug 104984
/sbin/init takes no command line parameters
Last modified: 2005-09-07 11:05:55 UTC
This line in mkinitrd: |exec /bin/run-init -c ./dev/console /root $init "$@" passes the $kernel_cmdline parameters to the init process. IMO this is wrong; the init process does not take parameters. This doesn't matter for the "real" init, but an option like "init=/bin/sh" causes the shell to try executing a script which then fails, for example.
Well, not quite. init does take a parameter (the selected runlevel). But for others it seems you are correct.
Created attachment 46229 [details] mkinitrd Fixed /sbin/mkinitrd
This is the version I've checked in into CVS. Please test with it; if I don't hear anything by the end of the week I'll submit it to autobuild.
wait a second: will this break the possibility to set variable names on the boot-prompt that affect hooks in the boot-process ?
No, all parameters are all still available in /proc/cmdline. This was only about how the init process itself is invoked.
I'm almost sure this breaks init=/bin/bash --login
Ad comment #4: Yes. Ad comment #6: Probably. Andreas, I'm beginning to wonder whether we should revert that change.
then indeed everything comes down to the bug in gfxboot to not allow parameters anymore - which forces you into the text grub, that doesn't remove the showopts we have in our default menu.lst. Because init=/bin/bash showopts _is_ a problem.
So, we fixed mkinitrd to only pass the runlevel to run_init. Everything else is pointless anyway. And no, init=/bin/bash --login is not broken.