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.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.