{
    "mode": "man",
    "parameter": "bootparam",
    "section": "7",
    "url": "https://www.chedong.com/phpMan.php/man/bootparam/7/json",
    "generated": "2026-06-12T15:20:30Z",
    "sections": {
        "NAME": {
            "content": "bootparam - introduction to boot time parameters of the Linux kernel\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "The  Linux kernel accepts certain 'command-line options' or 'boot time parameters' at the mo‐\nment it is started.  In general, this is used to supply the  kernel  with  information  about\nhardware  parameters  that  the  kernel  would  not  be  able  to determine on its own, or to\navoid/override the values that the kernel would otherwise detect.\n\nWhen the kernel is booted directly by the BIOS, you have no opportunity to specify any param‐\neters.  So, in order to take advantage of this possibility you have to use a boot loader that\nis able to pass parameters, such as GRUB.\n",
            "subsections": [
                {
                    "name": "The argument list",
                    "content": "The kernel command line is parsed into a list of strings (boot arguments) separated  by  spa‐\nces.  Most of the boot arguments have the form:\n\nname[=value1][,value2]...[,value10]\n\nwhere 'name' is a unique keyword that is used to identify what part of the kernel the associ‐\nated values (if any) are to be given to.  Note the limit of 10 is real, as the  present  code\nhandles  only  10  comma  separated parameters per keyword.  (However, you can reuse the same\nkeyword with up to an additional 10 parameters in unusually complicated situations,  assuming\nthe setup function supports it.)\n\nMost of the sorting is coded in the kernel source file init/main.c.  First, the kernel checks\nto see if the argument is any of the  special  arguments  'root=',  'nfsroot=',  'nfsaddrs=',\n'ro', 'rw', 'debug' or 'init'.  The meaning of these special arguments is described below.\n\nThen  it  walks  a  list  of setup functions to see if the specified argument string (such as\n'foo') has been associated with a setup function ('foosetup()') for a particular  device  or\npart  of  the  kernel.   If  you passed the kernel the line foo=3,4,5,6 then the kernel would\nsearch the bootsetups array to see if 'foo' was registered.  If it was, then  it  would  call\nthe setup function associated with 'foo' (foosetup()) and hand it the arguments 3, 4, 5, and\n6 as given on the kernel command line.\n\nAnything of the form 'foo=bar' that is not accepted as a setup function as described above is\nthen  interpreted as an environment variable to be set.  A (useless?) example would be to use\n'TERM=vt100' as a boot argument.\n\nAny remaining arguments that were not picked up by the kernel and were not interpreted as en‐\nvironment  variables  are  then passed onto PID 1, which is usually the init(1) program.  The\nmost common argument that is passed to the init process is the word 'single' which  instructs\nit to boot the computer in single user mode, and not launch all the usual daemons.  Check the\nmanual page for the version of init(1) installed on your system to see what arguments it  ac‐\ncepts.\n"
                },
                {
                    "name": "General non-device-specific boot arguments",
                    "content": ""
                },
                {
                    "name": "'init=...'",
                    "content": "This  sets  the  initial command to be executed by the kernel.  If this is not set, or\ncannot be found, the kernel will try /sbin/init, then /etc/init, then /bin/init,  then\n/bin/sh and panic if all of this fails.\n"
                },
                {
                    "name": "'nfsaddrs=...'",
                    "content": "This sets the NFS boot address to the given string.  This boot address is used in case\nof a net boot.\n"
                },
                {
                    "name": "'nfsroot=...'",
                    "content": "This sets the NFS root name to the given string.  If this string does not  begin  with\n'/' or ',' or a digit, then it is prefixed by '/tftpboot/'.  This root name is used in\ncase of a net boot.\n"
                },
                {
                    "name": "'root=...'",
                    "content": "This argument tells the kernel what device is to be used as the root filesystem  while\nbooting.   The  default  of this setting is determined at compile time, and usually is\nthe value of the root device of the system that the kernel was built on.  To  override\nthis  value,  and  select  the  second  floppy drive as the root device, one would use\n'root=/dev/fd1'.\n\nThe root device can be specified symbolically or numerically.  A  symbolic  specifica‐\ntion  has  the  form  /dev/XXYN,  where  XX designates the device type (e.g., 'hd' for\nST-506 compatible hard disk, with Y in 'a'–'d'; 'sd' for SCSI compatible disk, with  Y\nin  'a'–'e'), Y the driver letter or number, and N the number (in decimal) of the par‐\ntition on this device.\n\nNote that this has nothing to do  with  the  designation  of  these  devices  on  your\nfilesystem.  The '/dev/' part is purely conventional.\n\nThe  more  awkward  and less portable numeric specification of the above possible root\ndevices in major/minor format is also accepted.  (For example, /dev/sda3 is  major  8,\nminor 3, so you could use 'root=0x803' as an alternative.)\n"
                },
                {
                    "name": "'rootdelay='",
                    "content": "This  parameter  sets  the  delay (in seconds) to pause before attempting to mount the\nroot filesystem.\n"
                },
                {
                    "name": "'rootflags=...'",
                    "content": "This parameter sets the  mount  option  string  for  the  root  filesystem  (see  also\nfstab(5)).\n"
                },
                {
                    "name": "'rootfstype=...'",
                    "content": "The  'rootfstype'  option tells the kernel to mount the root filesystem as if it where\nof the type specified.  This can be useful (for example) to mount an  ext3  filesystem\nas ext2 and then remove the journal in the root filesystem, in fact reverting its for‐\nmat from ext3 to ext2 without the need to boot the box from alternate media.\n\n'ro' and 'rw'\nThe 'ro' option tells the kernel to mount the root filesystem as 'read-only'  so  that\nfilesystem consistency check programs (fsck) can do their work on a quiescent filesys‐\ntem.  No processes can write to files on the filesystem in question until it  is  're‐\nmounted' as read/write capable, for example, by 'mount -w -n -o remount /'.  (See also\nmount(8).)\n\nThe 'rw' option tells the kernel to mount the root filesystem read/write.  This is the\ndefault.\n"
                },
                {
                    "name": "'resume=...'",
                    "content": "This  tells  the kernel the location of the suspend-to-disk data that you want the ma‐\nchine to resume from after hibernation.  Usually, it is the same as your  swap  parti‐\ntion or file.  Example:\n\nresume=/dev/hda2\n"
                },
                {
                    "name": "'reserve=...'",
                    "content": "This is used to protect I/O port regions from probes.  The form of the command is:\n\nreserve=iobase,extent[,iobase,extent]...\n\nIn  some  machines it may be necessary to prevent device drivers from checking for de‐\nvices (auto-probing) in a specific region.  This may be because of hardware  that  re‐\nacts  badly to the probing, or hardware that would be mistakenly identified, or merely\nhardware you don't want the kernel to initialize.\n\nThe reserve boot-time argument specifies an I/O port region that shouldn't be  probed.\nA device driver will not probe a reserved region, unless another boot argument explic‐\nitly specifies that it do so.\n\nFor example, the boot line\n\nreserve=0x300,32  blah=0x300\n\nkeeps all device drivers except the driver for 'blah' from probing 0x300-0x31f.\n"
                },
                {
                    "name": "'panic=N'",
                    "content": "By default, the kernel will not reboot after a panic, but this  option  will  cause  a\nkernel  reboot  after  N  seconds (if N is greater than zero).  This panic timeout can\nalso be set by\n\necho N > /proc/sys/kernel/panic\n"
                },
                {
                    "name": "'reboot=[warm|cold][,[bios|hard]]'",
                    "content": "Since Linux 2.0.22, a reboot is by default a cold reboot.  One asks for  the  old  de‐\nfault  with  'reboot=warm'.  (A cold reboot may be required to reset certain hardware,\nbut might destroy not yet written data in a disk cache.  A warm reboot may be faster.)\nBy  default,  a  reboot  is hard, by asking the keyboard controller to pulse the reset\nline low, but there is at least one type of motherboard where that doesn't work.   The\noption 'reboot=bios' will instead jump through the BIOS.\n\n'nosmp' and 'maxcpus=N'\n(Only  when SMP is defined.)  A command-line option of 'nosmp' or 'maxcpus=0' will\ndisable SMP activation entirely; an option 'maxcpus=N' limits the  maximum  number  of\nCPUs activated in SMP mode to N.\n"
                },
                {
                    "name": "Boot arguments for use by kernel developers",
                    "content": ""
                },
                {
                    "name": "'debug'",
                    "content": "Kernel  messages  are  handed off to a daemon (e.g., klogd(8) or similar) so that they\nmay be logged to disk.  Messages with  a  priority  above  consoleloglevel  are  also\nprinted on the console.  (For a discussion of log levels, see syslog(2).)  By default,\nconsoleloglevel is set to log messages at levels higher than KERNDEBUG.   This  boot\nargument will cause the kernel to also print messages logged at level KERNDEBUG.  The\nconsole loglevel can also be set on a booted system  via  the  /proc/sys/kernel/printk\nfile (described in syslog(2)), the syslog(2) SYSLOGACTIONCONSOLELEVEL operation, or\ndmesg(8).\n"
                },
                {
                    "name": "'profile=N'",
                    "content": "It is possible to enable a kernel profiling function, if one wishes to find out  where\nthe  kernel  is spending its CPU cycles.  Profiling is enabled by setting the variable\nprofshift to a nonzero value.  This is done either by  specifying  CONFIGPROFILE  at\ncompile  time, or by giving the 'profile=' option.  Now the value that profshift gets\nwill be N, when given, or CONFIGPROFILESHIFT, when that is given, or 2, the default.\nThe  significance  of this variable is that it gives the granularity of the profiling:\neach clock tick, if the system was executing kernel code, a counter is incremented:\n\nprofile[address >> profshift]++;\n\nThe raw profiling information can be read from /proc/profile.  Probably you'll want to\nuse  a  tool  such as readprofile.c to digest it.  Writing to /proc/profile will clear\nthe counters.\n"
                },
                {
                    "name": "Boot arguments for ramdisk use",
                    "content": "(Only if the kernel was compiled with CONFIGBLKDEVRAM.)  In general it is a  bad  idea  to\nuse  a ramdisk under Linux—the system will use available memory more efficiently itself.  But\nwhile booting, it is often useful to load the floppy contents into a ramdisk.  One might also\nhave  a system in which first some modules (for filesystem or hardware) must be loaded before\nthe main disk can be accessed.\n\nIn Linux 1.3.48, ramdisk handling was changed drastically.  Earlier,  the  memory  was\nallocated  statically,  and there was a 'ramdisk=N' parameter to tell its size.  (This\ncould also be set in the kernel image at compile time.)  These days ram disks use  the\nbuffer  cache,  and grow dynamically.  For a lot of information on the current ramdisk\nsetup, see  the  kernel  source  file  Documentation/blockdev/ramdisk.txt  (Documenta‐\ntion/ramdisk.txt in older kernels).\n\nThere are four parameters, two boolean and two integral.\n\n'loadramdisk=N'\nIf N=1, do load a ramdisk.  If N=0, do not load a ramdisk.  (This is the default.)\n\n'promptramdisk=N'\nIf N=1, do prompt for insertion of the floppy.  (This is the default.)  If N=0, do not\nprompt.  (Thus, this parameter is never needed.)\n\n'ramdisksize=N' or (obsolete) 'ramdisk=N'\nSet the maximal size of the ramdisk(s) to N kB.  The default is 4096 (4 MB).\n\n'ramdiskstart=N'\nSets the starting block number (the offset on the floppy where the ramdisk starts)  to\nN.  This is needed in case the ramdisk follows a kernel image.\n"
                },
                {
                    "name": "'noinitrd'",
                    "content": "(Only  if  the kernel was compiled with CONFIGBLKDEVRAM and CONFIGBLKDEVINITRD.)\nThese days it is possible to compile the kernel to use initrd.  When this  feature  is\nenabled, the boot process will load the kernel and an initial ramdisk; then the kernel\nconverts initrd into a \"normal\" ramdisk, which is mounted read-write as  root  device;\nthen  /linuxrc  is  executed; afterward the \"real\" root filesystem is mounted, and the\ninitrd filesystem is moved over to /initrd; finally the usual boot sequence (e.g., in‐\nvocation of /sbin/init) is performed.\n\nFor  a detailed description of the initrd feature, see the kernel source file Documen‐\ntation/admin-guide/initrd.rst (or Documentation/initrd.txt before Linux 4.10).\n\nThe 'noinitrd' option tells the kernel that although it  was  compiled  for  operation\nwith initrd, it should not go through the above steps, but leave the initrd data under\n/dev/initrd.  (This device can be used only once: the data is freed  as  soon  as  the\nlast process that used it has closed /dev/initrd.)\n"
                },
                {
                    "name": "Boot arguments for SCSI devices",
                    "content": "General notation for this section:\n\niobase -- the first I/O port that the SCSI host occupies.  These are specified in hexadecimal\nnotation, and usually lie in the range from 0x200 to 0x3ff.\n\nirq -- the hardware interrupt that the card is configured to use.  Valid values will  be  de‐\npendent  on the card in question, but will usually be 5, 7, 9, 10, 11, 12, and 15.  The other\nvalues are usually used for common peripherals like IDE hard disks, floppies,  serial  ports,\nand so on.\n\nscsi-id  --  the ID that the host adapter uses to identify itself on the SCSI bus.  Only some\nhost adapters allow you to change this value, as most have it  permanently  specified  inter‐\nnally.  The usual default value is 7, but the Seagate and Future Domain TMC-950 boards use 6.\n\nparity -- whether the SCSI host adapter expects the attached devices to supply a parity value\nwith all information exchanges.  Specifying a one indicates parity checking is enabled, and a\nzero  disables parity checking.  Again, not all adapters will support selection of parity be‐\nhavior as a boot argument.\n\n'maxscsiluns=...'\nA SCSI device can have a number of 'subdevices' contained  within  itself.   The  most\ncommon  example  is  one  of  the new SCSI CD-ROMs that handle more than one disk at a\ntime.  Each CD is addressed as a 'Logical Unit Number' (LUN) of  that  particular  de‐\nvice.  But most devices, such as hard disks, tape drives and such are only one device,\nand will be assigned to LUN zero.\n\nSome poorly designed SCSI devices cannot handle being probed for  LUNs  not  equal  to\nzero.   Therefore,  if  the  compile-time flag CONFIGSCSIMULTILUN is not set, newer\nkernels will by default probe only LUN zero.\n\nTo specify the number of probed LUNs at boot, one enters 'maxscsiluns=n' as  a  boot\narg, where n is a number between one and eight.  To avoid problems as described above,\none would use n=1 to avoid upsetting such broken devices.\n"
                },
                {
                    "name": "SCSI tape configuration",
                    "content": "Some boot time configuration of the SCSI tape driver can be achieved by using the fol‐\nlowing:\n\nst=bufsize[,writethreshold[,maxbufs]]\n\nThe  first  two  numbers are specified in units of kB.  The default bufsize is 32k B,\nand  the  maximum  size  that  can  be  specified  is  a  ridiculous  16384 kB.    The\nwritethreshold  is the value at which the buffer is committed to tape, with a default\nvalue of 30 kB.  The maximum number of buffers varies with the number  of  drives  de‐\ntected, and has a default of two.  An example usage would be:\n\nst=32,30,2\n\nFull   details   can   be  found  in  the  file  Documentation/scsi/st.txt  (or  driv‐\ners/scsi/README.st for older kernels) in the Linux kernel source.\n"
                },
                {
                    "name": "Hard disks",
                    "content": ""
                },
                {
                    "name": "IDE Disk/CD-ROM Driver Parameters",
                    "content": "The IDE driver accepts a number of parameters, which range from disk geometry specifi‐\ncations, to support for broken controller chips.  Drive-specific options are specified\nby using 'hdX=' with X in 'a'–'h'.\n\nNon-drive-specific options are specified with the prefix 'hd='.   Note  that  using  a\ndrive-specific  prefix for a non-drive-specific option will still work, and the option\nwill just be applied as expected.\n\nAlso note that 'hd=' can be used to refer to the next unspecified  drive  in  the  (a,\n...,  h)  sequence.  For the following discussions, the 'hd=' option will be cited for\nbrevity.  See the file Documentation/ide/ide.txt (or  Documentation/ide.txt  in  older\nkernels,  or  drivers/block/README.ide  in ancient kernels) in the Linux kernel source\nfor more details.\n"
                },
                {
                    "name": "The 'hd=cyls,heads,sects[,wpcom[,irq]]' options",
                    "content": "These options are used to specify the physical geometry of the disk.  Only  the  first\nthree  values  are  required.   The cylinder/head/sectors values will be those used by\nfdisk.  The write precompensation value is ignored for IDE disks.  The IRQ value spec‐\nified will be the IRQ used for the interface that the drive resides on, and is not re‐\nally a drive-specific parameter.\n"
                },
                {
                    "name": "The 'hd=serialize' option",
                    "content": "The dual IDE interface CMD-640 chip is broken as designed such that when drives on the\nsecondary  interface  are used at the same time as drives on the primary interface, it\nwill corrupt your data.  Using this option tells the driver to make sure that both in‐\nterfaces are never used at the same time.\n"
                },
                {
                    "name": "The 'hd=noprobe' option",
                    "content": "Do not probe for this drive.  For example,\n\nhdb=noprobe hdb=1166,7,17\n\nwould disable the probe, but still specify the drive geometry so that it would be reg‐\nistered as a valid block device, and hence usable.\n"
                },
                {
                    "name": "The 'hd=nowerr' option",
                    "content": "Some drives apparently have the WRERRSTAT bit stuck on permanently.  This  enables  a\nwork-around for these broken devices.\n"
                },
                {
                    "name": "The 'hd=cdrom' option",
                    "content": "This  tells  the IDE driver that there is an ATAPI compatible CD-ROM attached in place\nof a normal IDE hard disk.  In most cases the CD-ROM is identified automatically,  but\nif it isn't then this may help.\n"
                },
                {
                    "name": "Standard ST-506 Disk Driver Options ('hd=')",
                    "content": "The  standard  disk  driver can accept geometry arguments for the disks similar to the\nIDE driver.  Note however that it expects only three values (C/H/S); any more  or  any\nless  and  it  will  silently ignore you.  Also, it accepts only 'hd=' as an argument,\nthat is, 'hda=' and so on are not valid here.  The format is as follows:\n\nhd=cyls,heads,sects\n\nIf there are two disks installed, the above is repeated with the  geometry  parameters\nof the second disk.\n"
                },
                {
                    "name": "Ethernet devices",
                    "content": "Different  drivers  make  use  of different parameters, but they all at least share having an\nIRQ, an I/O port base value, and a name.  In its most generic form, it looks  something  like\nthis:\n\nether=irq,iobase[,param1[,...param8]],name\n\nThe  first nonnumeric argument is taken as the name.  The paramn values (if applicable) usu‐\nally have different meanings for each different card/driver.  Typical paramn values are used\nto specify things like shared memory address, interface selection, DMA channel and the like.\n\nThe  most common use of this parameter is to force probing for a second ethercard, as the de‐\nfault is to probe only for one.  This can be accomplished with a simple:\n\nether=0,0,eth1\n\nNote that the values of zero for the IRQ and I/O base in the above example tell the driver(s)\nto autoprobe.\n\nThe   Ethernet-HowTo  has  extensive  documentation  on  using  multiple  cards  and  on  the\ncard/driver-specific implementation of the paramn values  where  used.   Interested  readers\nshould refer to the section in that document on their particular card.\n"
                },
                {
                    "name": "The floppy disk driver",
                    "content": "There  are  many  floppy  driver  options,  and  they  are all listed in Documentation/block‐\ndev/floppy.txt (or Documentation/floppy.txt in older kernels, or drivers/block/README.fd  for\nancient kernels) in the Linux kernel source.  See that file for the details.\n"
                },
                {
                    "name": "The sound driver",
                    "content": "The  sound driver can also accept boot arguments to override the compiled-in values.  This is\nnot recommended, as it is rather complex.  It is described in the Linux  kernel  source  file\nDocumentation/sound/oss/README.OSS (drivers/sound/Readme.linux in older kernel versions).  It\naccepts a boot argument of the form:\n\nsound=device1[,device2[,device3...[,device10]]]\n\nwhere each deviceN value is of the following format 0xTaaaId and the bytes are used  as  fol‐\nlows:\n\nT - device type: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16, 7=SB16-MPU401\n\naaa - I/O address in hex.\n\nI - interrupt line in hex (i.e., 10=a, 11=b, ...)\n\nd - DMA channel.\n\nAs  you can see, it gets pretty messy, and you are better off to compile in your own personal\nvalues as recommended.  Using a boot argument of 'sound=0' will disable the sound driver  en‐\ntirely.\n"
                },
                {
                    "name": "The line printer driver",
                    "content": ""
                },
                {
                    "name": "'lp='",
                    "content": "Syntax:\n\nlp=0\nlp=auto\nlp=reset\nlp=port[,port...]\n\nYou can tell the printer driver what ports to use and what ports not to use.  The lat‐\nter comes in handy if you don't want the printer driver to claim all available  paral‐\nlel ports, so that other drivers (e.g., PLIP, PPA) can use them instead.\n\nThe  format  of  the  argument  is multiple port names.  For example, lp=none,parport0\nwould use the first parallel port for lp1, and disable lp0.  To  disable  the  printer\ndriver entirely, one can use lp=0.\n"
                }
            ]
        },
        "SEE ALSO": {
            "content": "klogd(8), mount(8)\n\nFor  up-to-date  information, see the kernel source file Documentation/admin-guide/kernel-pa‐\nrameters.txt.\n",
            "subsections": []
        },
        "COLOPHON": {
            "content": "This page is part of release 5.10 of the Linux  man-pages  project.   A  description  of  the\nproject,  information about reporting bugs, and the latest version of this page, can be found\nat https://www.kernel.org/doc/man-pages/.\n\n\n\nLinux                                        2017-09-15                                 BOOTPARAM(7)",
            "subsections": []
        }
    },
    "summary": "bootparam - introduction to boot time parameters of the Linux kernel",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "klogd",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/klogd/8/json"
        },
        {
            "name": "mount",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/mount/8/json"
        }
    ]
}