ascii

title: ascii(7)

text:
# ascii(7)

## NAME
ascii - ASCII character set encoded in octal, decimal, and hexadecimal

## DESCRIPTION
ASCII is the American Standard Code for Information Interchange. It is a 7-bit code. Many 8-bit codes (e.g., ISO 8859-1) contain ASCII as their lower half. The international counterpart of ASCII is known as ISO 646-IRV.

The following table contains the 128 ASCII characters.

C program '\X' escapes are noted.

Oct

Dec

Hex

Char

Oct

Dec

Hex

Char

000

0

00

NUL '\0' (null character)

100

64

40

@

001

1

01

SOH (start of heading)

101

65

41

A

002

2

02

STX (start of text)

102

66

42

B

003

3

03

ETX (end of text)

103

67

43

C

004

4

04

EOT (end of transmission)

104

68

44

D

005

5

05

ENQ (enquiry)

105

69

45

E

006

6

06

ACK (acknowledge)

106

70

46

F

007

7

07

BEL '\a' (bell)

107

71

47

G

010

8

08

BS '\b' (backspace)

110

72

48

H

011

9

09

HT '\t' (horizontal tab)

111

73

49

I

012

10

0A

LF '\n' (new line)

112

74

4A

J

013

11

0B

VT '\v' (vertical tab)

113

75

4B

K

014

12

0C

FF '\f' (form feed)

114

76

4C

L

015

13

0D

CR '\r' (carriage ret)

115

77

4D

M

016

14

0E

SO (shift out)

116

78

4E

N

017

15

0F

SI (shift in)

117

79

4F

O

020

16

10

DLE (data link escape)

120

80

50

P

021

17

11

DC1 (device control 1)

121

81

51

Q

022

18

12

DC2 (device control 2)

122

82

52

R

023

19

13

DC3 (device control 3)

123

83

53

S

024

20

14

DC4 (device control 4)

124

84

54

T

025

21

15

NAK (negative ack.)

125

85

55

U

026

22

16

SYN (synchronous idle)

126

86

56

V

027

23

17

ETB (end of trans. blk)

127

87

57

W

030

24

18

CAN (cancel)

130

88

58

X

031

25

19

EM (end of medium)

131

89

59

Y

032

26

1A

SUB (substitute)

132

90

5A

Z

033

27

1B

ESC (escape)

133

91

5B

[

034

28

1C

FS (file separator)

134

92

5C

\ '\\'

035

29

1D

GS (group separator)

135

93

5D

]

036

30

1E

RS (record separator)

136

94

5E

^

037

31

1F

US (unit separator)

137

95

5F

_

040

32

20

SPACE

140

96

60

`

041

33

21

!

141

97

61

a

042

34

22

"

142

98

62

b

043

35

23

\#

143

99

63

c

044

36

24

$

144

100

64

d

045

37

25

%

145

101

65

e

046

38

26

&

146

102

66

f

047

39

27

'

147

103

67

g

050

40

28

(

150

104

68

h

051

41

29

)

151

105

69

i

052

42

2A

*

152

106

6A

j

053

43

2B

+

153

107

6B

k

054

44

2C

,

154

108

6C

l

055

45

2D

-

155

109

6D

m

056

46

2E

.

156

110

6E

n

057

47

2F

/

157

111

6F

o

060

48

30

0

160

112

70

p

061

49

31

1

161

113

71

q

062

50

32

2

162

114

72

r

063

51

33

3

163

115

73

s

064

52

34

4

164

116

74

t

065

53

35

5

165

117

75

u

066

54

36

6

166

118

76

v

067

55

37

7

167

119

77

w

070

56

38

8

170

120

78

x

071

57

39

9

171

121

79

y

072

58

3A

:

172

122

7A

z

073

59

3B

;

173

123

7B

{

074

60

3C

<

174

124

7C

|

075

61

3D

=

175

125

7D

}

076

62

3E

>

176

126

7E

~

077

63

3F

?

177

127

7F

DEL

```

```

### Tables
For convenience, below are more compact tables in hex and decimal.

```
   2 3 4 5 6 7       30 40 50 60 70 80 90 100 110 120

 -------------      ---------------------------------
