These are the boot arguments that are not related to any specific device or peripheral. They are instead related to certain internal kernel parameters, such as memory handling, ramdisk handling, root file system handling and others.
The following options all pertain to how the kernel selects and handles the root filesystem.
This argument tells the kernel what device is to be used as the root filesystem while booting. The default of this setting is the value of the root device of the system that the kernel was built on. For example, if the kernel in question was built on a system that used `/dev/hda1' as the root partition, then the default root device would be `/dev/hda1'. To override this default value, and select the second floppy drive as the root device, one would use `root=/dev/fd1'.
Valid root devices are any of the following devices:
(1) /dev/hdaN to /dev/hddN, which is partition N on ST-506 compatible disk `a to d'.
(2) /dev/sdaN to /dev/sdeN, which is partition N on SCSI compatible disk `a to e'.
(3) /dev/xdaN to /dev/xdbN, which is partition N on XT compatible disk `a to b'.
(4) /dev/fdN, which is floppy disk drive number N. Having N=0 would be the DOS `A:' drive, and N=1 would be `B:'.
(5) /dev/nfs, which is not really a device, but rather a flag to tell the kernel to get the root fs via the network.
(6) /dev/ram, which is the RAM disk.
The more awkward and less portable numeric specification
of the above possible disk devices in major/minor format is
also accepted. (e.g. /dev/sda3 is major 8, minor 3, so you
could use root=0x803 as an alternative.)
This is one of the few kernel boot arguments that has its
default stored in the kernel image, and which can thus
be altered with the rdev utility.
When the kernel boots, it needs a root filesystem to read basic things off of. This is the root filesystem that is mounted at boot. However, if the root filesystem is mounted with write access, you can not reliably check the filesystem integrity with half-written files in progress. The `ro' option tells the kernel to mount the root filesystem as `readonly' so that any filesystem consistency check programs (fsck) can safely assume that there are no half-written files in progress while performing the check. No programs or processes can write to files on the filesystem in question until it is `remounted' as read/write capable.
This is one of the few kernel boot arguments that has its
default stored in the kernel image, and which can thus
be altered with the rdev utility.
This is the exact opposite of the above, in that it tells the kernel to mount the root filesystem as read/write. The default is to mount the root filesystem as read only. Do not run any `fsck' type programs on a filesystem that is mounted read/write.
The same value stored in the image file mentioned above is
also used for this parameter, accessible via rdev.
The following options all relate to how the kernel handles the RAM disk device, which is usually used for bootstrapping machines during the install phase, or for machines with modular drivers that need to be installed to access the root filesystem.
To allow a kernel image to reside on a floppy disk along with a compressed ramdisk image, the `ramdisk_start=<offset>' command was added. The kernel can't be included into the compressed ramdisk filesystem image, because it needs to be stored starting at block zero so that the BIOS can load the bootsector and then the kernel can bootstrap itself to get going.
Note: If you are using an uncompressed ramdisk image, then the kernel can be a part of the filesystem image that is being loaded into the ramdisk, and the floppy can be booted with LILO, or the two can be separate as is done for the compressed images.
If you are using a two-disk boot/root setup (kernel on disk 1, ramdisk image on disk 2) then the ramdisk would start at block zero, and an offset of zero would be used. Since this is the default value, you would not need to actually use the command at all.
This parameter tells the kernel whether it is to try to load a ramdisk image or not. Specifying `load_ramdisk=1' will tell the kernel to load a floppy into the ramdisk. The default value is zero, meaning that the kernel should not try to load a ramdisk.
Please see the file linux/Documentation/ramdisk.txt
for a complete description of the new boot time arguments, and
how to use them. A description of how this parameter can be set
and stored in the kernel image via `rdev' is also described.
This parameter tells the kernel whether or not to give you a prompt asking you to insert the floppy containing the ramdisk image. In a single floppy configuration the ramdisk image is on the same floppy as the kernel that just finished loading/booting and so a prompt is not needed. In this case one can use `prompt_ramdisk=0'. In a two floppy configuration, you will need the chance to switch disks, and thus `prompt_ramdisk=1' can be used. Since this is the default value, it doesn't really need to be specified. ( (Historical note: Sneaky people used to use the `vga=ask' LILO option to temporarily pause the boot process and allow a chance to switch from boot to root floppy.)
Please see the file linux/Documentation/ramdisk.txt
for a complete description of the new boot time arguments, and
how to use them. A description of how this parameter can be set
and stored in the kernel image via `rdev' is also described.
While it is true that the ramdisk grows dynamically as required, there is an upper bound on its size so that it doesn't consume all available RAM and leave you in a mess. The default is 4096 (i.e. 4MB) which should be large enough for most needs. You can override the default to a bigger or smaller size with this boot argument.
Please see the file linux/Documentation/ramdisk.txt
for a complete description of the new boot time arguments, and
how to use them. A description of how this parameter can be set
and stored in the kernel image via `rdev' is also described.
(NOTE: This argument is obsolete, and should not be used except on kernels v1.3.47 and older. The commands that should be used for the ramdisk device are documented above.)
This specifies the size in kB of the RAM disk device. For example, if one wished to have a root filesystem on a 1.44MB floppy loaded into the RAM disk device, they would use:
ramdisk=1440
This is one of the few kernel boot arguments that has its
default stored in the kernel image, and which can thus
be altered with the rdev utility.
The v2.x and newer kernels have a feature where the root filesystem
can be initially a RAM disk, and the kernel executes /linuxrc
on that RAM image. This feature is typically used to allow loading
of modules needed to mount the real root filesystem (e.g. load
the SCSI driver modules stored in the RAM disk image, and then
mount the real root filesystem on a SCSI disk.)
The actual `noinitrd' argument determines what happens to the
initrd data after the kernel has booted. When
specified, instead of converting it to a RAM disk, it
is accessible via /dev/initrd, which can be read once
before the RAM is released back to the system. For full details
on using the initial RAM disk, please consult
linux/Documentation/initrd.txt. In addition, the most
recent versions of LILO and LOADLIN should have additional
useful information.
Supplying a non-zero integer will enable the non maskable interrupt watchdog (assuming IO APIC support is compiled in). This checks to see if the interrupt count is increasing (indicating normal system activity) and if it is not then it assumes that a processor is stuck and forces an error dump of diagnostic information.
The following arguments alter how Linux detects or handles the physical and virtual memory of your system.
This argument has two purposes: The original purpose was to
specify the amount of installed memory (or a value less than
that if you wanted to limit the amount of memory available to
linux). The second (and hardly used) purpose is to specify
mem=nopentium which tells the Linux kernel to not use
the 4MB page table performance feature.
The original BIOS call defined in the PC specification that
returns the amount of installed memory was only designed to
be able to report up to 64MB. (Yes, another lack of foresight,
just like the 1024 cylinder disks... sigh.) Linux uses this
BIOS call at boot to determine how much memory is installed.
If you have more than 64MB of RAM installed, you can use this
boot argument to tell Linux how much memory you have.
Here is a quote from Linus on the usage of the mem= parameter.
``The kernel will accept any `mem=xx' parameter you give it, and if it turns out that you lied to it, it will crash horribly sooner or later. The parameter indicates the highest addressable RAM address, so `mem=0x1000000' means you have 16MB of memory, for example. For a 96MB machine this would be `mem=0x6000000'. If you tell Linux that it has more memory than it actually does have, bad things will happen: maybe not at once, but surely eventually.''
Note that the argument does not have to be in hex, and the
suffixes `k' and `M' (case insensitive) can be used to specify
kilobytes and Megabytes, respectively. (A `k' will cause a 10 bit
shift on your value, and a `M' will cause a 20 bit shift.)
A typical example for a 128MB machine would be "mem=128m".
Memory is broken down into zones; on i386 these zones
correspond to `DMA' (for legacy ISA devices that can only address
up to 16MB via DMA); `Normal' for memory from 16MB up to 1GB,
and `HighMem' for memory beyond 1GB (assuming your kernel
was built with high mem support enabled). The two (or three)
integers supplied here determine how much memory in each zone
should be kept free - with the size of the zone divided by the
number supplied being used as the minimum (so smaller numbers
mean keep more free in the zone). The defaults are currently
memfrac=32,128,128.
This allows the user to tune some of the virtual memory (VM) parameters that are related to swapping to disk. It accepts the following eight parameters:
MAX_PAGE_AGE
PAGE_ADVANCE
PAGE_DECLINE
PAGE_INITIAL_AGE
AGE_CLUSTER_FRACT
AGE_CLUSTER_MIN
PAGEOUT_WEIGHT
BUFFEROUT_WEIGHT
Interested hackers are advised to have a read of
linux/mm/swap.c and also make note of the goodies in
/proc/sys/vm. Kernels come with some
useful documentation on this in the
linux/Documentation/vm/ directory.
Similar to the `swap=' argument, this allows the user to tune some of the parameters related to buffer memory management. It accepts the following six parameters:
MAX_BUFF_AGE
BUFF_ADVANCE
BUFF_DECLINE
BUFF_INITIAL_AGE
BUFFEROUT_WEIGHT
BUFFERMEM_GRACE
Interested hackers are advised to have a read of
linux/mm/swap.c and also make note of the goodies
in /proc/sys/vm. Kernels come with some
useful documentation on this in the
linux/Documentation/vm/ directory.
Linux supports systems such as diskless workstations via
having their root filesystem as NFS (Network FileSystem).
These arguments are used to tell the diskless workstation
which machine it is to get its system from. Also note that
the argument root=/dev/nfs is required. Detailed
information on using an NFS root fs is in the file
linux/Documentation/nfsroot.txt.
This argument tells the kernel which machine, what directory and what NFS options to use for the root filesystem. The form of the argument is as follows:
nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]
If the nfsroot parameter is not given on the command line, the default `/tftpboot/%s' will be used. The other options are as follows:
<server-ip> -- Specifies the IP address of the NFS server. If this field is not given, the default address as determined by the nfsaddrs variable (see below) is used. One use of this parameter is for example to allow using different servers for RARP and NFS. Usually you can leave this blank.
<root-dir> -- Name of the directory on the server to mount as root. If there is a `%s' token in the string, the token will be replaced by the ASCII-representation of the client's IP address.
<nfs-options> -- Standard NFS options. All options are separated by commas. If the options field is not given, the following defaults will be used:
port = as given by server portmap daemon
rsize = 1024
wsize = 1024
timeo = 7
retrans = 3
acregmin = 3
acregmax = 60
acdirmin = 30
acdirmax = 60
flags = hard, nointr, noposix, cto, ac
This boot argument sets up the various network interface addresses that are required to communicate over the network. If this argument is not given, then the kernel tries to use RARP and/or BOOTP to figure out these parameters. The form is as follows:
nfsaddrs=<my-ip>:<serv-ip>:<gw-ip>:<netmask>:<name>:<dev>:<auto>
<my-ip> -- IP address of the client. If empty, the address will either be determined by RARP or BOOTP. What protocol is used de- pends on what has been enabled during kernel configuration and on the <auto> parameter. If this parameter is not empty, neither RARP nor BOOTP will be used.
<serv-ip> -- IP address of the NFS server. If RARP is used to determine the client address and this parameter is NOT empty only replies from the specified server are accepted. To use different RARP and NFS server, specify your RARP server here (or leave it blank), and specify your NFS server in the nfsroot parameter (see above). If this entry is blank the address of the server is used which answered the RARP or BOOTP request.
<gw-ip> -- IP address of a gateway if the server in on a different subnet. If this entry is empty no gateway is used and the server is assumed to be on the local network, unless a value has been received by BOOTP.
<netmask> -- Netmask for local network interface. If this is empty, the netmask is derived from the client IP address, unless a value has been received by BOOTP.
<name> -- Name of the client. If empty, the client IP address is used in ASCII-notation, or the value received by BOOTP.
<dev> -- Name of network device to use. If this is empty, all devices are used for RARP requests, and the first one found for BOOTP. For NFS the device is used on which either RARP or BOOTP replies have been received. If you only have one device you can safely leave this blank.
<auto> -- Method to use for autoconfiguration. If this is either `rarp' or `bootp' or `dhcp' the specified protocol is being used. If the value is `both' or empty, both RARP and BOOTP protocols are used so far as they have been enabled during kernel configuration Using 'none' means no autoconfiguration. In this case you have to specify all necessary values in the fields before.
The <auto> parameter can appear alone as the value to the nfsaddrs parameter (without all the `:' characters before) in which case autoconfiguration is used. However, the `none' value is not available in that case.
These various boot arguments let the user tune certain internal kernel parameters.
Currently this only accepts `off' to disable the ACPI subsystem.
Usually the console is the 1st virtual terminal, and so boot
messages appear on your VGA screen. Sometimes it is nice to
be able to use another device like a serial port (or even a
printer!) to be the console when no video device is present.
It is also useful to capture boot time messages if a problem
stops progress before they can be logged to disk.
An example would be to use
console=ttyS1,9600 for selecting the 2nd serial port
at 9600 baud to be the console.
More information can be found in
linux/Documentation/serial-console.txt.
The kernel communicates important (and not-so important)
messages to the operator via the printk() function.
If the message is considered important, the printk()
function will put a copy on the present console as well
as handing it off to the klogd() facility so that it
gets logged to disk. The reason for printing important
messages to the console as well as logging them to disk is
because under unfortunate circumstances (e.g. a disk failure)
the message won't make it to disk and will be lost.
The threshold for what is and what isn't considered important
is set by the console_loglevel variable. The default is
to log anything more important than DEBUG (level 7) to
the console. (These levels are defined in the include file
kernel.h) Specifying debug as a boot argument will
set the console loglevel to 10, so that all kernel
messages appear on the console.
The console loglevel can usually also be set at run time via
an option to the klogd() program. Check the man page
for the version installed on your system to see how to do this.
If you are using DECnet, you can supply two comma separated integers here to give your area and node respectively.
Setting this to `poll' causes the idle loop in the kernel to poll on the need reschedule flag instead of waiting for an interrupt to happen. This can result in an improvement in performance on SMP systems (albeit at the cost of an increase in power consumption).
The kernel defaults to starting the `init' program at boot,
which then takes care of setting up the computer for users
via launching getty programs, running `rc' scripts and the like.
The kernel first looks for /sbin/init, then
/etc/init (depreciated), and as a last resort, it
will try to use /bin/sh (possibly on /etc/rc).
If for example, your init program got corrupted and thus stopped
you from being able to boot, you could simply use the boot prompt
init=/bin/sh which would drop you directly into a
shell at boot, allowing you to replace the corrupted program.
This takes the form of:
isapnp=read_port,reset,skip_pci_scan,verbose
This takes the form of:
isapnp_reserve_dma=n1,n2,n3,...nN
where n1 ... nN are the DMA channel numbers to not use for PnP.
This takes the form of:
isapnp_reserve_irq=io1,size1,io2,size2,...ioN,sizeN
where ioX,sizeX are I/O start and length pairs of regions
in I/O space that are not to be used by PnP.
This takes the form of:
isapnp_reserve_irq=n1,n2,n3,...nN
where n1 ... nN are the interrupt numbers to not use for PnP.
This takes the form of:
isapnp_reserve_mem=mem1,size1,mem2,size2,...memN,sizeN
where ioX,sizeX are I/O start and length pairs of regions
in memory space that are not to be used by PnP.
Normally on i386 based machines, the Linux kernel does not reset the keyboard controller at boot, since the BIOS is supposed to do this. But as usual, not all machines do what they should. Supplying this option may help if you are having problems with your keyboard behaviour. It simply forces a reset at initialization time. (Some have argued that this should be the default behaviour anyways).
The number given with this argument limits the maximum
number of CPUs activated in SMP mode. Using a value of
0 is equivalent to the nosmp option.
The IBM model 95 Microchannel machines seem to lock up on the test that Linux usually does to detect the type of math chip coupling. Since all Pentium chips have a built in math processor, this test (and the lock up problem) can be avoided by using this boot option.
If your root filesystem is on a Multiple Device then you can
use this (assuming you compiled in boot support) to tell the
kernel the multiple device layout. The format (from the
file linux/Documentation/md.txt) is:
md=md_device_num,raid_level,chunk_size_factor,fault_level,dev0,dev1,...,devN
Where md_device_num is the number of the md device,
i.e. 0 means md0, 1 means md1, etc.
For raid_level, use -1 for linear mode and 0 for striped mode.
Other modes are currently unsupported.
The chunk_size_factor is for raid-0 and raid-1 only and
sets the chunk size as PAGE_SIZE shifted left the specified
amount. The fault_level is only for raid-1
and sets the maximum fault number to the specified number.
(Currently unsupported due to lack of boot support for raid1.)
The dev0-devN are a comma separated list of the devices that
make up the individual md device:
e.g. /dev/hda1,/dev/hdc1,/dev/sda1
Some i387 coprocessor chips have bugs that show up when used in 32 bit protected mode. For example, some of the early ULSI-387 chips would cause solid lockups while performing floating point calculations, apparently due to a bug in the FRSAV/FRRESTOR instructions. Using the `no387' boot argument causes Linux to ignore the math coprocessor even if you have one. Of course you must then have your kernel compiled with math emulation support! This may also be useful if you have one of those really old 386 machines that could use an 80287 FPU, as Linux can't use an 80287.
The i386 (and successors thereof) family of CPUs have a `hlt' instruction which tells the CPU that nothing is going to happen until an external device (keyboard, modem, disk, etc.) calls upon the CPU to do a task. This allows the CPU to enter a `low-power' mode where it sits like a zombie until an external device wakes it up (usually via an interrupt). Some of the early i486DX-100 chips had a problem with the `hlt' instruction, in that they couldn't reliably return to operating mode after this instruction was used. Using the `no-hlt' instruction tells Linux to just run an infinite loop when there is nothing else to do, and to not halt your CPU when there is no activity. This allows people with these broken chips to use Linux, although they would be well advised to seek a replacement through a warranty where possible.
Using this argument at boot disables scrolling features that make it difficult to use Braille terminals.
Using this option tells a SMP kernel to not use some of the
advanced features of the interrupt controller on multi processor
machines. Use of this option may be required when a device
(such as those using ne2k-pci or 3c59xi drivers) stops generating
interrupts (i.e. cat /proc/interrupts shows the same
interrupt count.)
See linux/Documentation/IO-APIC.txt for more information.
If ISA PnP is built into the kernel, this will disable it.
Some newer processors have the ability to self-monitor and detect inconsistencies that should not regularly happen. If an inconsistency is detected, a Machine Check Exception will take place and the system will be halted (rather than plundering forward and corrupting your data). You can use this argument to disable this feature, but be sure to check that your CPU is not overheating or otherwise faulty first.
Use of this option will tell a SMP kernel on a SMP machine to operate single processor. Typically only used for debugging and determining if a particular problem is SMP related.
Use of this option will tell the kernel to not use the Time Stamp Counter for anything, even if the CPU has one.
Use of this option will tell the kernel to not use any speed-up tricks involving the floating point unit, even if the processor supports them.
In the unlikely event of a kernel panic (i.e. an internal error
that has been detected by the kernel, and which the kernel decides
is serious enough to moan loudly and then halt everything), the
default behaviour is to just sit there until someone comes along
and notices the panic message on the screen and reboots the machine.
However if a machine is running unattended in an isolated location
it may be desirable for it to automatically reset itself so that
the machine comes back on line. For example, using panic=30 at
boot would cause the kernel to try and reboot itself 30 seconds
after the kernel panic happened. A value of zero gives the default
behaviour, which is to wait forever.
Note that this timeout value can also be read and set via the
/proc/sys/kernel/panic sysctl interface.
Using this option tells a SMP kernel information on the PCI
slot versus IRQ settings for SMP motherboards which are
unknown (or known to be blacklisted).
See linux/Documentation/IO-APIC.txt for more
information.
Kernel developers can
profile how and where the kernel is spending its CPU cycles
in an effort to maximize efficiency and performance. This
option lets you set the profile shift count at boot. Typically
it is set to two. You need a tool such as
readprofile.c that can make use of the /proc/profile
output.
This is pretty much the opposite of the `debug' argument. When this is given, only important and system critical kernel messages are printed to the console. Normal messages about hardware detection at boot are suppressed.
This option controls the type of reboot that Linux will do
when it resets the computer (typically via /sbin/init
handling a Control-Alt-Delete). The default as of v2.0
kernels is to do a `cold' reboot (i.e. full reset, BIOS does
memory check, etc.) instead of a `warm' reboot (i.e. no full
reset, no memory check). It was changed to be cold by default
since that tends to work on cheap/broken hardware that fails
to reboot when a warm reboot is requested. To get the old
behaviour (i.e. warm reboots) use reboot=w or in fact
any word that starts with w will work.
Why would you bother? Some disk controllers with cache memory on board can sense a warm reboot, and flush any cached data to disk. Upon a cold boot, the card may be reset and the write-back data in your cache card's memory is lost. Others have reported systems that take a long time to go through the memory check, and/or SCSI BIOSes that take longer to initialize on a cold boot as a good reason to use warm reboots.
This is used to protect I/O port regions from probes. The form of the command is:
reserve=iobase,extent[,iobase,extent]...
In some machines it may be necessary to prevent device drivers from checking for devices (auto-probing) in a specific region. This may be because of poorly designed hardware that causes the boot to freeze (such as some ethercards), hardware that is mistakenly identified, hardware whose state is changed by an earlier probe, or merely hardware you don't want the kernel to initialize.
The reserve boot-time argument addresses this problem by specifying
an I/O port region that shouldn't be probed. That region is reserved
in the kernel's port registration table as if a device has already
been found in that region (with the name reserved).
Note that this mechanism shouldn't be necessary on most machines.
Only when there is a problem or special case would it be necessary
to use this.
The I/O ports in the specified region are protected against
device probes that do a check_region() prior to probing
blindly into a region of I/O space. This was put in to be used
when some driver was hanging on a NE2000, or misidentifying
some other device as its own. A correct device driver shouldn't
probe a reserved region, unless another boot argument explicitly
specifies that it do so. This implies that reserve will
most often be used with some other boot argument. Hence if you
specify a reserve region to protect a specific device, you
must generally specify an explicit probe for that device. Most
drivers ignore the port registration table if they are given an
explicit address.
For example, the boot line
reserve=0x300,32 blah=0x300
keeps all device drivers except the driver for `blah' from
probing 0x300-0x31f.
As usual with boot-time specifiers there is an 11 parameter limit,
thus you can only specify 5 reserved regions per reserve keyword.
Multiple reserve specifiers will work if you have an unusually
complicated request.
Note that this is not really a boot argument. It is an option
that is interpreted by LILO and not by the kernel like all the
other boot arguments are. However its use has become so common
that it deserves a mention here. It can also be set via using
rdev -v or equivalently vidmode on the vmlinuz file.
This allows the setup code to use the video BIOS to change
the default display mode before actually booting the Linux
kernel. Typical modes are 80x50, 132x44 and so on. The best
way to use this option is to start with vga=ask which
will prompt you with a list of various modes that you can use
with your video adapter before booting the kernel. Once you
have the number from the above list that you want to use, you
can later put it in place of the `ask'. For more information,
please see the file linux/Documentation/svga.txt
that comes with all recent kernel versions.
Note that newer kernels (v2.1 and up) have the setup code that
changes the video mode as an option, listed as
Video mode selection support so you need to enable this
option if you want to use this feature.