Upgrading from RHEL 7 to RHEL 8
Instructions for an in-place upgrade from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8
Abstract
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
Providing feedback on Red Hat documentation
We appreciate your input on our documentation. Please let us know how we could make it better. To do so:
For simple comments on specific passages:
- Make sure you are viewing the documentation in the Multi-page HTML format. In addition, ensure you see the Feedback button in the upper right corner of the document.
- Use your mouse cursor to highlight the part of text that you want to comment on.
- Click the Add Feedback pop-up that appears below the highlighted text.
- Follow the displayed instructions.
For submitting more complex feedback, create a Bugzilla ticket:
- Go to the Bugzilla website.
- As the Component, use Documentation.
- Fill in the Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation.
- Click Submit Bug.
Chapter 1. Planning an upgrade
An in-place upgrade is the recommended and supported way to upgrade your system to the next major version of RHEL.
You should consider the following before upgrading to RHEL 8:
Operating system - The operating system is upgraded by the
Leapp
utility under the following conditions:The Server variant installed of the latest available RHEL 7 version, which currently is:
- RHEL 7.9 on the 64-bit Intel, IBM POWER 8 (little endian), and 64-bit IBM Z architectures
- RHEL 7.6 on architectures that require kernel version 4.14: IBM POWER 9 (little endian) or 64-bit IBM Z (Structure A)
RHEL 7.7 when on SAP HANA on the 64-bit Intel architecture
See Supported in-place upgrade paths for Red Hat Enterprise Linux for more information.
- Minimum hardware requirements for RHEL 8 met
- Access to up-to-date RHEL 7.9 and RHEL 8.2 content provided; see Preparing a RHEL 7 system for the upgrade, step 1 for details.
-
Applications - You can migrate applications installed on your system using
Leapp
. However, in certain cases, you have to create custom actors, which specify actions to be performed byLeapp
during the upgrade, for example, reconfiguring an application or installing a specific hardware driver. For more information, see Handling the migration of your custom and third-party applications. Note that custom actors are unsupported by Red Hat. Security - You should evaluate this aspect before the upgrade and take additional steps when the upgrade process completes. Consider especially the following:
- Before the upgrade, define the security standard your system needs to comply with and understand the security changes in RHEL 8.
-
During the upgrade process, the
Leapp
utility sets SELinux mode to permissive. - In-place upgrades of systems in FIPS mode are not supported.
- After the upgrade is finished, re-evaluate and re-apply your security policies. For information about applying security policies that have been disabled during the upgrade or newly introduced in RHEL 8, see Applying security policies.
- Storage and file systems - You should always back up your system prior to upgrading. For example, you can use the Relax-and-Recover (ReaR) utility, LVM snapshots, RAID splitting, or a virtual machine snapshot.
- Downtime - The upgrade process can take from several minutes to several hours.
- Satellite - If you manage your hosts through Satellite, you can upgrade multiple hosts simultaneously from RHEL 7 to RHEL 8 using the Satellite web UI. For more information, see Upgrading Hosts from RHEL 7 to RHEL 8.
- SAP HANA - If you are using SAP HANA, follow How to in-place upgrade SAP environments from RHEL 7 to RHEL 8 instead. Note that the upgrade path for RHEL with SAP HANA might differ.
- Public Clouds - The in-place upgrade is supported for on-demand instances on Amazon Web Services (AWS) and Microsoft Azure, using Red Hat Update Infrastructure (RHUI).
Known limitations - Notable known limitations of
Leapp
currently include:- Encryption of the whole disk or a partition, or file-system encryption currently cannot be used on a system targeted for an in-place upgrade.
- No network-based multipath and no kind of network storage mount can be used as a system partition (for example, iSCSI, or NFS).
- The in-place upgrade is currently unsupported for on-demand instances on the remaining Public Clouds (Huawei Cloud, Alibaba Cloud, Google Cloud) that use Red Hat Update Infrastructure but not Red Hat Subscription Manager for a RHEL subscription.
See also Known Issues.
You can use Red Hat Insights to determine which of the systems you have registered to Insights is on a supported upgrade path to RHEL 8. To do so, navigate to the respective Advisor recommendation in Insights, enable the recommendation under the Actions drop-down menu, and inspect the list under the Affected systems heading. Note that the Advisor recommendation considers only the RHEL 7 minor version and does not perform a pre-upgrade assessment of the system.
Chapter 2. Preparing a RHEL 7 system for the upgrade
This procedure describes the steps that are necessary before performing an in-place upgrade to RHEL 8 using the Leapp
utility.
If you do not plan to use Red Hat Subscription Manager during the upgrade process, follow instructions in Upgrading to RHEL 8 without Red Hat Subscription Manager.
Prerequisites
- The system meets conditions listed in Planning an upgrade.
Procedure
Ensure your system has been successfully registered to the Red Hat Content Delivery Network (CDN) or Red Hat Satellite using the Red Hat Subscription Manager.
ImportantIf your system is registered to Satellite Server, ensure that Satellite meets the following conditions:
- Satellite is on a version in full or maintenance support. For more information, see Red Hat Satellite Product Life Cycle.
- Satellite has a subscription manifest with RHEL 8 repositories imported. For more information, see the Managing Subscriptions chapter in the Content Management Guide for the particular version of Red Hat Satellite, for example, for version 6.8.
All required repositories are enabled and synchronized with the latest updates and published on Satellite. For example, for the Intel architecture without an Extended Update Support (EUS) subscription, enable at minimum the following repositories:
Red Hat Enterprise Linux 7 Server (RPMs)
rhel-7-server-rpms
x86_64 7Server or x86_64 7.9
Red Hat Enterprise Linux 7 Server - Extras (RPMs)
rhel-7-server-extras-rpms
x86_64
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
rhel-8-for-x86_64-appstream-rpms
x86_64 8.2
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)
rhel-8-for-x86_64-baseos-rpms
x86_64 8.2
For more information, see the Importing Red Hat Content chapter in the Content Management Guide for the particular version of Red Hat Satellite, for example, for version 6.8.
The content host belongs to one of the following:
- A Content View containing the above RHEL 7 and RHEL 8 repositories.
The Default Organization View Content View and the Library life cycle environment.
For more information, see the Managing Content Views chapter in the Content Management Guide for the particular version of Red Hat Satellite, for example, for version 6.8.
Verify that you have the Red Hat Enterprise Linux Server subscription attached:
# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Red Hat Enterprise Linux Server Product ID: 69 Version: 7.9 Arch: x86_64 Status: Subscribed
You should see Server in the product name and Subscribed as the status.
Ensure you have appropriate repositories enabled. The following commands list repositories for the 64-bit Intel architecture; for other architectures, see RHEL 7 repositories.
Enable the Base repository:
# subscription-manager repos --enable rhel-7-server-rpms
Enable the Extras repository where
Leapp
and its dependencies are available:# subscription-manager repos --enable rhel-7-server-extras-rpms
NoteYou can also have the Optional or Supplementary repositories enabled; see their list in RHEL 7 repositories. In such a case,
Leapp
enables the RHEL 8 CodeReady Linux Builder or the RHEL 8 Supplementary repositories, respectively.
Set the Red Hat Subscription Manager to consume the latest RHEL 7 content:
# subscription-manager release --unset
- Optional: If you want to use custom repositories, configure them per instructions in Configuring custom repositories.
If you use the
yum-plugin-versionlock
plug-in to lock packages to a specific version, clear the lock by running:# yum versionlock clear
See How to restrict yum to install or upgrade a package to a fixed specific package version? for more information.
Ensure you have the system locale set to
en_US.UTF-8
:$ cat /etc/locale.conf
If the locale is different, follow instructions in How to change system locale on RHEL7?.
If you are upgrading using Red Hat Update Infrastructure (RHUI) on a public cloud, complete the following tasks to ensure your system is ready for upgrade.
For AWS, enable the Red Hat Update Infrastructure 3 Client Configuration Server 7 repository and install required RHUI packages.
# yum-config-manager --enable rhui-client-config-server-7 # yum -y install rh-amazon-rhui-client leapp-rhui-aws
For Microsoft Azure, enable the Microsoft Azure RPMs for Red Hat Enterprise Linux 7 repository and install required RHUI packages.
# yum-config-manager --enable rhui-microsoft-azure-rhel7 # yum -y install rhui-azure-rhel7 leapp-rhui-azure
NoteIf you locked the Azure virtual machine (VM) to a minor release, remove the version lock. For more information, see Switch a RHEL 7.x VM back to non-EUS.
- If you manage containers in Docker, recreate those containers with the appropriate container images using Podman and then attach any in-use volumes. For more information, see How do I migrate my Docker containers to Podman prior to moving from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8?
Update all packages to the latest RHEL 7 version:
# yum update
Reboot the system:
# reboot
Install the
Leapp
utility:# yum install leapp leapp-repository
Note that currently you need version 0.12.1 or later of the
leapp
package and version 0.13.0 or later of theleapp-repository
package.Download additional required data files (RPM package changes and RPM repository mapping) attached to the Knowledgebase article Data required by the Leapp utility for an in-place upgrade from RHEL 7 to RHEL 8 and place them in the
/etc/leapp/files/
directory. This is necessary for a successful upgrade. Note that currently you need data files from theleapp-data13.tar.gz
archive or later.NoteIf you are upgrading on a public cloud using RHUI and do not have a Red Hat subscription or Red Hat Customer Portal account, create a no-cost RHEL developer subscription so that you can access the Knowledgebase article and download required data packages. For more information, see How do I get a no-cost Red Hat Enterprise Linux Developer Subscription or renew it?
- Temporarily disable antivirus software to prevent the upgrade from failing.
- Ensure you have any configuration management (such as Salt, Chef, Puppet, Ansible) disabled or adequately reconfigured to not attempt to restore the original RHEL 7 system.
-
Ensure your system does not use more than one Network Interface Card (NIC) with a name based on the prefix used by the kernel (
eth
). For instructions on how to migrate to another naming scheme before an in-place upgrade to RHEL 8, see How to perform an in-place upgrade to RHEL 8 when using kernel NIC names on RHEL 7. - Ensure you have a full system backup or a virtual machine snapshot. You should be able to get your system to the pre-upgrade state if you follow standard disaster recovery procedures within your environment. For example, you can use the Relax-and-Recover (ReaR) utility. For more information, see the ReaR documentation and What is Relax and Recover (ReaR) and how can I use it for disaster recovery?. Alternatively, you can use LVM snapshots, or RAID splitting. In case of upgrading a virtual machine, you can create a snapshot of the whole VM.
If you are upgrading with Red Hat Subscription Manager and have disabled the subscription-manager plug-in in yum or yum4, re-enable the plug-in. For more information, see Enabling, configuring, and disabling yum plug-ins.
To determine whether the subscription-manager plug-in is enabled in yum, run the following command:
# yum 2>&1 | grep "^Loaded plugins"
A list of enabled plug-ins is generated. Review the list and determine whether subscription-manager is included.
Chapter 3. Reviewing the pre-upgrade report
To assess upgradability of your system, start the pre-upgrade process by the leapp preupgrade
command. During this phase, the Leapp
utility collects data about the system, assesses upgradability, and generates a pre-upgrade report.
The pre-upgrade report is available both in the /var/log/leapp/leapp-report.txt
file and in the web console. The report summarizes potential problems and proposes recommended solutions. The report also helps you decide whether it is possible or advisable to proceed with the upgrade.
In certain configurations, Leapp
generates true/false questions to determine how to proceed. All questions are stored in /var/log/leapp/answerfile
and in the pre-upgrade report in the Missing required answers in the answer file
message. Leapp
inhibits the upgrade if you do not provide answers to all the questions.
You have two options when assessing upgradability in the pre-upgrade phase:
-
Review the pre-upgrade report in the generated
leapp-report.txt
file and manually resolve reported problems using the command-line interface. - Use the web console to review the report, apply automated remediations where available, and fix remaining problems using the suggested remediation hints.
During the pre-upgrade phase, Leapp
neither simulates the whole in-place upgrade process nor downloads all RPM packages.
Reviewing a pre-upgrade report is useful also if you decide or need to redeploy a RHEL 8 system without the in-place upgrade process.
You can process the pre-upgrade report using your own custom scripts, for example, to compare results from multiple reports across different environments. For more information, see Automating your Red Hat Enterprise Linux pre-upgrade report workflow.
3.1. Assessing upgradability from the command line
Identify potential upgrade problems during the pre-upgrade phase using the command-line interface.
Prerequisites
- The steps listed in Preparing a RHEL 7 system for the upgrade have been completed.
Procedure
On your RHEL 7 system, perform the pre-upgrade phase:
# leapp preupgrade
NoteIf you are going to use custom repositories from the
/etc/yum.repos.d/
directory for the upgrade, enable the selected repositories as follows:# leapp preupgrade --enablerepo repository_id1 --enablerepo repository_id2 ...
If you are going to upgrade without RHSM or using RHUI, add the
--no-rhsm
option.Provide answers to each question required by
Leapp
by either of the following methods:Execute the
leapp answer
command, specifying the question you are responding to and your confirmed answer.# leapp answer --section question_section.confirm=answer
For example, to confirm a
True
response to the question Disable pam_pkcs11 module in PAM configuration?, execute the following command:# leapp answer --section remove_pam_krb5_module_check.confirm=True
-
Manually edit the
/var/log/leapp/answerfile
file, uncomment theconfirm
line of the file by deleting the#
symbol, and confirm your answer asTrue
orFalse
; see Leapp answerfile.
-
Examine the report in the
/var/log/leapp/leapp-report.txt
file, and manually resolve all the reported problems before proceeding with the in-place upgrade.
3.2. Assessing upgradability and applying automated remediations through the web console
Identify potential problems in the pre-upgrade phase and how to apply automated remediations using the web console.
Prerequisites
- The steps listed in Preparing a RHEL 7 system for the upgrade have been completed.
Procedure
Install the
cockpit-leapp
plug-in:# yum install cockpit-leapp
-
Navigate to the web console in your browser and log in as
root
or as a user configured in the/etc/sudoers
file. See Managing systems using the RHEL 7 web console for more information about the web console. On your RHEL 7 system, perform the pre-upgrade phase either from the command-line interface or from the web console terminal:
# leapp preupgrade
NoteIf you are going to use custom repositories from the
/etc/yum.repos.d/
directory for the upgrade, enable the selected repositories as follows:# leapp preupgrade --enablerepo repository_id1 --enablerepo repository_id2 ...
If you are going to upgrade without RHSM or using RHUI, add the
--no-rhsm
option.In the web console, select
from the left menu.Figure 3.1. In-place upgrade report in the web console
The report table provides an overview of the problems found, their risk assessment, and remediations (if available).
Risk factor:
- High - very likely to result in a deteriorated system state
- Medium - can impact both the system and applications
- Low - should not impact the system but can have an impact on applications
- Info - informational with no expected impact to the system or applications
- Inhibitor - will inhibit (hard stop) the upgrade process, otherwise the system could become unbootable, inaccessible, or dysfunctional
Remediation - an actionable solution to a reported problem:
- Remediation command - can be executed directly through the web console
- Remediation hint - instructions on how to resolve the problem manually
Examine the content of the report. You can sort the table by clicking a header. To open a detail pane, click a selected row.
Figure 3.2. Detail pane
The detail pane displays the following additional information:
- Summary of the problem and links to Knowledgebase articles describing the problem in more detail
- Remediations - you can run or schedule an automated remediation (if available), and see its results when applied
- Affected system resources: packages, repositories, files (configuration, data), disks, volumes
Optionally filter the results. Click the
button in the top left corner above the report and apply a filter based on your preferences. Filter categories are applied in conjunction with one another.Figure 3.3. Filters
Select issues for which you want to apply an automated remediation. You have two options:
- Choose individual items by clicking the button in the detail pane. Alternatively, you can execute individual remediations directly by clicking in the detail pane.
- Select all items for which a remediation is available by clicking the button in the top right corner above the report.
Review and answer questions required by
Leapp
in the web console. Each unanswered question appears as aMissing required answers in the answer file
title in the Upgrade Report. Select a title to answer the question:-
To confirm the default
True
answer, select to execute the remediation later or to execute the remediation immediately. To select the non-default answer instead, perform either of the following:
Execute the
leapp answer
command, specifying the question you are responding to and your confirmed answer.# leapp answer --section question_section.confirm=answer
For example, to confirm a
False
response to the question Disable pam_pkcs11 module in PAM configuration?, execute the following command:# leapp answer --section remove_pam_krb5_module_check.confirm=False
Manually edit the
/var/log/leapp/answerfile
file, uncomment theconfirm
line of the file by deleting the#
symbol, and confirm your answer asTrue
orFalse
; see Leapp answerfile example.Figure 3.4. Missing unanswered Leapp question
-
To confirm the default
Open the remediation plan by clicking the
link in the top right corner above the report. The remediation plan provides a list of all executed or scheduled remediations.Figure 3.5. Remediation plan
Process all scheduled remediations by clicking
. The following information is displayed for each remediation entry:- A unique ID of the remediation
- Exit status of the command
- Elapsed time of the executed remediation
- Standard output
- Standard error
-
After executing selected remediations, generate the pre-upgrade report again by using the
leapp preupgrade
command, examine the new report, and take additional remediation steps if needed.
Chapter 4. Performing the upgrade from RHEL 7 to RHEL 8
Upgrade to RHEL 8 using the Leapp
utility.
Prerequisites
- The steps listed in Preparing a RHEL 7 system for the upgrade have been completed, including a full system backup.
- The steps listed in Reviewing the pre-upgrade report have been completed and all reported issues resolved.
Procedure
On your RHEL 7 system, start the upgrade process:
# leapp upgrade
NoteIf you are going to use custom repositories from the
/etc/yum.repos.d/
directory for the upgrade, enable the selected repositories as follows:# leapp upgrade --enablerepo repository_id1 --enablerepo repository_id2 ...
If you are going to upgrade without RHSM or using RHUI, add the
--no-rhsm
option.At the beginning of the upgrade process,
Leapp
performs the pre-upgrade phase described in Reviewing the pre-upgrade reportIf the system is upgradable,
Leapp
downloads necessary data and prepares an RPM transaction for the upgrade.If your system does not meet the parameters for a reliable upgrade,
Leapp
terminates the upgrade process and provides a record describing the issue and a recommended solution in the/var/log/leapp/leapp-report.txt
file. For more information, see Troubleshooting.Manually reboot the system:
# reboot
In this phase, the system boots into a RHEL 8-based initial RAM disk image, initramfs.
Leapp
upgrades all packages and automatically reboots to the RHEL 8 system.Alternatively, you can run the
leapp upgrade
command with the--reboot
option and skip this manual step.If a failure occurs, investigate logs as described in Troubleshooting.
- Log in to the RHEL 8 system and verify its state as described in Verifying the post-upgrade state of the RHEL 8 system.
- Complete post-upgrade tasks as described in Performing post-upgrade tasks. Especially, re-evaluate and re-apply your security policies.
Chapter 5. Verifying the post-upgrade state of the RHEL 8 system
This procedure lists verification steps recommended to perform after an in-place upgrade to RHEL 8.
Prerequisites
- The system has been upgraded following the steps described in Performing the upgrade from RHEL 7 to RHEL 8 and you have been able to log in to RHEL 8.
Procedure
After the upgrade completes, determine whether the system is in the required state, at least:
Verify that the current OS version is Red Hat Enterprise Linux 8:
# cat /etc/redhat-release Red Hat Enterprise Linux release 8.2 (Ootpa)
Check the OS kernel version:
# uname -r 4.18.0-193.el8.x86_64
Note that
.el8
is important.If you are using the Red Hat Subscription Manager:
Verify that the correct product is installed:
# subscription-manager list --installed +-----------------------------------------+ Installed Product Status +-----------------------------------------+ Product Name: Red Hat Enterprise Linux for x86_64 Product ID: 479 Version: 8.2 Arch: x86_64 Status: Subscribed
Verify that the release version is set to 8.2 immediately after the upgrade:
# subscription-manager release Release: 8.2
- Verify that network services are operational, for example, try to connect to a server using SSH.
- Check the post-upgrade status of your applications. In some cases, you may need to perform migration and configuration changes manually. For example, to migrate your databases, follow instructions in RHEL 8 Database servers documentation.
Chapter 6. Performing post-upgrade tasks
This procedure lists major tasks recommended to perform after an in-place upgrade to RHEL 8.
Prerequisites
- The system has been upgraded following the steps described in Performing the upgrade from RHEL 7 to RHEL 8 and you have been able to log in to RHEL 8.
- The status of the in-place upgrade has been verified following the steps described in Verifying the post-upgrade status of the RHEL 8 system.
Procedure
After performing the upgrade, complete the following tasks:
Ensure your system remains supported after the in-place upgrade. With the general availability of RHEL 8.3, update your system either to RHEL 8.3 or to RHEL 8.2 Extended Update Support (EUS).
Update the system to RHEL 8.3:
Unset Red Hat Subscription Manager to consume the latest RHEL 8.3 content:
# subscription-manager release --unset
Update your system to the latest RHEL 8.3 version:
# yum update
Update the system to RHEL 8.2 EUS:
Enable RHEL 8 EUS repositories:
# subscription-manager repos --enable repository_id1 --enable repository_id2 …
Replace repository_id* with IDs of EUS repositories available with your subscription. Enable at least the BaseOS and AppStream repositories. For example, on the Intel 64 architecture:
# subscription-manager repos --enable rhel-8-for-x86_64-baseos-eus-rpms --enable rhel-8-for-x86_64-appstream-eus-rpms
Update your system to the latest RHEL 8.2.EUS version
# yum update
If you upgraded using RHUI on AWS or Microsoft Azure and your software certification is not available on a later minor release version, lock your system to a minor release version supported by your certification.
# echo '8.x' > /etc/yum/vars/releasever
- Re-evaluate and re-apply your security policies. Especially, change the SELinux mode to enforcing. For details, see Applying security policies.
Chapter 7. Applying security policies
During the in-place upgrade process, certain security policies must remain disabled. Furthermore, RHEL 8 introduces a new concept of system-wide cryptographic policies and also security profiles might contain changes between major releases. This section guides you when securing your upgraded RHEL systems.
7.1. Changing SELinux mode to enforcing
During the in-place upgrade process, the Leapp
utility sets SELinux mode to permissive. When the system is successfully upgraded, you have to manually change SELinux mode to enforcing.
Prerequisites
- The system has been upgraded and you have performed the verification steps described in Verifying the post-upgrade state of the RHEL 8 system.
Procedure
Ensure that there are no SELinux denials, for example, by using the
ausearch
utility:# ausearch -m AVC,USER_AVC -ts boot
Note that the previous step covers only the most common scenario. To check for all possible SELinux denials, see the Identifying SELinux denials section in the Using SELinux title, which provides a complete procedure.
Open the
/etc/selinux/config
file in a text editor of your choice, for example:# vi /etc/selinux/config
Configure the
SELINUX=enforcing
option:# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted
Save the change, and restart the system:
# reboot
Verification steps
After the system restarts, confirm that the
getenforce
command returnsEnforcing
:$ getenforce Enforcing
Additional resources
7.2. Setting system-wide cryptographic policies
Crypto policies is a system component that configures the core cryptographic subsystems, covering the TLS, IPSec, SSH, DNSSec, and Kerberos protocols.
After a successful installation or an in-place upgrade process, the system-wide cryptographic policy is automatically set to DEFAULT
. The DEFAULT
system-wide cryptographic policy level offers secure settings for current threat models.
To view or change the current system-wide cryptographic policy, use the update-crypto-policies tool:
$ update-crypto-policies --show
DEFAULT
For example, the following command switches the system-wide crypto policy level to FUTURE
, which should withstand any near-term future attacks:
# update-crypto-policies --set FUTURE
Setting system policy to FUTURE
RHEL 8.2 also introduces customization of system-wide cryptographic policies. For details, see the Customizing system-wide cryptographic policies with policy modifiers and Creating and setting a custom system-wide cryptographic policy sections.
Additional resources
- Using system-wide cryptographic policies
-
update-crypto-policies(8)
man page.
7.3. Remediating the system to a security baseline
The OpenSCAP suite provides remediations to make your system compliant with security baselines, such as PCI-DSS, OSPP, or ACSC E8. Use the steps in the following procedure for changing your system settings to conform with the PCI-DSS profile.
Red Hat does not provide any automated method to revert changes made by security-hardening remediations. Remediations are supported on RHEL systems in the default configuration. If your system has been altered after the installation, running remediation might not make it compliant with the required security profile.
Prerequisites
-
The
scap-security-guide
package is installed on your RHEL 8 system.
Procedure
Use the
oscap
command with the--remediate
option:# oscap xccdf eval --profile pci-dss --remediate /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
You can replace pci-dss in the previous example by a profile required by your scenario.
Restart your system:
# reboot
Verification steps
Evaluate the system of how it complies with the PCI-DSS profile, and save results to the pcidss_report.html file:
$ oscap xccdf eval --report pcidss_report.html --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
Additional resources
- Scanning the system for security compliance and vulnerabilities
-
scap-security-guide(8)
man page -
oscap(8)
man pages
Chapter 8. Troubleshooting
You can refer to the following tips to troubleshoot upgrading from RHEL 7 to RHEL 8.
8.1. Troubleshooting resources
You can refer to the following troubleshooting resources.
Console output
By default, only error and critical log level messages are printed to the console output by the Leapp
utility. To change the log level, use the --verbose
or --debug
options with the leapp upgrade
command.
-
In verbose mode,
Leapp
prints info, warning, error, and critical messages. -
In debug mode,
Leapp
prints debug, info, warning, error, and critical messages.
Logs
-
The
/var/log/leapp/leapp-upgrade.log
file lists issues found during the initramfs phase. -
The
/var/log/leapp/dnf-debugdata/
directory contains transaction debug data. This directory is present only if theleapp upgrade
command is executed with the--debug
option. -
The
/var/log/leapp/answerfile
contains questions required to be answered byLeapp
. -
The
journalctl
utility provides complete logs.
Reports
-
The
/var/log/leapp/leapp-report.txt
file lists issues found during the pre-upgrade phase. The report is also available in the web console, see Assessing upgradability and applying automated remediations through the web console. -
The
/var/log/leapp/leapp-report.json
file lists issues found during the pre-upgrade phase in a machine-readable format, which enables you to process the report using custom scripts. For more information, see Automating your Red Hat Enterprise Linux pre-upgrade report workflow.
8.2. Troubleshooting tips
You can refer to the following troubleshooting tips.
Pre-upgrade phase
- Verify that your system meets all conditions listed in Planning an upgrade.
-
Make sure you have followed all steps described in Preparing a RHEL 7 system for the upgrade for example, your system does not use more than one Network Interface Card (NIC) with a name based on the prefix used by the kernel (
eth
). Make sure you have answered all questions required by
Leapp
in the/var/log/leapp/answerfile
file. If any answers are missing,Leapp
inhibits the upgrade. Example questions:- Disable pam_pkcs11 module in PAM configuration?
- Disable pam_krb5 module in PAM configuration?
- Configure PAM and nsswitch.conf with the following authselect call?
-
Make sure you have resolved all problems identified in the pre-upgrade report, located at
/var/log/leapp/leapp-report.txt
. To achieve this, you can also use the web console, as described in Assessing upgradability and applying automated remediations through the web console.
Example 8.1. Leapp answerfile
The following is an example of an unedited /var/log/leapp/answerfile
file that has one unanswered question:
[remove_pam_pkcs11_module_check] # Title: None # Reason: Confirmation # =================== remove_pam_pkcs11_module_check.confirm ================== # Label: Disable pam_pkcs11 module in PAM configuration? If no, the upgrade process will be interrupted. # Description: PAM module pam_pkcs11 is no longer available in RHEL-8 since it was replaced by SSSD. # Type: bool # Default: None # Available choices: True/False # Unanswered question. Uncomment the following line with your answer # confirm =
The Label
field specifies the question that requires an answer. In this example, the question is Disable pam_pkcs11 module in PAM configuration?
To answer the question, uncomment the confirm
line and enter an answer of True
or False
. In this example, the selected answer is True
:
[remove_pam_pkcs11_module_check]
...
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
confirm = True
Download phase
-
If a problem occurs during downloading RPM packages, examine transaction debug data located in the
/var/log/leapp/dnf-debugdata/
directory.
initramfs phase
During this phase, potential failures redirect you to the Dracut shell. Check the Journal log:
# journalctl
Alternatively, restart the system from the Dracut shell using the
reboot
command and check the/var/log/leapp/leapp-upgrade.log
file.
Post-upgrade phase
- If your system seems to be successfully upgraded but booted with the old RHEL 7 kernel, restart the system and check the kernel version of the default entry in GRUB.
- Make sure you have followed the recommended steps in Verifying the post-upgrade state of the RHEL 8 system.
If your application or a service stops working or behaves incorrectly after you have switched SELinux to enforcing mode, search for denials using the ausearch, journalctl, or dmesg utilities:
# ausearch -m AVC,USER_AVC -ts boot # journalctl -t setroubleshoot # dmesg | grep -i -e selinux -e type=1400
The most common problems are caused by incorrect labeling. See Troubleshooting problems related to SELinux for more details.
8.3. Known issues
The following are Known Issues you may encounter when upgrading from RHEL 7 to RHEL 8.
- Network teaming currently does not work when the in-place upgrade is performed while Network Manager is disabled or not installed.
-
If you use an HTTP proxy, Red Hat Subscription Manager must be configured to use such a proxy, or the
subscription-manager
command must be executed with the--proxy <hostname>
option. Otherwise, an execution of thesubscription-manager
command fails. If you use the--proxy
option instead of the configuration change, the upgrade process fails becauseLeapp
is unable to detect the proxy. To prevent this problem from occurring, manually edit therhsm.conf
file as described in How to configure HTTP Proxy for Red Hat Subscription Management. (BZ#1689294) -
If your RHEL 7 system is installed on an FCoE Logical Unit Number (LUN) and connected to a network card that uses the
bnx2fc
driver, the LUN is not detected in RHEL 8 after the upgrade. Consequently, the upgraded system fails to boot. (BZ#1718147) -
If your RHEL 7 system uses a device driver that is provided by Red Hat but is not available in RHEL 8,
Leapp
inhibits the upgrade. However, if the RHEL 7 system uses a third-party device driver that is not included in the list of removed drivers (located at/etc/leapp/repos.d/system_upgrade/el7toel8/actors/kernel/checkkerneldrivers/files/removed_drivers.txt
),Leapp
does not detect such a driver and proceeds with the upgrade. Consequently, the system might fail to boot after the upgrade.
You cannot perform an in-place upgrade when the
winbind
andwins
Samba modules are used in the/etc/nsswitch.conf
file at the moment. The upgrade transaction fails with the following error messages andLeapp
inhibits the upgrade:upgrade[469]: STDERR: upgrade[469]: Error in PREIN scriptlet in rpm package unbound-libs upgrade[469]: Error: Transaction failed upgrade[469]: Container el8userspace failed with error code 1. unbound-libs has a PREIN failure
To work around this problem, configure the system so that it uses only local providers for the
user
,groups
, andhosts
database during the update:-
Open the system
/etc/nsswitch.conf
configuration file and search for entries that contain thewinbind
orwins
strings. -
If you find such entries, create a backup of
/etc/nsswitch.conf
. -
Edit
/etc/nsswitch.conf
and removewinbind
orwins
from the entries that contain them. - Perform an in-place upgrade.
After the upgrade, add the
winbind
andwins
strings to the respective entries in/etc/nsswitch.conf
, based on your system configuration requirements.(BZ#1410154)
-
Open the system
The
Leapp
utility does not change customized authentication configuration during the upgrade process. If you used the deprecatedauthconfig
utility to configure authentication on your RHEL 7 system, authentication on RHEL 8 might not work correctly. To ensure that your custom configuration functions properly on the RHEL 8 system, re-configure your RHEL 8 system with theauthselect
utility.ImportantDuring the in-place upgrade, the deprecated
pam_krb5
orpam_pkcs11
pluggable authentication modules (PAM) are removed. Consequently, if the PAM configuration on your RHEL 7 system contains thepam_krb5
orpam_pkcs11
modules and if these modules have therequired
orrequisite
control values, performing the in-place upgrade might result in locking you out of the system. To work around this problem, reconfigure your RHEL 7 system to not usepam_krb5
orpam_pkcs11
before you start the upgrade process.
-
On IBM Z systems,
Leapp
always expects a DASD disk attached. Consequently, if the/etc/dasd.conf
file does not exist, the in-place upgrade fails. To work around this problem, create an emptydasd.conf
file by using thetouch > /etc/dasd.conf
command. (BZ#1783248) If a name of a third-party package (not signed by Red Hat) installed on your system is the same as of a package provided by Red Hat, the in-place upgrade fails. To work around this problem, choose one of the following options prior to upgrading:
- Remove the third-party package
- Replace the third-party package with the package provided by Red Hat
-
During an in-place upgrade, the
docker
package is removed without a warning. If you use containers in RHEL, migrate to Podman prior to upgrading to RHEL 8. For instructions, see How do I migrate my Docker containers to Podman prior to moving from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8?. (BZ#1858711)
Due to security reasons, support for single-DES (DES) and triple-DES (3DES) encryption types has been removed from RHEL 8.3.0. RHEL 7 Identity Management (IdM), however, still supports 3DES encryption.
Upgrading an IdM environment from RHEL 7 to RHEL 8 is possible because both versions of RHEL prefer stronger AES encryption types by default:Version of IdM Default encryption types Additional supported encryption types RHEL 7
aes256-cts
aes128-cts
camellia256-cts
camellia128-cts
des3-hmac
arcfour-hmac
RHEL 8
aes256-cts
aes128-cts
aes256-sha2
aes128-sha2
camellia256-cts
camellia128-cts
arcfour-hmac
[a][a] RC4 encryption has been deprecated and disabled by default in RHEL 8, as it is considered less secure than the newer AES-128 and AES-256 encryption types. For more information on enabling RC4 support for compatibility with legacy Active Directory environments, see Ensuring support for common encryption types in AD and RHEL.If you manually configured a non-IdM Kerberos Distribution Center (KDC), any services, or any users to only use DES or 3DES encryption, you might experience service interruptions after updating to the latest Kerberos packages in RHEL 8, such as:
- Kerberos authentication errors
-
unknown enctype
encryption errors -
KDCs with DES-encrypted Database Master Keys (
K/M
) fail to start
Red Hat recommends you do not use DES or 3DES encryption in your environment. For more information on re-keying Kerberos principals to use stronger encryption types, see Retiring DES from MIT Kerberos Documentation.
8.4. Obtaining support
You can open a support case, select RHEL 8 as the product, and provide a sosreport
from your system.
-
To generate a
sosreport
on your system, run:
# sosreport
Note that you can leave the case ID empty.
For details on generating a sosreport, see the solution What is an sosreport and how to create one in Red Hat Enterprise Linux?.
For more information on opening and managing a support case on the Customer Portal, see the article How do I open and manage a support case on the Customer Portal?.
Appendix A. RHEL 7 repositories
Before the upgrade, ensure you have appropriate repositories enabled as described in step 3 of the procedure in Preparing a RHEL 7 system for the upgrade.
If you plan to use Red Hat Subscription Manager during the upgrade, you must enable the following repositories before the upgrade by using the subscription-manager repos --enable repository_id
command:
Architecture | Repository | Repository ID |
---|---|---|
64-bit Intel | Base |
|
Extras |
| |
IBM POWER8 (little endian) | Base |
|
Extras |
| |
IBM POWER9 (little endian) | Base |
|
Extras |
| |
IBM Z | Base |
|
Extras |
| |
IBM Z (Structure A) | Base |
|
Extras |
|
You can enable the following repositories before the upgrade by using the subscription-manager repos --enable repository_id
command:
Architecture | Repository | Repository ID |
---|---|---|
64-bit Intel | Optional |
|
Supplementary |
| |
IBM POWER8 (little endian) | Optional |
|
Supplementary |
| |
IBM POWER9 (little endian) | Optional |
|
Supplementary |
| |
IBM Z | Optional |
|
Supplementary |
| |
IBM Z (Structure A) | Optional |
|
Supplementary | N/A |
If you have enabled a RHEL 7 Optional or a RHEL 7 Supplementary repository before an in-place upgrade, Leapp
enables the RHEL 8 CodeReady Linux Builder or RHEL 8 Supplementary repositories, respectively.
If you decide to use custom repositories, enable them per instructions in Configuring custom repositories.