0:   0 @ P ` p     0:    (  2  <  F  P  Z  d   n   x
1: ! 1 A Q a q     1:    )  3  =  G  Q  [  e   o   y
2: " 2 B R b r     2:    *  4  >  H  R  \  f   p   z
3: # 3 C S c s     3: !  +  5  ?  I  S  ]  g   q   {
4: $ 4 D T d t     4: "  ,  6  @  J  T  ^  h   r   |
5: % 5 E U e u     5: #  -  7  A  K  U  _  i   s   }
6: & 6 F V f v     6: $  .  8  B  L  V  `  j   t   ~
7: ' 7 G W g w     7: %  /  9  C  M  W  a  k   u  DEL
8: ( 8 H X h x     8: &  0  :  D  N  X  b  l   v
9: ) 9 I Y i y     9: '  1  ;  E  O  Y  c  m   w
A: * : J Z j z
B: + ; K [ k {
C: , < L \ l |
D: - = M ] m }
E: . > N ^ n ~
F: / ? O _ o DEL
```

## NOTES

### History
/etc/ascii (VII) appears in the UNIX Programmer's Manual.

On older terminals, the underscore code is displayed as a left arrow, called backarrow, the caret is displayed as an up-arrow and the vertical bar has a hole in the middle.

Uppercase and lowercase characters differ by just one bit and the ASCII character 2 differs from the double quote by just one bit, too. That made it much easier to encode characters mechanically or with a non-microcontroller-based electronic keyboard and that pairing was found on old teletypes.

The ASCII standard was published by the United States of America Standards Institute (USASI) in 1968.

## SEE ALSO
charsets(7), iso_8859-1(7), iso_8859-2(7), iso_8859-3(7), iso_8859-4(7), iso_8859-5(7), iso_8859-6(7), iso_8859-7(7), iso_8859-8(7), iso_8859-9(7), iso_8859-10(7), iso_8859-11(7), iso_8859-13(7), iso_8859-14(7), iso_8859-15(7), iso_8859-16(7), utf-8(7)


attributes

package: man-pages

title: attributes(7)

summary: POSIX safety concepts

text:
# attributes(7)

## NAME
attributes - POSIX safety concepts

## DESCRIPTION
Note: the text of this man page is based on the material taken from the "POSIX Safety Concepts" section of the GNU C Library manual. Further details on the topics described here can be found in that manual.

Various function manual pages include a section ATTRIBUTES that describes the safety of calling the function in various contexts. This section annotates functions with the following safety markings:

MT-Safe

MT-Safe or Thread-Safe functions are safe to call in the presence of other threads. MT, in MT-Safe, stands for Multi Thread.

Being MT-Safe does not imply a function is atomic, nor that it uses any of the memory synchronization mechanisms POSIX exposes to users. It is even possible that calling MT-Safe functions in sequence does not yield an MT-Safe combination. For example, having a thread call two MT-Safe functions one right after the other does not guarantee behavior equivalent to atomic execution of a combination of both functions, since concurrent calls in other threads may interfere in a destructive way.

Whole-program optimizations that could inline functions across library interfaces may expose unsafe reordering, and so performing inlining across the GNU C Library interface is not recommended. The documented MT-Safety status is not guaranteed under whole-program optimization. However, functions defined in user-visible headers are designed to be safe for inlining.

MT-Unsafe

MT-Unsafe functions are not safe to call in a multithreaded programs.

Other keywords that appear in safety notes are defined in subsequent sections.

### Conditionally safe features
For some features that make functions unsafe to call in certain contexts, there are known ways to avoid the safety problem other than refraining from calling the function altogether. The keywords that follow refer to such features, and each of their definitions indicates how the whole program needs to be constrained in order to remove the safety problem indicated by the keyword. Only when all the reasons that make a function unsafe are observed and addressed, by applying the documented constraints, does the function become safe to call in a context.

init

Functions marked with init as an MT-Unsafe feature perform MT-Unsafe initialization when they are first called.

Calling such a function at least once in single-threaded mode removes this specific cause for the function to be regarded as MT-Unsafe. If no other cause for that remains, the function can then be safely called after other threads are started.

race

Functions annotated with race as an MT-Safety issue operate on objects in ways that may cause data races or similar forms of destructive interference out of concurrent execution. In some cases, the objects are passed to the functions by users; in others, they are used by the functions to return values to users; in others, they are not even exposed to users.

const

Functions marked with const as an MT-Safety issue non-atomically modify internal objects that are better regarded as constant, because a substantial portion of the GNU C Library accesses them without synchronization. Unlike race, which causes both readers and writers of internal objects to be regarded as MT-Unsafe, this mark is applied to writers only. Writers remain MT-Unsafe to call, but the then-mandatory constness of objects they modify enables readers to be regarded as MT-Safe (as long as no other reasons for them to be unsafe remain), since the lack of synchronization is not a problem when the objects are effectively constant.

The identifier that follows the const mark will appear by itself as a safety note in readers. Programs that wish to work around this safety issue, so as to call writers, may use a non-recursive read-write lock associated with the identifier, and guard all calls to functions marked with const followed by the identifier with a write lock, and all calls to functions marked with the identifier by itself with a read lock.

sig

Functions marked with sig as a MT-Safety issue may temporarily install a signal handler for internal purposes, which may interfere with other uses of the signal, identified after a colon.

This safety problem can be worked around by ensuring that no other uses of the signal will take place for the duration of the call. Holding a non-recursive mutex while calling all functions that use the same temporary signal; blocking that signal before the call and resetting its handler afterwards is recommended.

term

Functions marked with term as an MT-Safety issue may change the terminal settings in the recommended way, namely: call tcgetattr(3), modify some flags, and then call tcsetattr(3), this creates a window in which changes made by other threads are lost. Thus, functions marked with term are MT-Unsafe.

It is thus advisable for applications using the terminal to avoid concurrent and reentrant interactions with it, by not using it in signal handlers or blocking signals that might use it, and holding a lock while calling these functions and interacting with the terminal. This lock should also be used for mutual exclusion with functions marked with race:tcattr(fd), where fd is a file descriptor for the controlling terminal. The caller may use a single mutex for simplicity, or use one mutex per terminal, even if referenced by different file descriptors.

### Other safety remarks
Additional keywords may be attached to functions, indicating features that do not make a function unsafe to call, but that may need to be taken into account in certain classes of programs:

locale

Functions annotated with locale as an MT-Safety issue read from the locale object without any form of synchronization. Functions annotated with locale called concurrently with locale changes may behave in ways that do not correspond to any of the locales active during their execution, but an unpredictable mix thereof.

We do not mark these functions as MT-Unsafe, however, because functions that modify the locale object are marked with const:locale and regarded as unsafe. Being unsafe, the latter are not to be called when multiple threads are running or asynchronous signals are enabled, and so the locale can be considered effectively constant in these contexts, which makes the former safe.

env

Functions marked with env as an MT-Safety issue access the environment with getenv(3) or similar, without any guards to ensure safety in the presence of concurrent modifications.

We do not mark these functions as MT-Unsafe, however, because functions that modify the environment are all marked with const:env and regarded as unsafe. Being unsafe, the latter are not to be called when multiple threads are running or asynchronous signals are enabled, and so the environment can be considered effectively constant in these contexts, which makes the former safe.

hostid

The function marked with hostid as an MT-Safety issue reads from the system-wide data structures that hold the "host ID" of the machine. These data structures cannot generally be modified atomically. Since it is expected that the "host ID" will not normally change, the function that reads from it (gethostid(3)) is regarded as safe, whereas the function that modifies it (sethostid(3)) is marked with const:hostid, indicating it may require special care if it is to be called. In this specific case, the special care amounts to system-wide (not merely intra-process) coordination.

sigintr

Functions marked with sigintr as an MT-Safety issue access the GNU C Library _sigintr internal data structure without any guards to ensure safety in the presence of concurrent modifications.

We do not mark these functions as MT-Unsafe, however, because functions that modify this data structure are all marked with const:sigintr and regarded as unsafe. Being unsafe, the latter are not to be called when multiple threads are running or asynchronous signals are enabled, and so the data structure can be considered effectively constant in these contexts, which makes the former safe.

cwd

Functions marked with cwd as an MT-Safety issue may temporarily change the current working directory during their execution, which may cause relative pathnames to be resolved in unexpected ways in other threads or within asynchronous signal or cancelation handlers.

This is not enough of a reason to mark so-marked functions as MT-Unsafe, but when this behavior is optional (e.g., nftw(3) with FTW_CHDIR), avoiding the option may be a good alternative to using full pathnames or file descriptor-relative (e.g., openat(2)) system calls.

:identifier

Annotations may sometimes be followed by identifiers, intended to group several functions that, for example, access the data structures in an unsafe way, as in race and const, or to provide more specific information, such as naming a signal in a function marked with sig. It is envisioned that it may be applied to lock and corrupt as well in the future.

In most cases, the identifier will name a set of functions, but it may name global objects or function arguments, or identifiable properties or logical components associated with them, with a notation such as, for example, :buf(arg) to denote a buffer associated with the argument arg, or :tcattr(fd) to denote the terminal attributes of a file descriptor fd.

The most common use for identifiers is to provide logical groups of functions and arguments that need to be protected by the same synchronization primitive in order to ensure safe operation in a given context.

/condition

Some safety annotations may be conditional, in that they only apply if a boolean expression involving arguments, global variables or even the underlying kernel evaluates to true. For example, /!ps and /one_per_line indicate the preceding marker only applies when argument ps is NULL, or global variable one_per_line is nonzero.

When all marks that render a function unsafe are adorned with such conditions, and none of the named conditions hold, then the function can be regarded as safe.

## SEE ALSO
pthreads(7), signal-safety(7)

branch: sisyphus


boot

title: boot(7)

text:
# boot(7)

## NAME
boot - System bootup process based on UNIX System V Release 4

## DESCRIPTION
The bootup process (or "boot sequence") varies in details among systems, but can be roughly divided into phases controlled by the following components:

(1)

hardware

(2)

operating system (OS) loader

(3)

kernel

(4)

root user-space process (init and inittab)

(5)

boot scripts

Each of these is described below in more detail.

### Hardware
After power-on or hard reset, control is given to a program stored in read-only memory (normally PROM); for historical reasons involving the personal computer, this program is often called "the BIOS".

This program normally performs a basic self-test of the machine and accesses nonvolatile memory to read further parameters. This memory in the PC is battery-backed CMOS memory, so most people refer to it as "the CMOS"; outside of the PC world, it is usually called "the NVRAM" (nonvolatile RAM).

The parameters stored in the NVRAM vary among systems, but as a minimum, they should specify which device can supply an OS loader, or at least which devices may be probed for one; such a device is known as "the boot device". The hardware boot stage loads the OS loader from a fixed position on the boot device, and then transfers control to it.

Note:

The device from which the OS loader is read may be attached via a network, in which case the details of booting are further specified by protocols such as DHCP, TFTP, PXE, Etherboot, etc.

### OS loader
The main job of the OS loader is to locate the kernel on some device, load it, and run it. Most OS loaders allow interactive use, in order to enable specification of an alternative kernel (maybe a backup in case the one last compiled isn't functioning) and to pass optional parameters to the kernel.

In a traditional PC, the OS loader is located in the initial 512-byte block of the boot device; this block is known as "the MBR" (Master Boot Record).

In most systems, the OS loader is very limited due to various constraints. Even on non-PC systems, there are some limitations on the size and complexity of this loader, but the size limitation of the PC MBR (512 bytes, including the partition table) makes it almost impossible to squeeze much functionality into it.

Therefore, most systems split the role of loading the OS between a primary OS loader and a secondary OS loader; this secondary OS loader may be located within a larger portion of persistent storage, such as a disk partition.

In Linux, the OS loader is often grub(8) (an alternative is lilo(8)).

### Kernel
When the kernel is loaded, it initializes various components of the computer and operating system; each portion of software responsible for such a task is usually consider "a driver" for the applicable component. The kernel starts the virtual memory swapper (it is a kernel process, called "kswapd" in a modern Linux kernel), and mounts some filesystem at the root path, /.

Some of the parameters that may be passed to the kernel relate to these activities (for example, the default root filesystem can be overridden); for further information on Linux kernel parameters, read bootparam(7).

Only then does the kernel create the initial userland process, which is given the number 1 as its PID (process ID). Traditionally, this process executes the program /sbin/init, to which are passed the parameters that haven't already been handled by the kernel.

### Root user-space process
Note:

The following description applies to an OS based on UNIX System V Release 4. However, a number of widely used systems have adopted a related but fundamentally different approach known as systemd(1), for which the bootup process is detailed in its associated bootup(7).

When /sbin/init starts, it reads /etc/inittab for further instructions. This file defines what should be run when the /sbin/init program is instructed to enter a particular run level, giving the administrator an easy way to establish an environment for some usage; each run level is associated with a set of services (for example, run level S is single-user mode, and run level 2 entails running most network services).

The administrator may change the current run level via init(1), and query the current run level via runlevel(8).

However, since it is not convenient to manage individual services by editing this file, /etc/inittab only bootstraps a set of scripts that actually start/stop the individual services.

### Boot scripts
Note:

The following description applies to an OS based on UNIX System V Release 4. However, a number of widely used systems (Slackware Linux, FreeBSD, OpenBSD) have a somewhat different scheme for boot scripts.

For each managed service (mail, nfs server, cron, etc.), there is a single startup script located in a specific directory (/etc/init.d in most versions of Linux). Each of these scripts accepts as a single argument the word "start" (causing it to start the service) or the word "stop" (causing it to stop the service). The script may optionally accept other "convenience" parameters (e.g., "restart" to stop and then start, "status" to display the service status, etc.). Running the script without parameters displays the possible arguments.

### Sequencing directories
To make specific scripts start/stop at specific run levels and in a specific order, there are sequencing directories, normally of the form /etc/rc[0-6S].d. In each of these directories, there are links (usually symbolic) to the scripts in the /etc/init.d directory.

A primary script (usually /etc/rc) is called from inittab(5); this primary script calls each service's script via a link in the relevant sequencing directory. Each link whose name begins with 'S' is called with the argument "start" (thereby starting the service). Each link whose name begins with 'K' is called with the argument "stop" (thereby stopping the service).

To define the starting or stopping order within the same run level, the name of a link contains an order-number. Also, for clarity, the name of a link usually ends with the name of the service to which it refers. For example, the link /etc/rc2.d/S80sendmail starts the sendmail(8) service on run level 2. This happens after /etc/rc2.d/S12syslog is run but before /etc/rc2.d/S90xfs is run.

To manage these links is to manage the boot order and run levels; under many systems, there are tools to help with this task (e.g., chkconfig(8)).

### Boot configuration
A program that provides a service is often called a "daemon". Usually, a daemon may receive various command-line options and parameters. To allow a system administrator to change these inputs without editing an entire boot script, some separate configuration file is used, and is located in a specific directory where an associated boot script may find it (/etc/sysconfig on older Red Hat systems).

In older UNIX systems, such a file contained the actual command line options for a daemon, but in modern Linux systems (and also in HP-UX), it just contains shell variables. A boot script in /etc/init.d reads and includes its configuration file (that is, it "sources" its configuration file) and then uses the variable values.

## FILES
/etc/init.d/, /etc/rc[S0-6].d/, /etc/sysconfig/

## SEE ALSO
init(1), systemd(1), inittab(5), bootparam(7), bootup(7), runlevel(8), shutdown(8)


bootparam

title: bootparam(7)

text:
# bootparam(7)

## NAME
bootparam - introduction to boot time parameters of the Linux kernel

## DESCRIPTION
The Linux kernel accepts certain 'command-line options' or 'boot time parameters' at the moment it is started. In general, this is used to supply the kernel with information about hardware parameters that the kernel would not be able to determine on its own, or to avoid/override the values that the kernel would otherwise detect.

When the kernel is booted directly by the BIOS, you have no opportunity to specify any parameters. So, in order to take advantage of this possibility you have to use a boot loader that is able to pass parameters, such as GRUB.

### The argument list
The kernel command line is parsed into a list of strings (boot arguments) separated by spaces. Most of the boot arguments have the form:

```
name[=value_1][,value_2]...[,value_10]
```

where 'name' is a unique keyword that is used to identify what part of the kernel the associated values (if any) are to be given to. Note the limit of 10 is real, as the present code handles only 10 comma separated parameters per keyword. (However, you can reuse the same keyword with up to an additional 10 parameters in unusually complicated situations, assuming the setup function supports it.)

Most of the sorting is coded in the kernel source file init/main.c. First, the kernel checks to see if the argument is any of the special arguments 'root=', 'nfsroot=', 'nfsaddrs=', 'ro', 'rw', 'debug', or 'init'. The meaning of these special arguments is described below.

Then it walks a list of setup functions to see if the specified argument string (such as 'foo') has been associated with a setup function ('foo_setup()') for a particular device or part of the kernel. If you passed the kernel the line foo=3,4,5,6 then the kernel would search the bootsetups array to see if 'foo' was registered. If it was, then it would call the setup function associated with 'foo' (foo_setup()) and hand it the arguments 3, 4, 5, and 6 as given on the kernel command line.

Anything of the form 'foo=bar' that is not accepted as a setup function as described above is then interpreted as an environment variable to be set. A (useless?) example would be to use 'TERM=vt100' as a boot argument.

Any remaining arguments that were not picked up by the kernel and were not interpreted as environment variables are then passed onto PID 1, which is usually the init(1) program. The most common argument that is passed to the init process is the word 'single' which instructs it to boot the computer in single user mode, and not launch all the usual daemons. Check the manual page for the version of init(1) installed on your system to see what arguments it accepts.

### General non-device-specific boot arguments
'init=...'

This sets the initial command to be executed by the kernel. If this is not set, or cannot be found, the kernel will try /sbin/init, then /etc/init, then /bin/init, then /bin/sh and panic if all of this fails.

'nfsaddrs=...'

This sets the NFS boot address to the given string. This boot address is used in case of a net boot.

'nfsroot=...'

This sets the NFS root name to the given string. If this string does not begin with '/' or ',' or a digit, then it is prefixed by '/tftpboot/'. This root name is used in case of a net boot.

'root=...'

This argument tells the kernel what device is to be used as the root filesystem while booting. The default of this setting is determined at compile time, and usually is the value of the root device of the system that the kernel was built on. To override this value, and select the second floppy drive as the root device, one would use 'root=/dev/fd1'.

The root device can be specified symbolically or numerically. A symbolic specification has the form /dev/XXYN, where XX designates the device type (e.g., 'hd' for ST-506 compatible hard disk, with Y in 'a'–'d'; 'sd' for SCSI compatible disk, with Y in 'a'–'e'), Y the driver letter or number, and N the number (in decimal) of the partition on this device.

Note that this has nothing to do with the designation of these devices on your filesystem. The '/dev/' part is purely conventional.

The more awkward and less portable numeric specification of the above possible root devices in major/minor format is also accepted. (For example, /dev/sda3 is major 8, minor 3, so you could use 'root=0x803' as an alternative.)

'rootdelay='

This parameter sets the delay (in seconds) to pause before attempting to mount the root filesystem.

'rootflags=...'

This parameter sets the mount option string for the root filesystem (see also fstab(5)).

'rootfstype=...'

The 'rootfstype' option tells the kernel to mount the root filesystem as if it where of the type specified. This can be useful (for example) to mount an ext3 filesystem as ext2 and then remove the journal in the root filesystem, in fact reverting its format from ext3 to ext2 without the need to boot the box from alternate media.

'ro' and 'rw'

The 'ro' option tells the kernel to mount the root filesystem as 'read-only' so that filesystem consistency check programs (fsck) can do their work on a quiescent filesystem. No processes can write to files on the filesystem in question until it is 'remounted' as read/write capable, for example, by 'mount -w -n -o remount /'. (See also mount(8).)

The 'rw' option tells the kernel to mount the root filesystem read/write. This is the default.

'resume=...'

This tells the kernel the location of the suspend-to-disk data that you want the machine to resume from after hibernation. Usually, it is the same as your swap partition or file. Example:

```
resume=/dev/hda2

