Chapter 35. Installation and Booting
Installation fails with a traceback when specifying %packages --nobase --nocore in a Kickstart file
Using a Kickstart file which contains the
%packages
section and specifies the --nobase
and --nocore
options at the same time causes the installation to fail with a traceback message due to the yum-langpacks package missing.
To work around this problem, add the yum-langpacks package within the
%packages
section when using %packages --nobase --nocore
in your Kickstart file.
Installation can not proceed if a root password specified in Kickstart does not pass policy requirements
If you use a Kickstart file that defines a root password and the password does not fullfill requirements for the security policy selected in the Security Policy spoke, you will be unable to complete the installation. The
Begin Installation
button will be grayed out, and it is not possible to change the root password manually before pressing this button.
To work around this problem, make sure that your Kickstart file uses a sufficiently strong password that passes requirements defined by the selected security policy.
Rescue mode fails to detect and mount root volume on Btrfs
The installer rescue mode (accessed from the installation media boot menu or using the
inst.rescue
boot option) can not detect an existing system with the /
(root) directory placed on a Btrfs subvolume. Instead, an error message saying 'You don't have any linux partitions.' is displayed.
To work around this problem, enter the shell and mount the root volume manually.
Wrong window title in Initial Setup
The Initial Setup tool, which is automatically displayed after the first post-installation reboot and which allows you to configure settings like network connections and to register your system, displays the string
__main__.py
in the window title.
This is a cosmetic problem and has no negative impact on usability.
Reinstalling on an FBA DASD on IBM System z causes the installer to crash
When reinstalling Red Hat Enterprise Linux 7 on IBM System z with a Fixed Block Architecture (FBA) DASD, the installer will crash due to incomplete support for these devices.
To work around this problem, ensure that any FBA DASDs are not present during the installation by placing them on the device ignore list. This should be done before launching the installer. From a root shell, use the
chccwdev
command followed by the cio_ignore
command to manually switch devices offline and then add them to the device ignore list.
Alternatively, you can remove all FBA DASD device IDs from the CMS configuration file or the parameter file instead of using these commands before beginning the installation.
HyperPAV aliases are not available after installation on IBM System z
A known issue prevents DASDs configured as HyperPAV aliases from being automatically attached to the system after the installation finishes. These storage devices are available at the Installation Destination screen during installation, but they are not immediately accessible after you finish installing and reboot.
To fix this problem temporarily (until the next reboot), remove these devices from the device blacklist using the
chccwdev
command:
# chccwdev -e <devnumber>
To make the HyperPAV aliases available persistently across reboots, add their device numbers into the
/etc/dasd.conf
configuration file.
You can use the
lsdasd
command to verify that these devices are available.
Generated anaconda-ks.cfg file on IBM System z can not be used to reinstall the system
The
anaconda-ks.cfg
file, which is a Kickstart file generated during system installation and which contains all selections made during the install process, represents disk sizes as decimal numbers on IBM System z DASDs. This is because DASDs report a 4KiB alignment, which makes the calculated disk sizes incorrect as they are recorded in the Kickstart file, since only integer values are accepted. Therefore, it is not possible to re-use the generated Kickstart file to reproduce the installation.
Using the
anaconda-ks.cfg
file on IBM System z to reinstall the system requires you to manually change all decimal values within to integers.
Possible NetworkManager error message during installation
When installing the system, the following error message can be displayed and logged:
ERR NetworkManager: <error> [devices/nm-device.c:2590] activation_source_schedule(): (eth0): activation stage already scheduled
The error message should not prevent the installation from completing.
Package libocrdma is missing from the InfiniBand Support package group
The libocrdma package is not included in the default package set of the InfiniBand Support group. Consequently, when users select the InfiniBand Support group and are expecting RDMA over Converged Ethernet (RoCE) to work on Emulex OneConnect adapters, the necessary driver, libocrdma, is not installed by default.
On first boot, the user can manually install the missing package by issuing this command:
# yum install libocrdma
Alternatively, add the libocrdma package to the
%packages
section of your Kickstart file.
As a result, the user will now be able to use the Emulex OneConnect devices in RoCE mode.
Insufficient size of the /boot partition may prevent the system from upgrading
The /boot partition, which contains installed kernels and initial ram disks, may become full if multiple kernels and additional packages such as kernel-debug are installed. This is caused by the default size of this partition being set to 500 MB during installation, and prevents the system from being upgraded.
As a workaround, use
yum
to remove older kernels if you do not need them. If you are installing a new system, you should also consider this possibility, and set the /boot partition to a larger size (for example 1 GB) instead of the default (500 MB).
Installation on multipath devices fails if one or more disks are missing a label
When installing on multipath devices, the installer may display an error dialog if it fails to read one or more disks which are a member of the multipath. This problem is caused by one or more disks missing a disk label, and the installation can not proceed if it occurs.
To work around this problem, create disk labels on all disks which are part of the multipath device you are using during the installation.
Static IPv4 configuration in Kickstart is overwritten if a host name is defined in %pre script
When defining a host name in the
%pre
section of a Kickstart file, a network
command that only sets host name ("network --hostname=hn") is considered as a device configuration with default --bootproto value ("dhcp") and default --device
value ("link", which means the first device with link found). The Kickstart then behaves as if network --hostname=hn --device=link
was used.
If the device considered as default for the
--device
option (the first device with link found) has already been configured to use static IPv4 configuration (for example with the preceding network
command), the configuration is overriden by the IPv4 DHCP implied by the --hostname
option.
To work around this problem, make sure that the
network
command which defines the host name is used first, and the second network
command which would normally be overridden is used afterwards.
In cases where the
network
command defining a host name is the only such command in the Kickstart file, add a --device
option to it with a non-existing interface (for example, network --hostname=hn --device=x
).
Using the realm command in Kickstart causes the installer to crash
A known issue prevents the
realm
command from being used in Kickstart files. Attempting to join an Active Directory or Identity Management domain during the installation using this command causes the installer to crash.
To work around this problem, you can either wait until the installation finishes and join a domain manually afterwards, or you can add the
realm join <realm name>
command to the Kickstart file's %post
section. See the realm(8)
man page for information joining a domain using the command line.
Installer built-in help is not updated during system upgrade
When upgrading from Red Hat Enterprise Linux 7.1 to version 7.2, the built-in help for the Anaconda installer (the anaconda-user-help package) is not upgraded due to a significant change in packaging.
To work around this problem, use
yum
to remove the anaconda-user-help package before performing the upgrade, and install it again after you finish upgrading to Red Hat Enterprise Linux 7.2.
Incorrect ordering of boot menu entries generated by grubby
The
grubby
tool, which is used to modify and update the GRUB2 boot loader configuration files, may add debug boot menu entries at the top of the list when generating the boot menu configuration file. These debug menu entries then cause normal entries to be pushed down, although they are still highlighted and selected by default.
Using multiple driver update images at the same time only applies the last one specified
When attempting to perform a driver update during the installation using the
inst.dd=/dd.img
boot option and specifying it more than once to load multiple driver update images, Anaconda will ignore all instances of the parameter except the last one.
To work around this problem, you can:
* Install additional drivers after the installation if possible
* Use alternate means to specify a driver update image, such as the
driverdisk
Kickstart command
* Combine multiple driver update images into a single one
Installer crashes when it detects LDL-formatted DASDs
The installer crashes whenever it detects the LDL (Linux Disk Layout) format on one or more DASDs on IBM System z. The crash is caused by a race condition in the
libparted
library and happens even if these DASDs are not selected as installation targets. Other architectures are not affected by this issue.
If LDL DASDs are to be used during installation, users should manually reformat each LDL DASD as CDL (Compatible Disk Layout) using the
dasdfmt
command in a root shell before launching the installer.
If LDL DASDs are present on a system and a user does not wish to utilize them during installation, they should be placed on the device ignore list for the duration of the installation process. This should be done before launching the installer. From a root shell, users should use the
chccwdev
command followed by the cio_ignore
command to manually switch devices offline and then add them to the device ignore list.
Alternatively, you can remove all LDL DASD device IDs from the CMS configuration file or the parameter file instead of using these commands before beginning the installation.
Kernel panic on reboot after upgrading kernel and redhat-release packages
Installing redhat-release-server-7.2-9.el7 and a kernel package in the same Yum transaction leads to a missing
initrd
line in the new kernel's menu entry in GRUB2 configuration. Attempting to boot using the latest installed kernel then causes a kernel panic due to missing initrd. This issue usually appears while upgrading your system from an earlier minor release to Red Hat Enterprise Linux 7.2 using yum update
.
To work around this problem, make sure to upgrade the redhat-release-server and kernel packages in separate Yum transactions. Alternatively, you can locate the new kernel's menu entry in the GRUB2 configuration file (
/boot/grub2/grub.cfg
on BIOS systems and /boot/efi/EFI/redhat/grub.cfg
on UEFI systems) and add the initrd manually.
The initrd configuration line will look similar to
initrd /initramfs-3.10.0-327.el7.x86_64.img
. Make sure the file name matches the kernel (vmlinuz) configured within the same menu entry and that the file exists /boot
directory. Use older menu entries for reference.
Initial Setup may start in text mode even if a graphical environment is installed
The Initial Setup utility, which starts after installation finishes and the installed system is booted for the first time, may in some cases start in text mode on systems where a graphical environment is available and the graphical version of Initial Setup should start. This is caused by both the graphical and text mode services for Initial Setup being enabled at the same time.
To work around this problem, you can use a Kickstart file during the installation and include a
%post
section to disable the version of Initial Setup which you do not want to run.
To make sure that the graphical variant of Initial Setup runs after installation, use the following
%post
section:
%post systemctl disable initial-setup-text.service systemctl enable initial-setup-graphical.service %end
If you want to enable the text mode variant of Initial Setup, switch the
enable
and disable
commands in order to disable the graphical service and enable text mode.
Links to non-root file systems in /lib/
and /lib64/
are removed by ldconfig.service
Red Hat Enterprise Linux 7.2 introduced
ldconfig.service
, which is run at an early stage of the boot process, before non-root file systems are mounted. When ldconfig.service
is run, links in the /lib/
and /lib64/
directories are removed if they point to file systems which are not yet mounted. To work around this problem, disable ldconfig.service
with the command systemctl mask ldconfig
, so these symbolic links are no longer removed, and the system boots as expected.
Daemons using IPC terminate unexpectedly after update to Red Hat Enterprise Linux 7.2
A new
systemd
feature was introduced in Red Hat Enterprise Linux 7.2: cleanup of all allocated inter-process communication (IPC) resources with the last session a user finishes. A session can be an administrative cron
job or an interactive session. This behavior can cause daemons running under the same user, and using the same resources, to terminate unexpectedly. To work around this problem, edit the file /etc/systemd/logind.conf
and add the following line:
RemoveIPC=no
Then, execute the following command, so that the change is put into effect:
systemctl restart systemd-logind.service
After performing these steps, daemons no longer crash in the described situation.