lin q wrote:
I happen to find an interesting thing: if I add "init=/bin/bash" to the kernel boot parameter, then Fedora Core 1 quickly boots to command line bash, no GUI starts. And / is read only. And I works in single user environment.
Then I tried changing the parameter to "init=/bin/bash, rw", but this time the boot is like normal way, GUI starts, I am asked to log in, etc.
I wonder why it has so big difference with and without "rw"?
Whew. There's quite a lot to explain here.
In Unix-like systems, init is the first process to be run, and the ultimate ancestor of all processes ever run. It's responsible for running all the init scripts.
You're telling the Linux kernel to run /bin/bash as init, rather than the system init. This means *nothing* else is running: bash doesn't know it has to start anything. bash won't do a number of other init-type things either, so don't expect everything to work.
Now, the kernel expects spaces to separate options on its command line, not commas. This means that in your second example, the kernel thinks it has two parameters, "init=/bin/bash," (*including* the comma, excluding the quotes) and "rw".
I don't have a 2.4 kernel tree any more, and I'm not a "C" programmer, but in 2.6.11, the kernel source file init/main.c includes these lines: /* * 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) run_init_process(execute_command);
run_init_process("/sbin/init"); run_init_process("/etc/init"); run_init_process("/bin/init"); run_init_process("/bin/sh");
panic("No init found. Try passing init= option to kernel.");
So the kernel looks for "/bin/bash,", doesn't find it, and tries /sbin/init as normal. That works, and init (and Fedora) loads as usual.
Hope this helps,
James.
Hey, that's some good information. I never knew *exactly* where the kernel looks to start init scripts.
Thanks -dant
