Updated: 2013-05-08 21:01 EDT
/boot
directoryGRUB
lilo
/boot
directoryIndex/boot
, which may be a separately mounted partition at the start of the disk/boot
is located near the beginning of the disk because older BIOSes can’t address disk blocks at the middle or end of larger disks!/boot
problem is a BIOS limitation, not a Linux limitation.GRUB
Indexmenu.lst
, grub.conf
, or grub.cfg
under /boot/grub/
/etc/grub.d/
and you should edit the pieces, not the main file/etc/grub.conf
to the real location under /boot/grub/
/etc/grub.conf
has a completely different function - to configure GRUB installation!All versions of GRUB use a configuration file under /boot/grub
to display a menu of alternative operating systems to boot. Without a configuration file, GRUB starts in interactive mode and you have to specify and type everything yourself. With a configuration file, you can select from a menu list of choices.
In GRUB Legacy, each choice in the configuration file starts with a title
keyword followed by a descriptive name:
# Sample GRUB menu.lst or grub.conf file (GRUB Legacy version 0.9x)
timeout=30
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
default=0
# this sdb disk has partition sdb1 for /boot and sdb2 for / (ROOT)
# (Note how pathnames do *not* start with /boot on a separate partition!)
title Fedora 2.6.31 on second disk
root (hd1,0)
kernel /vmlinuz-2.6.31.5-127.fc12.i686.PAE ro root=/dev/sdb2
initrd /initramfs-2.6.31.5-127.fc12.i686.PAE.img
# this sdc disk has partition sdc1 for / (ROOT) and uses a /boot directory
# (not a separate /boot partition, so pathnames must start with /boot)
title Old Fedora 2.6.23 on third disk
password sesame
root (hd2,0)
kernel /boot/vmlinuz-2.6.23.15.137.fc8 ro root=/dev/sdc1
initrd /boot/initrd-2.6.23.15.137.fc8.img
# this first disk partition has a Windows boot loader in the first sector
title Windows on first disk
rootnoverify (hd0,0)
makeactive
chainloader +1
Notes:
title
section is for general GRUB configuration options - see below for the keywords:
timeout
: how long the menu waits before selecting the defaultdefault
: which title
section to boot when the time-out happens
splashimage
: a pretty picture to put behind the GRUB menuhiddenmenu
: hide the GRUB menu during the boot processtitle
boot menu entry sections for Linux kernels have these keywords:
root
: lets you set this prefix for all following GRUB pathnames, similar to cd
in the shell
(hd0,0)
/foo
becomes complete path (hd1,0)/foo
kernel
: the Linux kernel image followed by optional kernel optionsinitrd
: the initial RAM disk to be used by the kernel at boot timepassword
: require the given password to boot this menu entrygrub.conf
keywordsIndextitle
sections):
default
n (optional): The nth title
boot menu item, starting at 0, will be booted. Otherwise, the first (zeroth) title
item is booted.timeout
20 (optional): Number of seconds before booting into default.password
sesame (optional): Disable interactive editing and protect all boot menus that include the lock
optiontitle
sections):
title
: Menu title of this boot menukernel
: Location of Linux kernel file, followed by optionslock
(optional): Requires global password to boot this menu entrypassword
(optional): require the given password to boot this menu entryNote: To find out about additional GRUB commands, type help
at the GRUB shell prompt, and see the above Resources.
/boot
partition on GRUB pathnamesIndexGRUB configuration files are stored under directory /boot/grub
in Linux. /boot/grub
is the Linux pathname, not necessarily the GRUB pathname, because GRUB pathnames are composed of a partition name followed by a pathname inside the partition, e.g. (hd0,0)/some/path/name
where /some/path/name
is relative to the start of the partition.
Since partitions are mounted on directories in Linux, and those directory pathnames prefix the names inside the partition for Linux pathnames, a GRUB pathname and a Linux absolute pathname will always differ, except for the one partition that is mounted on ROOT (because prefixing an absolute pathname with /
(ROOT) doesn’t change it).
/boot
is on the ROOT partitionIndexIf /boot
is not its own partition, then it is a directory inside the existing ROOT partition. GRUB shell command pathnames referring to the kernel and to GRUB configuration files will also be inside the ROOT partition and will therefore all start with the ROOT partition name followed by the subdirectory name /boot
inside the partition, e.g. (hd0,0)/boot/grub/grub.conf
refers to the Linux pathname /boot/grub/grub.conf
because /boot
is an ordinary directory inside the ROOT partition (hd0,0)
.
/boot
is its own partitionIndexIf /boot
is its own mounted partition, then the GRUB files will be on this separate BOOT partition (not on the ROOT partition) that gets mounted on /boot
and the GRUB pathnames (which are relative to the start of the partition, not relative to the ROOT of the file system) will therefore not start with /boot
, they will start directly under the BOOT partition device name e.g. (hd0,0)/grub/grub.conf
refers to the Linux pathname /boot/grub/grub.conf
(because (hd0,0)
is mounted on /boot
and so /boot
is prefixed to the part of the pathname contained inside the partition).
/boot
partition: (hd0,0)/grub/grub.conf
/boot
is under ROOT: (hd0,0)/boot/grub/grub.conf
Fedora 12 uses a separate BOOT partition. The comments in its GRUB configuration file tell you this. Do not use /boot
at the start of GRUB pathnames because the pathnames are inside their own BOOT partition (that will be mounted on /boot
) and GRUB addresses pathnames by partition name.
Your Linux installation already installed GRUB for you. If you have to re-install GRUB, you may find (or be able to install) the grub-install
script that will do it for you. You can also try it manually, if the GRUB setup files are already stored under /boot/grub
:
root
, type grub
at the command line: this will load GRUB and display the GRUB shell prompt grub>
setup
with two GRUB pathname arguments: the boot sector installation device and the device containing the GRUB setup files
setup (hd0) (hd0,0)
quit
command when doneMost versions of the GRUB shell have TAB command completion, where you can type part of a device or pathname and GRUB will give you all the possible completions. The command-line GRUB in Fedora 12 is broken, and does not have this feature. The GRUB that runs at boot time is not broken and does have the TAB completion feature.
BE CAREFUL. GRUB does not ask you for confirmation! If you type the wrong thing, you will overwrite your boot sector with garbage and be unable to boot your system. You will need to boot a “live” CD and repair.
Options provided on the kernel
line in a GRUB configuration file influence how the system boots and what software might be enabled. The options are given after the kernel image name on a kernel
line and allow you to boot your system with different features enabled. Some versions of GRUB allow you to type a
while viewing the GRUB menu, to go directly to a GRUB kernel
line and edit the kernel options. Options are separated by blanks, e.g.: ro single txt 3
When you edit these GRUB lines, you are only changing the in-memory copy of the configuration, you are not changing the actual configuration in the GRUB configuration file on disk. To make any edit permanent, you must boot the system (single-user is fine) and actually edit the GRUB configuration file and save it.
Single-user mode is a “half-up” state used for system repair and maintenance (especially for resetting the root
password!). The system only brings up a minimal number of services (often none). The GUI is not started. Networking may not be enabled. Not all disks may be mounted. The console terminal gets a shell running as the root
user.
To boot into single-user mode, add the word single
as an option to a kernel
line in a GRUB boot menu entry and then boot that entry, e.g.:
kernel (hd0,0)/vmlinuz ro root=/dev/sda3 single
(Run Levels are summarized below.) To start Linux with a different Run Level than the default, add the Run Level digit to the end of the kernel
options line during boot, e.g. to boot Run Level 3 (which on Fedora 12 means boot multi-user without the X11 GUI window system), use the GRUB menu to add 3
to the end of the kernel
options:
kernel /vmlinuz ro root=/dev/sda2 3
If you moved your ROOT file system to a different partition but forgot to change the GRUB configuration file, your kernel will “panic” and tell you it can’t find the ROOT file system. You can reboot into the GRUB shell and edit the root=
option on the kernel
line to point to the correct ROOT partition:
kernel (hd0,0)/vmlinuz ro root=/dev/sdb2
The System V Run Levels system was a crude way to specify groups of services (such as the Apache Web Server, or the Secure Shell Server) that were to be started and stopped together. Run Levels expect that a system boots into a fixed state, with a fixed set of disks and fixed set of services. They do not work well with systems where devices come and go after booting, e.g. dynamic USB drives, printers, cameras, hotplug disks, etc.
Since Enterprise Servers (systems with a long maintenance window) typically boot into a fixed state where devices don’t come and go, Run Levels are still a useful and simple way of configuring Enterprise systems. Enterprise systems still use Run Levels, and even the newer versions of the system boot process (using the new Upstart or Systemd) emulate traditional Run Levels. (Fedora 12 uses Upstart to emulate Run Levels.)
The system can be in only one Run Level at a time, but can be moved to any other Run Level. Changing Run Levels cause services to be started and stopped to match what is supposed to be available in that Run Level.
Each Run Level is given a number. The broad meaning of each Run Level is usually documented in comments inside the file /etc/inittab
in a table that looks similar to this (from Fedora 12):
# 0 - Halt (Do NOT set the initdefault default run level to this)
# 1 - Single user mode
# 2 - Multi-user, without NFS (The same as 3, if you do not have networking)
# 3 - Full multi-user mode, text-only
# 4 - not used
# 5 - Full multi-user mode, with X11
# 6 - reboot (Do NOT set the initdefault default run level to this)
id:5:initdefault:
The last line of this file (initdefault
) is the only active (non-comment) line in the file. It gives the Run Level number that the system will normally boot into.
As you can see above, Fedora 12 Linux uses seven Run Levels, numbered 0
through 6
, with Run Level 5
being the default Run Level.
You can tell the system to change Run Levels using commands such as telinit
. The shutdown
and reboot
commands also change Run Levels. Changing Run Levels will cause some system services to stop and others to start. Run Levels are not an ordered sequence; the system goes directly between Run Levels, it does not “pass through” Run Levels 3 and 4 when going from, say, Run Level 2 to Run Level 5.
The meanings of the Fedora 12 Run Levels are given in the /etc/inittab
file:
shutdown
command instead!)initdefault
to this or else you will never be able to boot your system!root
shell on the system console (no password needed).root
password.login:
prompt.login:
prompt.shutdown
command instead!)initdefault
to this or else you will never be able to boot your system! (Use the shutdown
command instead!)Higher numbered Run Levels generally mean more and more services started, but the highest Run Level (6
) is used to reboot the system without warning. Run Levels are not an ordered sequence. When going from, say, Run Level 2 to Run Level 5 the system goes directly between Run Levels; it does not “pass through” Run Levels 3 and 4.
Fedora 12 actually uses the newer Upstart event-based services system, but hides most of that Upstart functionality behind a traditional Run Levels emulation layer. You can read about Upstart below.
/etc/inittab
IndexThe default Run Level to use at boot time is set by the initdefault
option of the /etc/inittab
file. It looks like this if your default Run Level is number 5
:
id:5:initdefault:
To display previous and current system Run Levels, use the runlevel
command:
$ runlevel
N 5
An N
will be printed as the previous Run Level right after booting, otherwise the first number will be the previous run level number.
Only root
can tell the system to change Run Levels.
To change Run Levels (as root
) use the telinit
command with an argument of the desired Run Level, e.g. telinit 5
See the table of Run Levels in the comments in the /etc/inittab
file to know what each Run Level number means.
You rarely need to explicitly tell the system to change Run Levels. The shutdown
command is much better for shutting down and/or rebooting the system, because shutdown
will send a warning message to all logged-in users.
You can change Run Levels while the system is running using commands such as telinit
, but that command doesn’t print any warning messages.
Usually use shutdown
to shut down or reboot the system, because shutdown
will send a warning message to all logged-in users.
chkconfig
IndexSystem services are started and stopped for each Run Level. You can see which services are on and off in each of the seven Run Levels using the chkconfig
command:
$ chkconfig | wc
57 456 3195 # there are 57 possible services available
$ chkconfig --list sshd
sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
$ chkconfig | grep syslog
rsyslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off
$ chkconfig
NetworkManager 0:off 1:off 2:on 3:on 4:on 5:on 6:off
abrtd 0:off 1:off 2:off 3:on 4:off 5:on 6:off
acpid 0:off 1:off 2:on 3:on 4:on 5:on 6:off
atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
avahi-daemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off
bluetooth 0:off 1:off 2:off 3:on 4:on 5:on 6:off
btseed 0:off 1:off 2:off 3:off 4:off 5:off 6:off
bttrack 0:off 1:off 2:off 3:off 4:off 5:off 6:off
cpuspeed 0:off 1:on 2:on 3:on 4:on 5:on 6:off
... many more lines ...
The chkconfig
output gives a list of the known services and whether each service is supposed to be turned on or off in that Run Level.
The chkconfig
command cannot tell you if the service is actually and currently on or off; it only knows what should be on or off and it does not start or stop any services itself. If you want to check whether or not a service is actually running, use the ps
command to look for it.
You can use shell pipelines on the output of chkconfig
, for example to find out which services are enabled to start in at least one Run Level:
# chkconfig | grep ':on'
NetworkManager 0:off 1:off 2:on 3:on 4:on 5:on 6:off
abrtd 0:off 1:off 2:off 3:on 4:off 5:on 6:off
acpid 0:off 1:off 2:on 3:on 4:on 5:on 6:off
atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
avahi-daemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off
bluetooth 0:off 1:off 2:off 3:on 4:off 5:off 6:off
cpuspeed 0:off 1:on 2:on 3:on 4:on 5:on 6:off
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
cups 0:off 1:off 2:on 3:on 4:on 5:on 6:off
... many more lines ...
A common use of chkconfig
is to change which services are supposed to be turned on or off in which Run Level (requires root
permissions):
# chkconfig --list bluetooth
bluetooth 0:off 1:off 2:off 3:on 4:on 5:on 6:off
# chkconfig --level 45 bluetooth off
# chkconfig --list bluetooth
bluetooth 0:off 1:off 2:off 3:on 4:off 5:off 6:off
You can also completely remove (delete) a service from chkconfig
so that it does not appear at all in the output. (RTFM)
chkconfig
IndexIf chkconfig
is not available, you can still discover and change which services run in each Run Level by knowing how the System V Run Levels system works.
Services (such as the SSH server or the HTTP server) are started using shell scripts. All the SysV-style service start-up scripts are kept in directory /etc/init.d/
:
$ ls /etc/init.d/http* /etc/init.d/ssh*
/etc/init.d/httpd /etc/init.d/sshd
$ wc /etc/init.d/http* /etc/init.d/ssh*
119 426 3158 /etc/init.d/httpd
234 669 4537 /etc/init.d/sshd
Symbolic links to these scripts are placed in directory /etc/rc?.d/
, e.g. the services for Run Level 3 are listed under directory /etc/rc3.d
:
$ ls -l /etc/rc3.d/*ssh* /etc/rc3.d/*http*
lrwxrwxrwx. 1 root root 15 2011-09-02 09:53 /etc/rc3.d/K15httpd -> ../init.d/httpd
lrwxrwxrwx. 1 root root 14 2011-09-02 09:54 /etc/rc3.d/S55sshd -> ../init.d/sshd
The symbolic links starting with S
and a number start a service; the symbolic links starting with K
and a number stop (“kill”) a service, e.g.
/etc/rc3.d/K15httpd # symlink to kill the HTTP daemon in Run Level 3
/etc/rc3.d/S55sshd # symlink to start the SSH daemon in Run Level 3
Each of those symlinks points to a script file responsible for killing or starting the indicated service. Without chkconfig
, you can change what services get killed or started by manually adding or removing symlinks from the corresponding /etc/rc?.d
Run Level directories.
A service is started in a Run Level by calling its SysV start-up script with a single argument of start
. A service is stopped in a Run Level by calling its SysV start-up script with a single argument of stop
.
Most Run Level changes that cause these scripts to run happen at boot time and system shut down, though you can use the telinit
command to change Run Levels if you need to.
While is is always possible to create and remove the symbolic links in the rc?.d
directories by hand (using ln -s
and rm
), the chkconfig
command is the preferred tool for listing and manipulating these symbolic links in their Run Level directories.
Many/most of the SysV start-up scripts in /etc/init.d
contain a chkconfig
comment line in the comments at the start of the script. The comment line might look something like this:
$ grep 'chkconfig' /etc/init.d/crond
# chkconfig: 2345 90 60
The above shell comment line is readable by chkconfig
if you give chkconfig
the reset
option for that service. With reset
, chkconfig
will read the above line and make sure there are start/stop symlinks for the service in Run Levels 2,3,4,5 at priority 90 and 60. For example:
# chkconfig crond reset
Now chkconfig --list crond
will show crond
enabled in Run Levels 2,3,4,5. The crond
service will start at priority 90 and stop at priority 60. You can confirm this by looking for the symlinks in all the /etc/rc?.d
directories:
$ chkconfig --list crond
crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off
$ ls /etc/rc?.d/*crond*
/etc/rc0.d/K60crond /etc/rc3.d/S90crond /etc/rc6.d/K60crond
/etc/rc1.d/K60crond /etc/rc4.d/S90crond
/etc/rc2.d/S90crond /etc/rc5.d/S90crond
Note: You can always add the appropriate start/stop symlinks manually in the rc?.d
directories if the above procedure isn’t possible because the chkconfig
command is missing. Don’t depend on chkconfig
!
service
IndexUsing chkconfig
to change which servers are supposed to be on or off in any Run Level does not change what services are actually and currently running (or not running). A service may have died unexpectedly, or have been stopped or started manually.
System services can be started, stopped, and reset using the service
command (as root
) with a service name and an appropriate command operation argument:
# service crond
Usage: /etc/init.d/crond {start|stop|status|restart|condrestart|try-restart|reload|force-reload}
# service crond status
crond (pid 1597) is running...
# service crond restart
Stopping crond: [ OK ]
Starting crond: [ OK ]
# service crond status
crond (pid 8207) is running...
All services support the start
and stop
commands, which are used to start and stop services when the system changes Run Levels. You can omit any commands to generate a list of what other commands are possible:
# service httpd
Usage: httpd {start|stop|restart|condrestart|reload|status|fullstatus|graceful|help|configtest}
If your system is missing the service
command, you can always execute any service script directly from the /etc/init.d/
directory, passing it an argument of what function you want to perform:
# /etc/init.d/crond status
crond (pid 8207) is running...
Remember: chkconfig
only specifies what services should be on or off in a Run Level. It does not start or stop any services. You can start or stop any services in any Run Level using the service
command.
Fixed Run Levels do not work well on dynamic systems such as user Desktop or Workstation systems where devices come and go after booting, e.g. USB drives, printers, cameras, hotplug disks, etc. Run Levels can only start a fixed set of services, and there is no clean way using Run Levels to start a new service when a new device is plugged in and to stop it when the device is unplugged.
Modern Unix/Linux systems moved away from static Run Levels to use the more dynamic and complex Upstart system of starting/stopping services. Run Levels are “emulated” by Upstart, but Upstart can handle devices coming and going dynamically much better. When devices were added/removed, “events” were generated that could start and stop related system services.
Red Hat replaced the legacy System V init system (Run Levels) with the improved Upstart system for their Enterprise Linux 6.
The complexity and limitations of Upstart prompted Lennart Poettering to write a new Linux-only Systemd session manager. Fedora 15 then moved from using Upstart to use the new Linux-only Systemd. Red Hat Enterprise Linux is planning to move from Upstart to Systemd in the next release. (Yes, Upstart was used for only one release.)
The Debian Linux distribution is reluctant to use a Linux-only start-up system that won’t work on non-Linux systems (such as Debian GNU/kFreeBSD), and so Debian and Ubuntu still use the Upstart system, not Systemd.
In early 2013, there is still considerable controversy on the move from booting with Upstart to booting with Systemd. Fedora and Red Hat are moving to Systemd; Debian and Ubuntu are staying with Upstart; other distributions are watching the battle to see who wins.
See these references for some background on the heated discussions:
udev
developers
Good luck with the future of Linux booting.