In-Place Upgrade from EL8 to EL9

This article walks through an in-place major version upgrade of a JetPatch server from Enterprise Linux 8 (EL8) to Enterprise Linux 9 (EL9). The process preserves the server, its hostname and network identity, and lets you restore the JetPatch application on the upgraded operating system without rebuilding the host.
 

Prerequisites:

• Kindly take the Proper snapshot backup and all the configurations and db dumps backups (including the PostgreSQL database and intigua.properties) Before the activity.
• Ensure the EL8 Server is fully updated to latest. 
• Allow outbound network access to the EL9 repositories (Local repository if available). Do not configure EL9 repositories on the server manually; the upgrade tool handles this.
• Allow Leapp tool from appstream and ELevate from External RPM as per the requirement.
• Have Ensure sufficient free space in / and /var, since the upgrade downloads the full EL9 package set into /var.
• Disable the Agents (for Monitoring, Backup) which are running in the Server along with Antivirus Agents.
• Clear the Old remnants files from EL7 if available
• Kindly upgrade the Jetpatch applications to latest to avoid conflicts Before the Upgrade. Kindly reach out to us for the RPMs.

Toll Installation:

For Redhat OS:
Ensure the subscription before runnning the Leapp.

Then Install the Leapp-upgrade 

#subscription-manager status
#dnf install -y leapp-upgrade

For Rocky, Oracle, Alma Use ELevate:

Install the ELevate release package, 

#yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm

Then install the leapp packages along with data package according with their distribution, 

Pre-upgrade simulation Check:

Let's run the preupgrade check by 

#leapp preupgrade

This will check and verify the kernel modules, packages and compatibility for the upgrade without changing the system.

Review the file which is generated after the simulation completes for the outputfile and clear the inhibitors and blockers fully. 

Clearing Inhibitors:

Some inhibitors are questions that need an explicit answer, recorded in /var/log/leapp/answerfile. Answer these with the leapp answer command shown in the report.

Clearing Jetpatch Related Inhibitors:

• If you are getting inhibitors related to nginx, postgres and Intigua, 

• Kindly take the proper backups and disable the services.

  #systemctl stop <service_name>
  #systemctl disable <service_name>

• Then uninstall the mentioned packages in leapp-report.txt.
• After the upgrade, We need to restore all the removed packages. 

Run the preupgrade again to make sure there are no inhibitors pending before the ugrade.

OS Upgrade:

After all the inhibitors were cleared, You can proceed with actual upgrade, 

#leapp upgrade 

This will download the all the required Packages which are required for Upgrade. 

Once you able to see "Reboot the system to continue with the upgrade"

Kindly reboot the Server, which boots into a temporary upgrade environment, applies the upgrade, and then reboots into EL9. This can take a while; do not interrupt it. Monitor progress from the server console if possible.

Verification and Clean-up:

Once the Systems comes back live, Check the release, 

#cat /etc/os-release
#uname -r

Check for the applications and agents/services and other required data were present, up and running. 

Re-enable and start the antivirus, monitoring, and other agents stopped before the activity.

Once verified, We can proceed for clean up.

You can clean up the old Remnants packages and files by, 

#leapp cleanup

# rpm -qa | grep -E '\.el8' | grep -v gpg-pubkey | sort
After reviewing the list, remove what is no longer needed:
dnf remove <package_names>
Remove upgrade tool data and old kernel modules
#rm -rf /var/log/leapp /var/lib/leapp /root/tmp_leapp_py3
#rm -rf /lib/modules/*el8*
#dnf autoremove -y

Clear the dnf cache to downlaod the latest files by 

#dnf clean all && dnf update -y

Reinstallation of Packages:

Let's install the Packages to restore the application which we are removed like nginx, postgres, Intigua packages.

For Postgres: 

Change the version as per the requirement.

Install the repository RPM:

# sudo dnf install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-9-x86_64/pgdg-redhat-repo-latest.noarch.rpm

Install PostgreSQL:

#sudo dnf install -y postgresql16-server

#sudo systemctl enable postgresql-16
#sudo systemctl start postgresql-16

If the original data directory (/var/lib/pgsql/16/data) is still intact, do not run initdb; just enable and start the service. Otherwise, initialize a new cluster and restore from your dump:

Optionally initialize the database and enable automatic start( only if DB data is not available)
#sudo /usr/pgsql-16/bin/postgresql-16-setup initdb

For Nginx:

#dnf install -y nginx
Restore nginx configuration and certificates from backup if needed
#nginx -t
#systemctl enable --now nginx

For Intigua: 

Install the same versions before the upgrade.

Via the RPMs

#dnf localinstall intigua*

Via Live Repo:

#dnf install intigua*

Restoration of Jetpatch Configuration: 

Once everything installed, Kindly restore the intigua.properties 

#cp -rp /backup_path/intigua.properties /usr/share/tomcat/default/conf/intigua.properties

Then restart the Tomcat. 

#systemctl restart tomcat.

JetPatch Verification:

Restarting Tomcat brings the JetPatch application back up. Before closing the activity, confirm:

1. The JetPatch console loads and users can log in.
2. Remediation Plans (RPs) are present and their schedules are intact.
3. Connectivity to managed endpoints and integrated systems is working.
4. A test patching job or RP run completes successfully on a non-critical target.

5. All services disabled in Step 3 are re-enabled and start on boot.
   
   Rollback

   If the upgrade fails or JetPatch does not function correctly afterward:

1. Restore the VM snapshot taken before the activity.
2. Confirm the server is back on EL8 and JetPatch is working as before.
3. Contact JetPatch Support with /var/log/leapp/leapp-report.txt, /var/log/leapp/leapp-upgrade.log, and any application errors observed.