How the Linux kernel command line is processed (more or less)
June 22, 2012
Because I just had to research this (right down to reading kernel source), here is how the Linux kernel handles its command line arguments.
(The kernel command line is set in the bootloader in various ways. Grub lets you edit it on the fly, assuming that you can interrupt grub in time before it autoboots your kernel.)
First, the kernel goes through all kernel options and handles them. In theory all of the kernel options are documented in Documentation/kernel-parameters.txt in the kernel source, but beware: on a modern system that boots using an initial ramfs, a number of these options are really handled by the initial boot process instead of the kernel.
For anything that is not a kernel option and does not have a '.' in
its name (these are assumed to be unhandled module parameters), one
of two things happen. If it is of the form 'a=b' or (I believe) 'a=',
it's placed in the environment that will be passed to the initial
user-level process (generally either
Generally the initial user-level process then immediately reads and
(I say 'pseudo-parses' because
Some but not all distributions make use of the initial environment
variables; for example, Fedora sets
Sidebar: what some distributions do with init command line arguments
All of these are for when you have an initial ramfs with its own
These days initial ramdisk images are gzip'd CPIO archives, so they can be extracted with:
mkdir /tmp/unpack cd /tmp/unpack zcat /boot/init<whatever>.img | cpio -id
* * *
Atom feeds are available; see the bottom of most pages.