```

'reserve=...'

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 hardware that reacts badly to the probing, or hardware that would be mistakenly identified, or merely hardware you don't want the kernel to initialize.

The reserve boot-time argument specifies an I/O port region that shouldn't be probed. A device driver will not probe a reserved region, unless another boot argument explicitly specifies that it do so.

For example, the boot line

```
reserve=0x300,32  blah=0x300

```

keeps all device drivers except the driver for 'blah' from probing 0x300-0x31f.

'panic=N'

By default, the kernel will not reboot after a panic, but this option will cause a kernel reboot after N seconds (if N is greater than zero). This panic timeout can also be set by

```
echo N > /proc/sys/kernel/panic

```

'reboot=[warm|cold][,[bios|hard]]'

Since Linux 2.0.22, a reboot is by default a cold reboot. One asks for the old default with 'reboot=warm'. (A cold reboot may be required to reset certain hardware, but might destroy not yet written data in a disk cache. A warm reboot may be faster.) By default, a reboot is hard, by asking the keyboard controller to pulse the reset line low, but there is at least one type of motherboard where that doesn't work. The option 'reboot=bios' will instead jump through the BIOS.

'nosmp' and 'maxcpus=N'

(Only when __SMP__ is defined.) A command-line option of 'nosmp' or 'maxcpus=0' will disable SMP activation entirely; an option 'maxcpus=N' limits the maximum number of CPUs activated in SMP mode to N.

### Boot arguments for use by kernel developers
'debug'

Kernel messages are handed off to a daemon (e.g., klogd(8) or similar) so that they may be logged to disk. Messages with a priority above console_loglevel are also printed on the console. (For a discussion of log levels, see syslog(2).) By default, console_loglevel is set to log messages at levels higher than KERN_DEBUG. This boot argument will cause the kernel to also print messages logged at level KERN_DEBUG. The console loglevel can also be set on a booted system via the /proc/sys/kernel/printk file (described in syslog(2)), the syslog(2) SYSLOG_ACTION_CONSOLE_LEVEL operation, or dmesg(8).

'profile=N'

It is possible to enable a kernel profiling function, if one wishes to find out where the kernel is spending its CPU cycles. Profiling is enabled by setting the variable prof_shift to a nonzero value. This is done either by specifying CONFIG_PROFILE at compile time, or by giving the 'profile=' option. Now the value that prof_shift gets will be N, when given, or CONFIG_PROFILE_SHIFT, when that is given, or 2, the default. The significance of this variable is that it gives the granularity of the profiling: each clock tick, if the system was executing kernel code, a counter is incremented:

```
profile[address >> prof_shift]++;

