System Booting

Grand Unified Bootloader (GRUB)

Settings

Boot files

commands

protect boot configuration access

add an OS entry

During the boot process, everything is logged to the /var/log/dmesg file. You can also use the dmesg command to query information about the boot process after the system has booted. When the system’s drivers are in place, the kernel executes the /sbin/init program.

The init program is the first process created by the kernel. It is responsible for the rest of the boot process and setting up the environment for the user. First, it consults the /etc/inittab file, which defines how the rest of the boot process will go. The /etc/inittab file lists the default runlevel to boot into and the system initialization script (/etc/rc.d/rc.sysinit). I describe what a runlevel is and how it is used later in this chapter. Let’s look at the /etc/inittab file to see what the init process goes through:

Grub

Files and Directories

Understanding GRUB 2

The GRUB 2 boot loader makes sure that you can boot Linux. GRUB 2 is installed in the boot sector of your server’s hard drive and is configured to load a Linux kernel and the initramfs:

■ The kernel is the heart of the operating system, allowing users to interact with the hardware that is installed in the server.

■ The initramfs contains drivers that are needed to start your server. It contains a mini file system that is mounted during boot. In it are kernel modules that are needed during the rest of the boot process (for example, the LVM modules and SCSI modules for accessing disks that are not supported by default).

Normally, GRUB 2 works just fine and does not need much maintenance. In some cases, though, you might have to change its configuration. To apply changes to the GRUB 2 configuration, the starting point is the /etc/default/grub file. In this file, you’ll find options that tell GRUB what to do and how to do it.

Apart from the configuration in /etc/default/grub, there are a few configuration files in /etc/grub.d. In these files, you’ll find rather complicated shell code that tells GRUB what to load and how to load it. You typically do not have to modify it. You also will not need to modify anything if you want to make it possible to select from different kernels while booting. GRUB 2 picks up new kernels automatically and adds them to the boot menu automatically, so nothing has to be added manually.

Based on the configuration files mentioned previously, the main configuration file / boot/grub2/grub.cfg is created. Even if this looks like a configuration file that can be manually modified, you should never do that, because it will get overwritten at some point. This will happen, for instance, after updating the kernel. The RPM from which the kernel is updated will run a post-installation script that regenerates

Modifying Default GRUB 2 Boot Options

To apply modifications to the GRUB 2 boot loader, the file /etc/default/grub is your entry point; do not change the contents of the /boot/grub2/grub.cfg configuration file directly.

The most important line in this file is GRUB_CMDLINE_LINUX, which defines how the Linux kernel should be started.

In this line, you can apply permanent fixes to the GRUB 2 configuration. Some likely candidates for removal are the options rhgb and quiet . These options tell the kernel to hide all output while booting. That is nice to hide confusing messages for end users, but if you are a server administrator, you probably just want to remove these options.

PROTECTING GRUB 2 WITH A PASSWORD

• Password is required for modifying menu entries but not for booting existing menu entries;
• Password is required for modifying menu entries and for booting one, several, or all menu entries.

Configuring GRUB 2 to Require a Password only for Modifying Entries

To require password authentication for modifying GRUB 2 entries, follow these steps: Run the grub2-setpassword command as root:

Following this procedure creates a /boot/grub2/user.cfg file that contains the hash of the password. The user for this password, root, is defined in the /boot/grub2/grub.cfg file. With this change, modifying a boot entry during booting requires you to specify the root user name and your password.

Configuring GRUB 2 to Require a Password for Modifying and Booting Entries (RHEL 7)

menuentry 'Red Hat Enterprise Linux Server (3.10.0-327.18.2.rt56.223.el7_2.x86_64) 7.2 (Maipo)' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-327.el7.x86_64-advanced-c109825c-de2f-4340-a0ef-4f47d19fe4bf' {
        load_video
        set gfxpayload=keep

Manual changes to the /boot/grub2/grub.cfg persist when new kernel versions are installed, but are lost when re-generating grub.cfg using the grub2-mkconfig command. Therefore, to retain password protection, use the above procedure after every use of grub2-mkconfig.

If you delete the --unrestricted parameter from every menu entry in the /boot/grub2/grub.cfg file, all newly installed kernels will have menu entry created without --unrestricted and hence automatically inherit the password protection. Passwords Set Before Updating to Red Hat Enterprise Linux 7.2

The grub2-setpassword tool was added in Red Hat Enterprise Linux 7.2 and is now the standard method of setting GRUB 2 passwords. This is in contrast to previous versions of Red Hat Enterprise Linux, where boot entries needed to be manually specified in the /etc/grub.d/40_custom file, and super users - in the /etc/grub.d/01_users file.

Booting entries without the --unrestricted parameter requires the root password. However, GRUB 2 also enables creating additional non-root users that can boot such entries without providing a password. Modifying the entries still requires the root password. For information on creating such users, see the GRUB 2 Manual.

Travailler avec des cibles Systemd

Les versions précédentes de Red Hat Enterprise Linux, qui étaient distribuées avec SysV init ou Upstart, implémentaient un ensemble prédéfini de niveaux d'exécution (« runlevels ») qui représentaient des modes d'opération spécifiques. Ces niveaux d'exécution étaient numérotés de 0 à 6 et étaient définis par une sélection de services système à exécuter lorsqu'un niveau d'exécution particulier était activé par l'administrateur systèmes. Sur Red Hat Enterprise Linux 7, le concept des niveaux d'exécution a été remplacé par les cibles Systemd.

Les cibles Systemd sont représentées par des unités de cible (« target units »). Les unités de cible se terminent par l'extension de fichier .target et leur unique but consiste à regrouper d'autres unités Systemd dans une chaîne de dépendances. Par exemple, l'unité graphical.target, qui est utilisée pour lancer une session graphique, lance des services système comme le gestionnaire d'affichage GNOME (gdm.service) ou le services des comptes (accounts-daemon.service) et active également l'unité multi-user.target. De manière similaire, l'unité multi-user.target lance d'autres services système essentiels, tels que NetworkManager (NetworkManager.service) ou D-Bus (dbus.service) et active une autre unité cible nommée basic.target.

Red Hat Enterprise Linux 7 est distribué avec un certain nombre de cibles prédéfinies plus ou moins similaires à l'ensemble standard des niveaux d'exécution des versions précédentes de ce système. Pour des raisons de compatibilité, des alias sont également fournis pour ces cibles, et les font correspondre directement aux niveaux d'exécution SysV. La Tableau 9.6, « Comparaison des niveaux d'exécution SysV avec les cibles Systemd » offre une liste complète des niveaux d'exécution SysV et des cibles Systemd correspondantes.

Afficher la cible par défaut

Cette commande résout le lien symbolique situé sur /etc/systemd/system/default.target et affiche le résultat.

~]$ systemctl get-default
graphical.target

Modifier la cible par défaut