RHEL7/8/9 Leapp upgrade utility

-

Here we are going to see how to use leapp upgrade utility to perform an upgrade of RHEL7.9 to RHEL8 or RHEL version 8.6 to version 9. This note is specific to RHEL7.9 to 8 upgrade.

Update RHEL version 7.x to 7.9 and 8.x to 8.6 prior to planning upgrade to major versions.

Few riders are,

  • NFS and network storage protocols like iscsi are not supported. 
  • Only upgrade to following major version is supported, ex RHEL7 to RHEL8 & RHEL8 to RHEL9.
  • Wont work on your encrypted root device.
  • Public cloud instance using RedHat Update Infrastructure are not eligible for Leapp upgrade.
  • VDO devices must be converted to LVM managed devs.
  • For RHEL7, the minor version should at least be, 7.9. So update your OS to version 7.9 .
  • Take backup and snapshots to restore back to previous version and avoid complete loss of servers.
  • Generate Sosreports.
  • rhel-7-server-extras-rpms should be added to repolist and enabled.
  • Clear any yum version locks.

# yum versionlock clear

# subscription-manager repos --enable rhel-7-server-extras-rpms

Leapp can now be installed on rhel7.

          # yum install leapp -y

 

Few quick mental map on leapp:

  • Leapp Upgrade = Pre-Upgrade Analysis phase + Upgrade Phase.

  • You get 2 commands, leapp & leapp-upgrade-el8toel9 available from rhel-8-for-x86_64-appstream-rpms repo.

  • Remove left over file from any previous leapp upgrade , /root/tmp_leapp_py3 .



Now perform, pre-upgrade analysis:

          # leapp preupgradeundefined

Generates, reports on ability to upgrade node with pointers to remediations, stores responses to queries in answer file, logs in preupgrade.log file. Also keeps the report in json format file. All these files are in /var/log/leapp.

In the report, risk factors are denoted High, Medium, Low, Info . It has title that identifies the element in question, summary to provide description, remediation recommends certain actionables.

Leapp utility makes use of Actors, that can change your system configs. These are written in Python and one can create their own custom Actors.

Keep re-running the preupgrade phase untill output is clean with no inhibitors (blockers to upgrade). Then move to upgrade part.

Once system is ready to be upgraded, run one of below commands,

        # leapp upgrade

        # leapp upgrade –reboot

1st Reboot, bootloader automatically creates another boot env with RHEL-Upgrade-Initramfs, where the upgrade will happen.

2nd Reboot, SELinux labels wll be restored and go for this reboot.

3rd Reboot, final one post which RHEL upgraded environment can be verfied and then used.









Comments

Post a Comment

Popular posts from this blog

VLAN External Network in Openshift using NMState Operators and Multus

-
Image
NMstate operators and Multus CNI provide us with plugins and APIs, to set up external network in openshift container ecosystem. Let us see how we can implement a external VLAN networking for certain pods/VMs apart from, pods/VMs using internal cluster networking. When we install NMState operator, it avails us 3 different APIs, namely: Node Network Configuration Policy : Node level network settings implementation.          # oc get nncp Node Network State : The current state of node network is stored in this.         # oc get nns/<node-name> Node Network Configuration Enactment : The status of NNCP implementation across cluster nodes, is checked in this object.         # oc get nnce Network Attachment Definition (NAD) : Apart from above APIs, we will also make use of NAD from multus CNI plugin framework. This implements namespaced object that exposes existing layer 2 network dev...
Read more

Migrating from OpenshiftSDN to OVNKubernetes CNI

-
APIs involved in this migrations are: Network.operator.openshift.io Network.config.openshift.io Operators involved in this migrations are: Cluster Network Operator (CNO) Machine Config Operator (MCO) Refer to pre-requisite steps here , jotted in another post. Update to latest compatible z-stream .  With  that taken care, proceed below. 1> Backup existing cluster network config:      # oc get Network.config.openshift.io cluster -o yaml > cluster-openshiftSDN.yaml 2> Verify that  OVN_SDN_MIGRATION_TIMEOUT   environment variable is set and is  equal to  0s. 3> Set the migration value to null in CNO object cluster:                  # oc patch Network.operator.openshift.io cluster  -- type='merge'  --patch '{"spec":{"migration":null}}' At this time, CNO updates status of Network.config.openshift.io   CR  named  cluster accordingly. MCO rolls out an update to sys...
Read more

Updating Z-stream of version in Openshift Container Platform

-
Whenever we want to upgrade the OCP to next recommended upgrade path, we want to first move to latest patch version of major and minor version of OCP we are running. For instance, if your Openshift is version 4.15.11 (x.y.z) then, Major (x) version is 4, Minor (y) version is 15 and patch (z) version is 11. First update the master/control node and then worker nodes. The worker nodes in case of update can differ from control node by y-2. This allows to plan for update in large clusters that is staggered across in time. With that bit cleared let us see the procedure to update the z version of OCP version. 1> Just run following to lists the compatible update releases # oc adm upgrade Or run below to see available updates, # oc adm upgrade --include-not-recommended Note: Always consult the OSUS upgrade Graph for valid path upgrades 2> After having made the decision, considering impact of updates on existing set-up, go ahead and update the control node. # oc adm upgrade --to=4.15.3...
Read more