{
    "mode": "man",
    "parameter": "bootparam",
    "section": "7",
    "url": "https://www.chedong.com/phpMan.php/man/bootparam/7/json",
    "generated": "2026-10-07T19:08:52Z",
    "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  para‐\nmeters.   So,  in  order  to take advantage of this possibility you have to use a boot loader\nthat is 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\nspaces.  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"
                },
                {
                    "name": "'load_ramdisk=N'",
                    "content": "If N=1, do load a ramdisk.  If N=0, do not load a ramdisk.  (This is the default.)\n"
                },
                {
                    "name": "'prompt_ramdisk=N'",
                    "content": "If 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"
                },
                {
                    "name": "'ramdisk_start=N'",
                    "content": "Sets  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"
                },
                {
                    "name": "'max_scsi_luns=...'",
                    "content": "A  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  de‐\nvice, and 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   dri‐\nvers/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 card/dri‐\nver-specific implementation of the paramn values where used.  Interested readers should  re‐\nfer 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-para‐\nmeters.txt.\n\nLinux man-pages 6.7                          2023-10-31                                 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"
        }
    ]
}