```

The raw profiling information can be read from /proc/profile. Probably you'll want to use a tool such as readprofile.c to digest it. Writing to /proc/profile will clear the counters.

### Boot arguments for ramdisk use
(Only if the kernel was compiled with CONFIG_BLK_DEV_RAM.) In general it is a bad idea to use a ramdisk under Linux—the system will use available memory more efficiently itself. But while booting, it is often useful to load the floppy contents into a ramdisk. One might also have a system in which first some modules (for filesystem or hardware) must be loaded before the main disk can be accessed.

In Linux 1.3.48, ramdisk handling was changed drastically. Earlier, the memory was allocated statically, and there was a 'ramdisk=N' parameter to tell its size. (This could also be set in the kernel image at compile time.) These days ram disks use the buffer cache, and grow dynamically. For a lot of information on the current ramdisk setup, see the kernel source file Documentation/blockdev/ramdisk.txt (Documentation/ramdisk.txt in older kernels).

There are four parameters, two boolean and two integral.

'load_ramdisk=N'

If N=1, do load a ramdisk. If N=0, do not load a ramdisk. (This is the default.)

'prompt_ramdisk=N'

If N=1, do prompt for insertion of the floppy. (This is the default.) If N=0, do not prompt. (Thus, this parameter is never needed.)

'ramdisk_size=N' or (obsolete) 'ramdisk=N'

Set the maximal size of the ramdisk(s) to N kB. The default is 4096 (4 MB).

'ramdisk_start=N'

Sets the starting block number (the offset on the floppy where the ramdisk starts) to N. This is needed in case the ramdisk follows a kernel image.

'noinitrd'

(Only if the kernel was compiled with CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD.) These days it is possible to compile the kernel to use initrd. When this feature is enabled, the boot process will load the kernel and an initial ramdisk; then the kernel converts initrd into a "normal" ramdisk, which is mounted read-write as root device; then /linuxrc is executed; afterward the "real" root filesystem is mounted, and the initrd filesystem is moved over to /initrd; finally the usual boot sequence (e.g., invocation of /sbin/init) is performed.

For a detailed description of the initrd feature, see the kernel source file Documentation/admin-guide/initrd.rst (or Documentation/initrd.txt before Linux 4.10).

The 'noinitrd' option tells the kernel that although it was compiled for operation with initrd, it should not go through the above steps, but leave the initrd data under /dev/initrd. (This device can be used only once: the data is freed as soon as the last process that used it has closed /dev/initrd.)

### Boot arguments for SCSI devices
General notation for this section:

iobase -- the first I/O port that the SCSI host occupies. These are specified in hexadecimal notation, and usually lie in the range from 0x200 to 0x3ff.

irq -- the hardware interrupt that the card is configured to use. Valid values will be dependent on the card in question, but will usually be 5, 7, 9, 10, 11, 12, and 15. The other values are usually used for common peripherals like IDE hard disks, floppies, serial ports, and so on.

scsi-id -- the ID that the host adapter uses to identify itself on the SCSI bus. Only some host adapters allow you to change this value, as most have it permanently specified internally. The usual default value is 7, but the Seagate and Future Domain TMC-950 boards use 6.

parity -- whether the SCSI host adapter expects the attached devices to supply a parity value with all information exchanges. Specifying a one indicates parity checking is enabled, and a zero disables parity checking. Again, not all adapters will support selection of parity behavior as a boot argument.

'max_scsi_luns=...'

A SCSI device can have a number of 'subdevices' contained within itself. The most common example is one of the new SCSI CD-ROMs that handle more than one disk at a time. Each CD is addressed as a 'Logical Unit Number' (LUN) of that particular device. But most devices, such as hard disks, tape drives, and such are only one device, and will be assigned to LUN zero.

Some poorly designed SCSI devices cannot handle being probed for LUNs not equal to zero. Therefore, if the compile-time flag CONFIG_SCSI_MULTI_LUN is not set, newer kernels will by default probe only LUN zero.

To specify the number of probed LUNs at boot, one enters 'max_scsi_luns=n' as a boot arg, where n is a number between one and eight. To avoid problems as described above, one would use n=1 to avoid upsetting such broken devices.

SCSI tape configuration

Some boot time configuration of the SCSI tape driver can be achieved by using the following:

```
st=buf_size[,write_threshold[,max_bufs]]

