Linux Command Line Parameters
Consider the following situations:
Scenario 1: You are installing Linux from CDROM, but the kernel isn't using the correct I/O address for your CD-ROM drive. You can correct this by recompiling the kernel, but to build the kernel you first need to install Linux from CD-ROM...
Scenario 2: You made a change to the system startup script rc.local and now your system hangs while booting. How can you fix the error without reinstalling Linux?
Scenario 3: You'd like to experiment with the various VGA console video modes available without having to recompile the kernel each time.
Scenario 4: You've just written a large application that runs well on your system. How well would it run on a friend's machine that has only 4MB of RAM and no floating point coprocessor?
One solution to each of these problems is provided by Linux and its ability to pass command line parameters to the kernel. Unfortunately, these options are not well documented, (some of the HOWTOs mention certain options in passing, e.g., the SCSI HOWTO mentions some SCSI related options) and a number of them have been added relatively recently. We'll explore them in this article.
In order to understand how command line parameters fit into the scheme of things, let's briefly look at what happens when Linux boots.
For those who aren't afraid to look at kernel source code, I'll mention some of the relevant files. The filenames given are relative to wherever you have installed the kernel source, usually /usr/src/linux. Therefore, a reference to the file boot/bootsect.S should be found in /usr/src/linux/boot/bootsect.S. This information is valid for Linux kernel version 1.2.
Starting from power on, the PC ROM BIOS routines load boot code from floppy or hard disk. If booting from hard disk, this is usually the boot loader installed by LILO. If booting fJ5m floppy, it is the code in the file boot/bootsect.S. This in turn loads the code found in boot/setup.S and runs it. This module reads some information from the BIOS (the VGA mode, amount of memory, etc.) and makes note of it for later use. It will be needed later as the BIOS routines will not (normally) be used once the kernel starts up.
The setup code next switches to protected (32-bit) mode, then loads and runs the code found in boot/head.S. (Actually, for compressed kernels, which is always the case in recent kernels, the kernel proper is first uncompressed using the code found in zBoot/head.S). This sets up more of the 32-bit environment, gets the command-line parameters (usually from LILO), and passes them to the routine start_kernel.
Up to now everything was written in assembly language. At this point we now switch to the function start_kernel, written in C, found in the file init/main.c. This is the code that does most of the option parsing, saving information on a number of kernel-specific parameters in global variables so that they can be used by the kernel when needed.
Any other parameters given as “name=value” pairs are passed as arguments and environment variables to the next process.
This first kernel process now sets some things up for multitasking, and makes the first call to the fork system call, creating a new process; we are now multitasking. The original (parent) process becomes the “idle process” which is executed whenever there are no processes ready to run. The child process (which has process id 1) calls the program init. (It actually looks in a number of places, including /etc/init, /bin/init, /sbin/init, /etc/rc, and finally /bin/sh.) The init program then starts up all of the initial system processes such as getty and other daemons, and shortly we have a login prompt on the console.
There are a number of important options that can be set when compiling the Linux kernel. These include the root device, swap device, and VGA video mode. The toplevel Makefile allows setting most of these.
The problem with this method is that recompiling the kernel is somewhat time-consuming (at least on my machine; do you have a 100MHz Pentium?). You must also modify the standard Makefile, and remember to continue to do so when upgrading to newer kernels.
The rdev command was written long ago to make it easier to set some of these important kernel options without a recompile. The program directly patches the appropriate variables in a kernel image. These are at fixed addresses (defined in boot/bootsect.S).
While using rdev is fast, it is still somewhat inconvenient in that you have to remember to run it after building each kernel. It is also limited in the options that can be changed. We can do better.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
|Android Candy: Intercoms||Apr 23, 2015|
|"No Reboot" Kernel Patching - And Why You Should Care||Apr 22, 2015|
|Return of the Mac||Apr 20, 2015|
|DevOps: Better Than the Sum of Its Parts||Apr 20, 2015|
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
- DevOps: Better Than the Sum of Its Parts
- "No Reboot" Kernel Patching - And Why You Should Care
- Return of the Mac
- Android Candy: Intercoms
- Designing Foils with XFLR5
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- diff -u: What's New in Kernel Development
- Consent That Goes Both Ways
- Non-Linux FOSS: .NET?