Chapter 9. Installation and Booting

Fixed network setup in initrd if network configuration is provided in Kickstart

Previously, the installer was failing to set up or reconfigure network interfaces in initrd, if these interfaces were defined in Kickstart files. This could cause the installation to fail and enter emergency mode if network access was required by other commands in the Kickstart file.
This issue is now resolved and Anaconda now properly handles network configuration from Kickstart files in initrd, early in the boot process.

Anaconda now supports creating cached logical volumes

The installer now supports creating cached LVM logical volumes and installing the system onto those volumes.
Currently, this approach is only supported in Kickstart. To create a cached logical volume, use the new --cachepvs=, --cachesize=, and --cachemode= options of the logvol Kickstart command.
See the Red Hat Enterprise Linux 7 Installation Guide for detailed information about these new options.

Improved sorting of GRUB2 boot menu

An issue with the sorting mechanism used by the grub2-mkconfig command could cause the grub.cfg configuration file to be generated with available kernels sorted incorrectly.
GRUB2 now uses the rpmdevtools package to sort available kernels and the configuration file is being generated correctly with the most recent kernel version listed at the top.

Anaconda now properly reverts disk actions when disk selection changes

Previously, Anaconda and Blivet did not properly revert actions scheduled on disks when disk selection changed, causing various issues. With this update, Anaconda has been fixed to create a snapshot of the original storage configuration and return to it when disk selection changes, thus completely reverting all actions scheduled for disks.

Improved detection of device-mapper disk names

In the previous release of Red Hat Enterprise Linux 7, it was possible for the installer to crash when installing on disks which previously contained LVM logical volumes and the metadata for those volumes was still present. The installer could not recognize correct device-mapper names and the process of creating new LVM logical volumes would fail.
The method used to obtain device-mapper device names has been updated and installation on disks which contain existing LVM metadata is now more reliable.

Fixed handling of PReP Boot during partitioning

In some circumstances, the PReP Boot partition on IBM Power Systems could be set to an invalid size during custom partitioning. In that situation, removing any partition caused the installer to crash.
Checks are now implemented in anaconda to ensure that the partition is always sized correctly between 4096 KiB and 10 MiB. Additionally, it is no longer necessary to change the format of the PReP Boot partition in order to change its size.

EFI partitions on RAID1 devices

EFI System Partitions may now be created on a RAID1 device, this is to enable system recovery when one boot disk fails. However, because the system is only guaranteed to discover one EFI System Partition, if the volume of the ESP that is discovered by the firmware becomes corrupt (but still appears to be a valid ESP), and both Boot#### and BootOrder also become corrupt, then the boot order will not be rebuilt automatically. In this case, the system should still boot manually from the second disk.

Text mode installation no longer crashes during network configuration

Previously, in the Network Configuration screen in the interactive text mode installer, using a space when specifying nameservers caused the installer to crash.
Anaconda now handles spaces in nameserver definitions in text mode correctly and the installer no longer crashes if a space is used to separate nameserver addresses.

Rescue mode screens on IBM System z are no longer cut off

Previously, the second and third screen in rescue mode on IBM System z servers were being displayed improperly and parts of the interface were cut off. Rescue mode on this architecture has been improved and all screens now function correctly.

OpenSCAP add-on in Anaconda

It is now possible to apply Security Content Automation Protocol (SCAP) content during the installation process. This new installer add-on provides a reliable and easy way to configure a security policy without having to rely on custom scripts.
This add-on provides a new Kickstart section ("%addon org_fedora_oscap") as well as a new screen in the graphical user interface during an interactive installation. All three parts are documented in the Red Hat Enterprise Linux 7 Installation Guide.
Applying a security policy during installation will perform various changes during and immediately after the installation, depending on which policy you enable. If a profile is selected, the openscap-scanner package (an OpenSCAP compliance scanning tool) is added to your package selection and an initial compliance scan is performed after the installation finishes. Results of this scan are saved into /root/openscap_data.
Several profiles are provided on installation media by the scap-security-guide package. You can also load other content as a datastream, archive, or an RPM package from an HTTP, HTTPS or FTP server if needed.
Note that applying a security policy is not necessary on all systems. This add-on should only be used when a specific policy is mandated by your organization's rules or government regulations, otherwise the add-on can be left in its default state which does not apply any security policy.

Anaconda no longer times out when waiting for a Kickstart file on a CD or DVD

Previously, if Anaconda was configured to load a Kickstart file from optical media using the inst.ks=cdrom:/ks.cfg command, and the system was also booted from a CD or DVD, the installer only waited 30 seconds for the user to swap the disk. After this time window passed, the system entered emergency mode.
With this update, Anaconda has been modified to never time out when waiting for the user to provide a Kickstart file on a CD or DVD. If the inst.ks=cdrom boot options is used and the Kickstart file is not detected, Anaconda displays a prompt and waits until the user provides the file or reboots.