```

The first two numbers are specified in units of kB. The default buf_size is 32k B, and the maximum size that can be specified is a ridiculous 16384 kB. The write_threshold is the value at which the buffer is committed to tape, with a default value of 30 kB. The maximum number of buffers varies with the number of drives detected, and has a default of two. An example usage would be:

```
st=32,30,2

```

Full details can be found in the file Documentation/scsi/st.txt (or drivers/scsi/README.st for older kernels) in the Linux kernel source.

### Hard disks
IDE Disk/CD-ROM Driver Parameters

The IDE driver accepts a number of parameters, which range from disk geometry specifications, to support for broken controller chips. Drive-specific options are specified by using 'hdX=' with X in 'a'–'h'.

Non-drive-specific options are specified with the prefix 'hd='. Note that using a drive-specific prefix for a non-drive-specific option will still work, and the option will just be applied as expected.

Also note that 'hd=' can be used to refer to the next unspecified drive in the (a, ..., h) sequence. For the following discussions, the 'hd=' option will be cited for brevity. See the file Documentation/ide/ide.txt (or Documentation/ide.txt in older kernels, or drivers/block/README.ide in ancient kernels) in the Linux kernel source for more details.

The 'hd=cyls,heads,sects[,wpcom[,irq]]' options

These options are used to specify the physical geometry of the disk. Only the first three values are required. The cylinder/head/sectors values will be those used by fdisk. The write precompensation value is ignored for IDE disks. The IRQ value specified will be the IRQ used for the interface that the drive resides on, and is not really a drive-specific parameter.

The 'hd=serialize' option

The dual IDE interface CMD-640 chip is broken as designed such that when drives on the secondary interface are used at the same time as drives on the primary interface, it will corrupt your data. Using this option tells the driver to make sure that both interfaces are never used at the same time.

The 'hd=noprobe' option

Do not probe for this drive. For example,

```
hdb=noprobe hdb=1166,7,17

```

would disable the probe, but still specify the drive geometry so that it would be registered as a valid block device, and hence usable.

The 'hd=nowerr' option

Some drives apparently have the WRERR_STAT bit stuck on permanently. This enables a work-around for these broken devices.

The 'hd=cdrom' option

This tells the IDE driver that there is an ATAPI compatible CD-ROM attached in place of a normal IDE hard disk. In most cases the CD-ROM is identified automatically, but if it isn't then this may help.

Standard ST-506 Disk Driver Options ('hd=')

The standard disk driver can accept geometry arguments for the disks similar to the IDE driver. Note however that it expects only three values (C/H/S); any more or any less and it will silently ignore you. Also, it accepts only 'hd=' as an argument, that is, 'hda=' and so on are not valid here. The format is as follows:

```
hd=cyls,heads,sects

```

If there are two disks installed, the above is repeated with the geometry parameters of the second disk.

### Ethernet devices
Different drivers make use of different parameters, but they all at least share having an IRQ, an I/O port base value, and a name. In its most generic form, it looks something like this:

```
ether=irq,iobase[,param_1[,...param_8]],name
```

The first nonnumeric argument is taken as the name. The param_n values (if applicable) usually have different meanings for each different card/driver. Typical param_n values are used to specify things like shared memory address, interface selection, DMA channel and the like.

The most common use of this parameter is to force probing for a second ethercard, as the default is to probe only for one. This can be accomplished with a simple:

```
ether=0,0,eth1
```

Note that the values of zero for the IRQ and I/O base in the above example tell the driver(s) to autoprobe.

The Ethernet-HowTo has extensive documentation on using multiple cards and on the card/driver-specific implementation of the param_n values where used. Interested readers should refer to the section in that document on their particular card.

### The floppy disk driver
There are many floppy driver options, and they are all listed in Documentation/blockdev/floppy.txt (or Documentation/floppy.txt in older kernels, or drivers/block/README.fd for ancient kernels) in the Linux kernel source. See that file for the details.

### The sound driver
The sound driver can also accept boot arguments to override the compiled-in values. This is not recommended, as it is rather complex. It is described in the Linux kernel source file Documentation/sound/oss/README.OSS (drivers/sound/Readme.linux in older kernel versions). It accepts a boot argument of the form:

```
sound=device1[,device2[,device3...[,device10]]]
```

where each deviceN value is of the following format 0xTaaaId and the bytes are used as follows:

T - device type: 1=FM, 2=SB, 3=PAS, 4=GUS, 5=MPU401, 6=SB16, 7=SB16-MPU401

aaa - I/O address in hex.

I - interrupt line in hex (i.e., 10=a, 11=b, ...)

d - DMA channel.

As you can see, it gets pretty messy, and you are better off to compile in your own personal values as recommended. Using a boot argument of 'sound=0' will disable the sound driver entirely.

### The line printer driver
'lp='

Syntax:

```
lp=0
lp=auto
lp=reset
lp=port[,port...]

```

You can tell the printer driver what ports to use and what ports not to use. The latter comes in handy if you don't want the printer driver to claim all available parallel ports, so that other drivers (e.g., PLIP, PPA) can use them instead.

The format of the argument is multiple port names. For example, lp=none,parport0 would use the first parallel port for lp1, and disable lp0. To disable the printer driver entirely, one can use lp=0.

## SEE ALSO
klogd(8), mount(8)

For up-to-date information, see the kernel source file Documentation/admin-guide/kernel-parameters.txt.