| Installation GuideInternet Small Computer System Interface (iSCSI) is a protocol that allows computers to communicate with storage devices by SCSI requests and responses carried over TCP/IP. Because iSCSI is based on the standard SCSI protocols, it uses some terminology from SCSI. The device on the SCSI bus to which requests get sent (and which answers these requests) is known as the target and the device issuing requests is known as the initiator. In other words, an iSCSI disk is a target and the iSCSI software equivalent of a SCSI controller or SCSI Host Bus Adapter (HBA) is called an initiator. This appendix only covers Linux as an iSCSI initiator: how Linux uses iSCSI disks, but not how Linux hosts iSCSI disks. Linux has a software iSCSI initiator in the kernel that takes the place and form of a SCSI HBA driver and therefore allows Linux to use iSCSI disks. However, as iSCSI is a fully network-based protocol, iSCSI initiator support needs more than just the ability to send SCSI packets over the network. Before Linux can use an iSCSI target, Linux must find the target on the network and make a connection to it. In some cases, Linux must send authentication information to gain access to the target. Linux must also detect any failure of the network connection and must establish a new connection, including logging in again if necessary. The discovery, connection, and logging in is handled in userspace by the iscsiadm utility, and the error handling is also handled in userspace by iscsid. Both iscsiadm and iscsid are part of the iscsi-initiator-utils package under Red Hat Enterprise Linux. B.1. iSCSI disks in anacondaAnaconda can discover (and then log in to) iSCSI disks in two ways: When anaconda starts, it checks if the BIOS or add-on boot ROMs of the system support iSCSI Boot Firmware Table (iBFT), a BIOS extension for systems which can boot from iSCSI. If the BIOS supports iBFT, anaconda will read the iSCSI target information for the configured boot disk from the BIOS and log in to this target, making it available as an installation target. If you select the Specialized Storage Devices option during installation, the storage device selection screen presents you with an Add Advanced Target button. If you click this button, you can add iSCSI target information like the discovery IP address. Anaconda probes the given IP address and logs in to any targets that it finds. See Section 9.6.1.1, " Advanced Storage Options " for the details that you can specify for iSCSI targets.
While anaconda uses iscsiadm to find and log into iSCSI targets, iscsiadm automatically stores any information about these targets in the iscsiadm iSCSI database. Anaconda then copies this database to the installed system and marks any iSCSI targets not used for / so that the system will automatically log in to them when it starts. If / is placed on an iSCSI target, initrd will log into this target and anaconda does not include this target in start up scripts to avoid multiple attempts to log into the same target. If / is placed on an iSCSI target, anaconda sets NetworkManager to ignore any network interfaces that were active during the installation process. These interfaces will also be configured by initrd when the system starts. If NetworkManager were to reconfigure these interfaces, the system would lose its connection to /. B.2. iSCSI disks during start upISCSI-related events might occur at a number of points while the system starts: The init script in the initrd will log in to iSCSI targets used for / (if any). This is done using the iscsistart utility (which can do this without requiring iscsid to run). When the root filesystem has been mounted and the various service initscripts get run, the iscsid initscript will get called. This script will then start iscsid if any iSCSI targets are used for /, or if any targets in the iSCSI database are marked to be logged in to automatically. After the classic network service script has been run (or would have been run if enabled) the iscsi initscript will run. If the network is accessible, this will log in to any targets in the iSCSI database which are marked to be logged in to automatically. If the network is not accessible, this script will exit quietly. When using NetworkManager to access the network (instead of the classic network service script), NetworkManager will call the iscsi initscript. See: /etc/NetworkManager/dispatcher.d/04-iscsi Because NetworkManager is installed in /usr, you cannot use it to configure network access if /usr is on network-attached storage such as an iSCSI target.
If iscsid is not needed as the system starts, it will not start automatically. If you start iscsiadm, iscsiadm will start iscsid in turn. C.1. What is block device encryption? Block device encryption protects the data on a block device by encrypting it. To access the device's decrypted contents, a user must provide a passphrase or key as authentication. This provides additional security beyond existing OS security mechanisms in that it protects the device's contents even if it has been physically removed from the system. C.2. Encrypting block devices using dm-crypt/LUKS Linux Unified Key Setup (LUKS) is a specification for block device encryption. It establishes an on-disk format for the data, as well as a passphrase/key management policy. LUKS uses the kernel device mapper subsystem via the dm-crypt module. This arrangement provides a low-level mapping that handles encryption and decryption of the device's data. User-level operations, such as creating and accessing encrypted devices, are accomplished through the use of the cryptsetup utility. What LUKS does: LUKS encrypts entire block devices LUKS is thereby well-suited for protecting the contents of mobile devices such as: Removable storage media Laptop disk drives
The underlying contents of the encrypted block device are arbitrary. LUKS uses the existing device mapper kernel subsystem. LUKS provides passphrase strengthening. LUKS devices contain multiple key slots.
What LUKS does not do: LUKS is not well-suited for applications requiring many (more than eight) users to have distinct access keys to the same device. LUKS is not well-suited for applications requiring file-level encryption.
C.2.2. How will I access the encrypted devices after installation? (System Startup) During system startup you will be presented with a passphrase prompt. After the correct passphrase has been provided the system will continue to boot normally. If you used different passphrases for multiple encrypted devices you may need to enter more than one passphrase during the startup. Consider using the same passphrase for all encrypted block devices in a given system. This will simplify system startup and you will have fewer passphrases to remember. Just make sure you choose a good passphrase! C.2.3. Choosing a Good Passphrase While dm-crypt/LUKS supports both keys and passphrases, the anaconda installer only supports the use of passphrases for creating and accessing encrypted block devices during installation. LUKS does provide passphrase strengthening but it is still a good idea to choose a good (meaning "difficult to guess") passphrase. Note the use of the term "passphrase", as opposed to the term "password". This is intentional. Providing a phrase containing multiple words to increase the security of your data is important. C.3. Creating Encrypted Block Devices in Anaconda You can create encrypted devices during system installation. This allows you to easily configure a system with encrypted partitions. To enable block device encryption, check the "Encrypt System" checkbox when selecting automatic partitioning or the "Encrypt" checkbox when creating an individual partition, software RAID array, or logical volume. After you finish partitioning, you will be prompted for an encryption passphrase. This passphrase will be required to access the encrypted devices. If you have pre-existing LUKS devices and provided correct passphrases for them earlier in the install process the passphrase entry dialog will also contain a checkbox. Checking this checkbox indicates that you would like the new passphrase to be added to an available slot in each of the pre-existing encrypted block devices. Checking the "Encrypt System" checkbox on the "Automatic Partitioning" screen and then choosing "Create custom layout" does not cause any block devices to be encrypted automatically. You can use kickstart to set a separate passphrase for each new encrypted block device. C.3.1. What Kinds of Block Devices Can Be Encrypted? Most types of block devices can be encrypted using LUKS. From anaconda you can encrypt partitions, LVM physical volumes, LVM logical volumes, and software RAID arrays. C.3.2. Saving PassphrasesIf you use a kickstart file during installation, you can automatically save the passphrases used during installation to an encrypted file (an escrow packet) on the local file system. To use this feature, you must have an X.509 certificate available at a location that anaconda can access. To specify the URL of this certificate, add the --escrowcert parameter to any of the autopart, logvol, part or raid commands. During installation, the encryption keys for the specified devices are saved in files in /root, encrypted with the certificate. You can save escrow packets during installation only with the use of a kickstart file - refer to Chapter 32, Kickstart Installations for more detail. You cannot save an escrow packet during an interactive installation, although you can create one on an installed system with the volume_key tool. The volume_key tool also allows you to use the information stored in an escrow packet to restore access to an encrypted volume. Refer to the volume_key manpage for more information. C.3.3. Creating and Saving Backup PassphrasesIf you use a kickstart file during installation, anaconda can add a randomly generated backup passphrase to each block device on the system and save each passphrase to an encrypted file on the local file system. Specify the URL of this certificate with the --escrowcert parameter as described in Section C.3.2, "Saving Passphrases", followed by the --backuppassphrase parameter for each of the kickstart commands that relate to the devices for which you want to create backup passphrases. C.4. Creating Encrypted Block Devices on the Installed System After Installation Encrypted block devices can be created and configured after installation. C.4.1. Create the block devices Create the block devices you want to encrypt by using parted, pvcreate, lvcreate and mdadm. C.4.2. Optional: Fill the device with random dataFilling <device> (eg: /dev/sda3) with random data before encrypting it greatly increases the strength of the encryption. The downside is that it can take a very long time. The commands below will destroy any existing data on the device. The best way, which provides high quality random data but takes a long time (several minutes per gigabyte on most systems): dd if=/dev/urandom of=<device> Fastest way, which provides lower quality random data: badblocks -c 10240 -s -w -t random -v <device>
C.4.3. Format the device as a dm-crypt/LUKS encrypted device The command below will destroy any existing data on the device. cryptsetup luksFormat <device> For more information, read the cryptsetup(8) man page. After supplying the passphrase twice the device will be formatted for use. To verify, use the following command: cryptsetup isLuks <device> && echo Success To see a summary of the encryption information for the device, use the following command: cryptsetup luksDump <device> C.4.4. Create a mapping to allow access to the device's decrypted contents To access the device's decrypted contents, a mapping must be established using the kernel device-mapper. It is useful to choose a meaningful name for this mapping. LUKS provides a UUID (Universally Unique Identifier) for each device. This, unlike the device name (eg: /dev/sda3), is guaranteed to remain constant as long as the LUKS header remains intact. To find a LUKS device's UUID, run the following command: cryptsetup luksUUID <device> An example of a reliable, informative and unique mapping name would be luks-<uuid>, where <uuid> is replaced with the device's LUKS UUID (eg: luks-50ec957a-5b5a-47ee-85e6-f8085bbc97a8). This naming convention might seem unwieldy but is it not necessary to type it often. cryptsetup luksOpen <device> <name> There should now be a device node, /dev/mapper/<name>, which represents the decrypted device. This block device can be read from and written to like any other unencrypted block device. To see some information about the mapped device, use the following command: dmsetup info <name> For more information, read the dmsetup(8) man page. C.4.5. Create filesystems on the mapped device, or continue to build complex storage structures using the mapped device Use the mapped device node (/dev/mapper/<name>) as any other block device. To create an ext2 filesystem on the mapped device, use the following command: mke2fs /dev/mapper/<name> To mount this filesystem on /mnt/test, use the following command: The directory /mnt/test must exist before executing this command. mount /dev/mapper/<name> /mnt/test C.4.6. Add the mapping information to /etc/crypttabIn order for the system to set up a mapping for the device, an entry must be present in the /etc/crypttab file. If the file doesn't exist, create it and change the owner and group to root (root:root) and change the mode to 0744. Add a line to the file with the following format: <name> <device> none The <device> field should be given in the form "UUID=<luks_uuid>", where <luks_uuid> is the LUKS uuid as given by the command cryptsetup luksUUID <device>. This ensures the correct device will be identified and used even if the device node (eg: /dev/sda5) changes. For details on the format of the /etc/crypttab file, read the crypttab(5) man page. C.4.7. Add an entry to /etc/fstabAdd an entry to /etc/fstab. This is only necessary if you want to establish a persistent association between the device and a mountpoint. Use the decrypted device, /dev/mapper/<name> in the /etc/fstab file. In many cases it is desirable to list devices in /etc/fstab by UUID or by a filesystem label. The main purpose of this is to provide a constant identifier in the event that the device name (eg: /dev/sda4) changes. LUKS device names in the form of /dev/mapper/luks-<luks_uuid> are based only on the device's LUKS UUID, and are therefore guaranteed to remain constant. This fact makes them suitable for use in /etc/fstab. For details on the format of the /etc/fstab file, read the fstab(5) man page. C.5. Common Post-Installation Tasks The following sections are about common post-installation tasks. C.5.1. Set a randomly generated key as an additional way to access an encrypted block deviceThese sections are about generating keys and adding keys. This will generate a 256-bit key in the file $HOME/keyfile. dd if=/dev/urandom of=$HOME/keyfile bs=32 count=1chmod 600 $HOME/keyfile C.5.1.2. Add the key to an available keyslot on the encrypted device cryptsetup luksAddKey <device> ~/keyfile C.5.2. Add a new passphrase to an existing device cryptsetup luksAddKey <device> After being prompted for any one of the existing passphrases for authentication, you will be prompted to enter the new passphrase. C.5.3. Remove a passphrase or key from a device cryptsetup luksRemoveKey <device> You will be prompted for the passphrase you wish to remove and then for any one of the remaining passphrases for authentication. LVM (Logical Volume Management) partitions provide a number of advantages over standard partitions. LVM partitions are formatted as physical volumes. One or more physical volumes are combined to form a volume group. Each volume group's total storage is then divided into one or more logical volumes. The logical volumes function much like standard partitions. They have a file system type, such as ext4, and a mount point. On most architectures, the boot loader cannot read LVM volumes. You must make a standard, non-LVM disk partition for your /boot partition. However, on System z, the zipl boot loader supports /boot on LVM logical volumes with linear mapping. To understand LVM better, imagine the physical volume as a pile of blocks. A block is simply a storage unit used to store data. Several piles of blocks can be combined to make a much larger pile, just as physical volumes are combined to make a volume group. The resulting pile can be subdivided into several smaller piles of arbitrary size, just as a volume group is allocated to several logical volumes. An administrator may grow or shrink logical volumes without destroying data, unlike standard disk partitions. If the physical volumes in a volume group are on separate drives or RAID arrays then administrators may also spread a logical volume across the storage devices. You may lose data if you shrink a logical volume to a smaller capacity than the data on the volume requires. To ensure maximum flexibility, create logical volumes to meet your current needs, and leave excess storage capacity unallocated. You may safely grow logical volumes to use unallocated space, as your needs dictate. By default, the installation process creates / and swap partitions within LVM volumes, with a separate /boot partition. When a computer running Linux is turned on, the operating system is loaded into memory by a special program called a boot loader. A boot loader usually exists on the system's primary hard drive (or other media device) and has the sole responsibility of loading the Linux kernel with its required files or (in some cases) other operating systems into memory. E.1. Boot Loaders and System ArchitectureEach architecture capable of running Red Hat Enterprise Linux uses a different boot loader. The following table lists the boot loaders available for each architecture: Table E.1. Boot Loaders by Architecture | Architecture | Boot Loaders |
|---|
| AMD AMD64 | GRUB | | IBM Power Systems | yaboot | | IBM System z | z/IPL | | x86 | GRUB |
This appendix discusses commands and configuration options for the GRUB boot loader included with Red Hat Enterprise Linux for the x86 architecture. The GRUB bootloader in Red Hat Enterprise Linux 6 supports only the ext2, ext3, and ext4 (recommended) file systems. You cannot use any other file system for /boot, such as Btrfs, XFS, or VFAT. The GNU GRand Unified Boot loader (GRUB) is a program which enables the selection of the installed operating system or kernel to be loaded at system boot time. It also allows the user to pass arguments to the kernel. E.2.1. GRUB and the boot process on BIOS-based x86 systemsGRUB loads itself into memory in the following stages: The Stage 1 or primary boot loader is read into memory by the BIOS from the MBR . The primary boot loader exists on less than 512 bytes of disk space within the MBR and is capable of loading either the Stage 1.5 or Stage 2 boot loader. BIOS cannot read partition tables or file systems. It initializes the hardware, reads the MBR, then depends entirely on the stage 1 bootloader to continue the boot process. The Stage 1.5 boot loader is read into memory by the Stage 1 boot loader, if necessary. Some hardware requires an intermediate step to get to the Stage 2 boot loader. This is sometimes true when the /boot/ partition is above the 1024 cylinder head of the hard drive or when using LBA mode. The Stage 1.5 boot loader is found either on the /boot/ partition or on a small part of the MBR and the /boot/ partition. The Stage 2 or secondary boot loader is read into memory. The secondary boot loader displays the GRUB menu and command environment. This interface allows the user to select which kernel or operating system to boot, pass arguments to the kernel, or look at system parameters. The secondary boot loader reads the operating system or kernel as well as the contents of /boot/sysroot/ into memory. Once GRUB determines which operating system or kernel to start, it loads it into memory and transfers control of the machine to that operating system.
The method used to boot Linux is called direct loading because the boot loader loads the operating system directly. There is no intermediary between the boot loader and the kernel. The boot process used by other operating systems may differ. For example, the Microsoft Windows operating system, as well as other operating systems, are loaded using chain loading. Under this method, the MBR points to the first sector of the partition holding the operating system, where it finds the files necessary to actually boot that operating system. GRUB supports both direct and chain loading boot methods, allowing it to boot almost any operating system. During installation, Microsoft's DOS and Windows installation programs completely overwrite the MBR, destroying any existing boot loaders. If creating a dual-boot system, it is best to install the Microsoft operating system first. E.2.2. GRUB and the boot process on UEFI-based x86 systemsGRUB loads itself into memory in the following stages: The UEFI-based platform reads the partition table on the system storage and mounts the EFI System Partition (ESP), a VFAT partition labeled with a particular globally unique identifier (GUID). The ESP contains EFI applications such as bootloaders and utility software, stored in directories specific to software vendors. Viewed from within the Red Hat Enterprise Linux 6 file system, the ESP is /boot/efi/, and EFI software provided by Red Hat is stored in /boot/efi/EFI/redhat/. The /boot/efi/EFI/redhat/ directory contains grub.efi, a version of GRUB compiled for the EFI firmware architecture as an EFI application. In the simplest case, the EFI boot manager selects grub.efi as the default bootloader and reads it into memory. If the ESP contains other EFI applications, the EFI boot manager might prompt you to select an application to run, rather than load grub.efi automatically. GRUB determines which operating system or kernel to start, loads it into memory, and transfers control of the machine to that operating system.
Because each vendor maintains its own directory of applications in the ESP, chain loading is not normally necessary on UEFI-based systems. The EFI boot manager can load any of the operating system bootloaders that are present in the ESP. GRUB contains several features that make it preferable to other boot loaders available for the x86 architecture. Below is a partial list of some of the more important features: GRUB provides a true command-based, pre-OS environment on x86 machines. This feature affords the user maximum flexibility in loading operating systems with specified options or gathering information about the system. For years, many non-x86 architectures have employed pre-OS environments that allow system booting from a command line. GRUB supports Logical Block Addressing (LBA) mode. LBA places the addressing conversion used to find files in the hard drive's firmware, and is used on many IDE and all SCSI hard devices. Before LBA, boot loaders could encounter the 1024-cylinder BIOS limitation, where the BIOS could not find a file after the 1024 cylinder head of the disk. LBA support allows GRUB to boot operating systems from partitions beyond the 1024-cylinder limit, so long as the system BIOS supports LBA mode. Most modern BIOS revisions support LBA mode. GRUB can read ext2 partitions. This functionality allows GRUB to access its configuration file, /boot/grub/grub.conf, every time the system boots, eliminating the need for the user to write a new version of the first stage boot loader to the MBR when configuration changes are made. The only time a user needs to reinstall GRUB on the MBR is if the physical location of the /boot/ partition is moved on the disk. For details on installing GRUB to the MBR, refer to Section E.3, "Installing GRUB".
If GRUB was not installed during the installation process, it can be installed afterward. Once installed, it automatically becomes the default boot loader. Before installing GRUB, make sure to use the latest GRUB package available or use the GRUB package from the installation DVD. For instructions on installing packages, refer to the chapter titled Package Management with RPM in the Red Hat Enterprise Linux Deployment Guide. Once the GRUB package is installed, open a root shell prompt and run the command /sbin/grub-install <location>, where <location> is the location that the GRUB Stage 1 boot loader should be installed. For example, the following command installs GRUB to the MBR of the master IDE device on the primary IDE bus: /sbin/grub-install /dev/hda
The next time the system boots, the GRUB graphical boot loader menu appears before the kernel loads into memory. GRUB cannot construct a software RAID. Therefore, the /boot directory must reside on a single, specific disk partition. The /boot directory cannot be striped across multiple disks, as in a level 0 RAID. To use a level 0 RAID on your system, place /boot on a separate partition outside the RAID. Similarly, because the /boot directory must reside on a single, specific disk partition, GRUB cannot boot the system if the disk holding that partition fails or is removed from the system. This is true even if the disk is mirrored in a level 1 RAID. The following Red Hat Knowledgebase article describes how to make the system bootable from another disk in the mirrored set: http://kbase.redhat.com/faq/docs/DOC-7095Note that these issues apply only to RAID that is implemented in software, where the individual disks that make up the array are still visible as individual disks on the system. These issues do not apply to hardware RAID where multiple disks are represented as a single device. One of the most important things to understand before using GRUB is how the program refers to devices, such as hard drives and partitions. This information is particularly important when configuring GRUB to boot multiple operating systems. When referring to a specific device with GRUB, do so using the following format (note that the parentheses and comma are very important syntactically): (<type-of-device><bios-device-number>,<partition-number>)
The <type-of-device> specifies the type of device from which GRUB boots. The two most common options are hd for a hard disk or fd for a 3.5 diskette. A lesser used device type is also available called nd for a network disk. Instructions on configuring GRUB to boot over the network are available online at http://www.gnu.org/software/grub/manual/. The <bios-device-number> is the BIOS device number. The primary IDE hard drive is numbered 0 and a secondary IDE hard drive is numbered 1. This syntax is roughly equivalent to that used for devices by the kernel. For example, the a in hda for the kernel is analogous to the 0 in hd0 for GRUB, the b in hdb is analogous to the 1 in hd1, and so on. The <partition-number> specifies the number of a partition on a device. Like the <bios-device-number>, most types of partitions are numbered starting at 0. However, BSD partitions are specified using letters, with a corresponding to 0, b corresponding to 1, and so on. The numbering system for devices under GRUB always begins with 0, not 1. Failing to make this distinction is one of the most common mistakes made by new users. To give an example, if a system has more than one hard drive, GRUB refers to the first hard drive as (hd0) and the second as (hd1). Likewise, GRUB refers to the first partition on the first drive as (hd0,0) and the third partition on the second hard drive as (hd1,2). In general the following rules apply when naming devices and partitions under GRUB: It does not matter if system hard drives are IDE or SCSI, all hard drives begin with the letters hd. The letters fd are used to specify 3.5 diskettes. To specify an entire device without respect to partitions, leave off the comma and the partition number. This is important when telling GRUB to configure the MBR for a particular disk. For example, (hd0) specifies the MBR on the first device and (hd3) specifies the MBR on the fourth device. If a system has multiple drive devices, it is very important to know how the drive boot order is set in the BIOS. This is a simple task if a system has only IDE or SCSI drives, but if there is a mix of devices, it becomes critical that the type of drive with the boot partition be accessed first.
E.4.2. File Names and BlocklistsWhen typing commands to GRUB that reference a file, such as a menu list, it is necessary to specify an absolute file path immediately after the device and partition numbers. The following illustrates the structure of such a command: (<device-type><device-number>,<partition-number>)</path/to/file>
In this example, replace <device-type> with hd, fd, or nd. Replace <device-number> with the integer for the device. Replace </path/to/file> with an absolute path relative to the top-level of the device. It is also possible to specify files to GRUB that do not actually appear in the file system, such as a chain loader that appears in the first few blocks of a partition. To load such files, provide a blocklist that specifies block by block where the file is located in the partition. Since a file is often comprised of several different sets of blocks, blocklists use a special syntax. Each block containing the file is specified by an offset number of blocks, followed by the number of blocks from that offset point. Block offsets are listed sequentially in a comma-delimited list. The following is a sample blocklist: 0+50,100+25,200+1
This sample blocklist specifies a file that starts at the first block on the partition and uses blocks 0 through 49, 100 through 124, and 200. Knowing how to write blocklists is useful when using GRUB to load operating systems which require chain loading. It is possible to leave off the offset number of blocks if starting at block 0. As an example, the chain loading file in the first partition of the first hard drive would have the following name: (hd0,0)+1
The following shows the chainloader command with a similar blocklist designation at the GRUB command line after setting the correct device and partition as root: chainloader +1
E.4.3. The Root File System and GRUBThe use of the term root file system has a different meaning in regard to GRUB. It is important to remember that GRUB's root file system has nothing to do with the Linux root file system. The GRUB root file system is the top level of the specified device. For example, the image file (hd0,0)/grub/splash.xpm.gz is located within the /grub/ directory at the top-level (or root) of the (hd0,0) partition (which is actually the /boot/ partition for the system). Next, the kernel command is executed with the location of the kernel file as an option. Once the Linux kernel boots, it sets up the root file system that Linux users are familiar with. The original GRUB root file system and its mounts are forgotten; they only existed to boot the kernel file. GRUB features three interfaces which provide different levels of functionality. Each of these interfaces allows users to boot the Linux kernel or another operating system. The interfaces are as follows: The following GRUB interfaces can only be accessed by pressing any key within the three seconds of the GRUB menu bypass screen. - Menu Interface
This is the default interface shown when GRUB is configured by the installation program. A menu of operating systems or preconfigured kernels are displayed as a list, ordered by name. Use the arrow keys to select an operating system or kernel version and press the Enter key to boot it. If you do nothing on this screen, then after the time out period expires GRUB will load the default option. Press the e key to enter the entry editor interface or the c key to load a command line interface. - Menu Entry Editor Interface
To access the menu entry editor, press the e key from the boot loader menu. The GRUB commands for that entry are displayed here, and users may alter these command lines before booting the operating system by adding a command line (o inserts a new line after the current line and O inserts a new line before it), editing one (e), or deleting one (d). After all changes are made, the b key executes the commands and boots the operating system. The Esc key discards any changes and reloads the standard menu interface. The c key loads the command line interface. - Command Line Interface
The command line interface is the most basic GRUB interface, but it is also the one that grants the most control. The command line makes it possible to type any relevant GRUB commands followed by the Enter key to execute them. This interface features some advanced shell-like features, including Tab key completion based on context, and Ctrl key combinations when typing commands, such as Ctrl+a to move to the beginning of a line and Ctrl+e to move to the end of a line. In addition, the arrow, Home, End, and Delete keys work as they do in the bash shell.
E.5.1. Interfaces Load OrderWhen GRUB loads its second stage boot loader, it first searches for its configuration file. Once found, the menu interface bypass screen is displayed. If a key is pressed within three seconds, GRUB builds a menu list and displays the menu interface. If no key is pressed, the default kernel entry in the GRUB menu is used. If the configuration file cannot be found, or if the configuration file is unreadable, GRUB loads the command line interface, allowing the user to type commands to complete the boot process. If the configuration file is not valid, GRUB prints out the error and asks for input. This helps the user see precisely where the problem occurred. Pressing any key reloads the menu interface, where it is then possible to edit the menu option and correct the problem based on the error reported by GRUB. If the correction fails, GRUB reports an error and reloads the menu interface. GRUB allows a number of useful commands in its command line interface. Some of the commands accept options after their name; these options should be separated from the command and other options on that line by space characters. The following is a list of useful commands: boot - Boots the operating system or chain loader that was last loaded.
chainloader </path/to/file> - Loads the specified file as a chain loader. If the file is located on the first sector of the specified partition, use the blocklist notation, +1, instead of the file name.
The following is an example chainloader command: chainloader +1
displaymem - Displays the current use of memory, based on information from the BIOS. This is useful to determine how much RAM a system has prior to booting it.
initrd </path/to/initrd> - Enables users to specify an initial RAM disk to use when booting. An initrd is necessary when the kernel needs certain modules in order to boot properly, such as when the root partition is formatted with the ext3 or ext4 file system.
The following is an example initrd command: initrd /initrd-2.6.8-1.523.img
install <stage-1> <install-disk> <stage-2> p config-file - Installs GRUB to the system MBR.
<stage-1>(hd0,0)/grub/stage1.
<install-disk>(hd0).
<stage-2>(hd0,0)/grub/stage2.
p <config-file>install command to look for the menu configuration file specified by <config-file>(hd0,0)/grub/grub.conf.
The install command overwrites any information already located on the MBR. kernel </path/to/kernel> <option-1> <option-N> ... - Specifies the kernel file to load when booting the operating system. Replace </path/to/kernel> with an absolute path from the partition specified by the root command. Replace <option-1> with options for the Linux kernel, such as root=/dev/VolGroup00/LogVol00 to specify the device on which the root partition for the system is located. Multiple options can be passed to the kernel in a space separated list.
The following is an example kernel command: kernel /vmlinuz-2.6.8-1.523 ro root=/dev/VolGroup00/LogVol00
The option in the previous example specifies that the root file system for Linux is located on the hda5 partition. root (<device-type><device-number>,<partition>) - Configures the root partition for GRUB, such as (hd0,0), and mounts the partition.
The following is an example root command: root (hd0,0)
rootnoverify (<device-type><device-number>,<partition>) - Configures the root partition for GRUB, just like the root command, but does not mount the partition.
Other commands are also available; type help --all for a full list of commands. For a description of all GRUB commands, refer to the documentation available online at http://www.gnu.org/software/grub/manual/. E.7. GRUB Menu Configuration FileThe configuration file ( /boot/grub/grub.conf), which is used to create the list of operating systems to boot in GRUB's menu interface, essentially allows the user to select a pre-set group of commands to execute. The commands given in Section E.6, "GRUB Commands" can be used, as well as some special commands that are only available in the configuration file. E.7.1. Configuration File StructureThe GRUB menu interface configuration file is /boot/grub/grub.conf. The commands to set the global preferences for the menu interface are placed at the top of the file, followed by stanzas for each operating kernel or operating system listed in the menu. The following is a very basic GRUB menu configuration file designed to boot either Red Hat Enterprise Linux or Microsoft Windows Vista: default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Server (2.6.32.130.el6.i686) root (hd0,0) kernel /boot/vmlinuz-2.6.32.130.el6.i686 ro root=LABEL=/1 rhgb quiet initrd /boot/initrd-2.6.32.130.el6.i686.img# section to load Windows title Windows rootnoverify (hd0,0) chainloader +1 This file configures GRUB to build a menu with Red Hat Enterprise Linux as the default operating system and sets it to autoboot after 10 seconds. Two sections are given, one for each operating system entry, with commands specific to the system disk partition table. Note that the default is specified as an integer. This refers to the first title line in the GRUB configuration file. For the Windows section to be set as the default in the previous example, change the default=0 to default=1. Configuring a GRUB menu configuration file to boot multiple operating systems is beyond the scope of this chapter. Consult Section E.9, "Additional Resources" for a list of additional resources. E.7.2. Configuration File DirectivesThe following are directives commonly used in the GRUB menu configuration file: chainloader </path/to/file> - Loads the specified file as a chain loader. Replace </path/to/file> with the absolute path to the chain loader. If the file is located on the first sector of the specified partition, use the blocklist notation, +1.
color <normal-color> <selected-color> - Allows specific colors to be used in the menu, where two colors are configured as the foreground and background. Use simple color names such as red/black. For example:
color red/black green/blue
default=<integer> - Replace <integer> with the default entry title number to be loaded if the menu interface times out.
fallback=<integer> - Replace <integer> with the entry title number to try if the first attempt fails.
hiddenmenu - Prevents the GRUB menu interface from being displayed, loading the default entry when the timeout period expires. The user can see the standard GRUB menu by pressing the Esc key.
initrd </path/to/initrd> - Enables users to specify an initial RAM disk to use when booting. Replace </path/to/initrd> with the absolute path to the initial RAM disk.
kernel </path/to/kernel> <option-1> <option-N> - Specifies the kernel file to load when booting the operating system. Replace </path/to/kernel> with an absolute path from the partition specified by the root directive. Multiple options can be passed to the kernel when it is loaded.
These options include: rhgb (Red Hat graphical boot) - displays an animation during the boot process, rather than lines of text.
quiet - suppresses all but the most important messages in the part of the boot sequence before the Red Hat graphical boot animation begins.
password=<password> - Prevents a user who does not know the password from editing the entries for this menu option.
Optionally, it is possible to specify an alternate menu configuration file after the password=<password> directive. In this case, GRUB restarts the second stage boot loader and uses the specified alternate configuration file to build the menu. If an alternate menu configuration file is left out of the command, a user who knows the password is allowed to edit the current configuration file. For more information about securing GRUB, refer to the chapter titled Workstation Security in the Red Hat Enterprise Linux Security Guide. map - Swaps the numbers assigned to two hard drives. For example:
map (hd0) (hd3)map (hd3) (hd0) assigns the number 0 to the fourth hard drive, and the number 3 to the first hard drive. This option is especially useful if you configure your system with an option to boot a Windows operating system, because the Windows boot loader must find the Windows installation on the first hard drive. For example, if your Windows installation is on the fourth hard drive, the following entry in grub.conf will allow the Windows boot loader to load Windows correctly: title Windowsmap (hd0) (hd3)map (hd3) (hd0)rootnoverify (hd3,0)chainloader +1 root (<device-type><device-number>,<partition>) - Configures the root partition for GRUB, such as (hd0,0), and mounts the partition. To specify the boot drive selected by the EFI boot manager, the syntax is <device-type>,<partition>, such as (bd,1).
rootnoverify (<device-type><device-number>,<partition>) - Configures the root partition for GRUB, just like the root command, but does not mount the partition.
timeout=<integer> - Specifies the interval, in seconds, that GRUB waits before loading the entry designated in the default command.
splashimage=<path-to-image> - Specifies the location of the splash screen image to be used when GRUB boots.
title group-title - Specifies a title to be used with a particular group of commands used to load a kernel or operating system.
To add human-readable comments to the menu configuration file, begin the line with the hash mark character (#). E.8. Changing Runlevels at Boot TimeUnder Red Hat Enterprise Linux, it is possible to change the default runlevel at boot time. To change the runlevel of a single boot session, use the following instructions: When the GRUB menu bypass screen appears at boot time, press any key to enter the GRUB menu (within the first three seconds). Press the a key to append to the kernel command. Add <space><runlevel> at the end of the boot options line to boot to the desired runlevel. For example, the following entry would initiate a boot process into runlevel 3: grub append> ro root=/dev/VolGroup00/LogVol00 rhgb quiet 3
E.9. Additional ResourcesThis chapter is only intended as an introduction to GRUB. Consult the following resources to discover more about how GRUB works. E.9.1. Installed Documentation/usr/share/doc/grub-<version-number>/ - This directory contains good information about using and configuring GRUB, where <version-number> corresponds to the version of the GRUB package installed.
info grub - The GRUB info page contains a tutorial, a user reference manual, a programmer reference manual, and a FAQ document about GRUB and its usage.
|
| |
