Linux Command Line Parameters
If you are using the LILO (LInux LOader) program to boot Linux (usually from hard disk), then you can pass command-line options to the kernel at boot time. Typically these are set in the configuration file /etc/lilo.conf.
This is the most flexible method. It allows you, for example, to boot different kernels or boot the same kernel with different options.
Most options are passed by LILO on to the kernel; one useful option is parsed and handled by LILO itself. ,The console video mode for VGA displays can be set using a command-line option of the form:
where mode can be one of:
“normal” for the default 80-column by 24-line display,
“extended” or “ext” for 80 columns by 50 lines,
“ask” to prompt the user at boot up time for the mode to use, or
a decimal number to select various other modes, dependent on the type of VGA card (for example, on my Trident VGA card, mode 6 is 132x30).
Let's now look at the specific options supported by the Linux kernel. These affect the behavior of the kernel itself and are not passed on to the init program.
Some of these options accept a numeric value, parsed by a simplified version of the strtoul library function. Values can be given in decimal (e.g., 1234), octal (e.g., 01234) or hexadecimal (e.g., 0x1234), and should be separated by spaces. Let's now examine each of the options.
This option sets the root device; the device used as the root (“/”) filesystem; when booting. It accepts a value from a hard-coded list of common devices: /dev/hda..b (IDE hard disks), /dev/sda..e (SCSI disks), /dev/fd (floppy), and /dev/xda..b (XT hard disks). These are mapped into the corresponding major and minor device numbers.
This option indicates that the root filesystem should be mounted readonly. Typically this is done in order to run fsck on bootup.
This option is the converse of the previous one, indicating that the root filesystem should be mounted for both read and write, the normal case once a Linux system has been booted.
This option sets the kernel logging level to 10, rather than the default value of 7. It sets the global variable “console_loglevel”. Currently this make no visible difference; apparently there is no kemel code that displays messages at levels higher than 7.
This sets the global variable “hlt_works_ok” to 0. When Linux is idle, it runs the previously mentioned idle process in a loop (found in kernel/sys.c). Having the idle process periodically execute a hlt (halt) instruction reduces power consumption on some machines, most notably laptops. However, a few users have reported problems with the kilt instruction on certain machines, so it can be disabled with this option.
Incidently, I routinely use this option on my desktop system; I find that it significantly reduces the level of bus noise picked up on my sound card.
This option sets the global variable “hard_math” to 0. It forces the kernel to use co-processor emulation, even if one is installed. This can be useful if you suspect hardware problems with your co-processor or if you want to measure performance without a math chip.
This option specifies to the kernel the highest memory address to use (specified in bytes). Normally Linux uses all of the available memory. This feature can be useful for simulating machines with less memory or debugging cache problems on machines with lots of memory. As an experiment, try booting your machine with less memory, say 2MB, to highlight the difference memory makes. As another experiment, see what happens if you lie and tell Linux you have more memory than is installed...
reserve=port, size. . .
This option reserves I/O ports; it marks them as used so they will not be probed by device drivers that do autoprobing. This may be needed on certain systems that have unusual hardware or device conflicts.
This option sets the size of the RAM disk, in bytes.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide