Every step below shows two ways to make the same call:

• A standard requests call, the default Python module to handle REST APIs.
• The equivalent call using oggrestapi.py, the OGGRestAPI Python client I presented in another blog, which handles everything for you.

Installing the latest version of GoldenGate

This part does not change: the REST API cannot install software on the server, so you still need to unzip the patched installation to a new OGG_HOME and run runInstaller in silent mode, as described in the web UI blog.

Patching the Service Manager with the REST API

As with the web UI, the Service Manager has to be patched first. Assume the following setup:

• sm_url: https://vmogg:7809
• new_ogg_home: /u01/app/ogg/product/23.26.2.0.1
• username / password: an administrator on the Service Manager

Updating OGG_HOME is a PATCH call on the ServiceManager deployment:

import requests

sm_url = "https://vmogg:7809"
auth = ("oggadmin", "password")

requests.patch(
    f"{sm_url}/services/v2/deployments/ServiceManager",
    json={"oggHome": "/u01/app/ogg/product/23.26.2.0.1"},
    auth=auth,
)

With oggrestapi.py:

from oggrestapi import OGGRestAPI

client = OGGRestAPI(url="https://vmogg:7809", username="oggadmin", password="password")
client.update_deployment(deployment="ServiceManager", ogg_home="/u01/app/ogg/product/23.26.2.0.1")

Already, you can see that the REST API client simplifies the patching a lot.

Restarting the Service Manager is the same endpoint, this time setting status:

requests.patch(
    f"{sm_url}/services/v2/deployments/ServiceManager",
    json={"status": "restart"},
    auth=auth,
)

client.restart_deployment(deployment="ServiceManager")

restart_deployment is a dedicated method in oggrestapi.py, following the same pattern already used for restart_service, restart_extract and restart_replicat. It makes it easier to use the API, instead of building the {"status": "restart"} payload yourself. It also takes an optional only_if_running argument, so a deployment that was already stopped before the patch is left alone rather than being started by the restart call.

As with the web UI, all your deployment processes are still running on the old OGG_HOME at this point. The AIService, introduced in 26ai, does not pick up the new home automatically either. You should then list the services attached to the Service Manager and restart the ones that are not ServiceManager itself:

services = requests.get(
    f"{sm_url}/services/v2/deployments/ServiceManager/services",
    auth=auth,
).json()["response"]["items"]

for service in services:
    if service["name"] != "ServiceManager":
        requests.patch(
            f"{sm_url}/services/v2/deployments/ServiceManager/services/{service['name']}",
            json={"status": "restart"},
            auth=auth,
        )

for service in client.list_services("ServiceManager"):
    if service.get("name") != "ServiceManager":
        client.restart_service(deployment="ServiceManager", service=service.get("name"))

Patching each deployment with the REST API

Once the Service Manager runs on the new home, repeat the same update, then restart sequence for each deployment (oggHome, then status: restart):

deployment = "ogg_test_01"

requests.patch(
    f"{sm_url}/services/v2/deployments/{deployment}",
    json={"oggHome": "/u01/app/ogg/product/23.26.2.0.1"},
    auth=auth,
)

requests.patch(
    f"{sm_url}/services/v2/deployments/{deployment}",
    json={"status": "restart"},
    auth=auth,
)

client.update_deployment(deployment="ogg_test_01", ogg_home="/u01/app/ogg/product/23.26.2.0.1")
client.restart_deployment(deployment="ogg_test_01")

Once the deployment is back up, restart its extracts and replicats. Since these processes are not accessible through the Service Manager port, you need to change the URL. If you use a reverse proxy setup, or auto_discovery=True (see below), this is also easier with the Python client.

admin_url = "https://vmogg:7810"

extracts = requests.get(f"{admin_url}/services/v2/extracts", auth=auth).json()["response"]["items"]
for extract in extracts:
    requests.patch(f"{admin_url}/services/v2/extracts/{extract['name']}", json={"status": "stopped"}, auth=auth)
    requests.patch(f"{admin_url}/services/v2/extracts/{extract['name']}", json={"status": "running"}, auth=auth)

replicats = requests.get(f"{admin_url}/services/v2/replicats", auth=auth).json()["response"]["items"]
for replicat in replicats:
    requests.patch(f"{admin_url}/services/v2/replicats/{replicat['name']}", json={"status": "stopped"}, auth=auth)
    requests.patch(f"{admin_url}/services/v2/replicats/{replicat['name']}", json={"status": "running"}, auth=auth)

With oggrestapi.py, restart_all_extracts and restart_all_replicats do the same thing on an OGGRestAPI client already pointed at the deployment (either connected directly to its Administration Service, or through an NGINX reverse proxy with deployment= set):

admin_client = OGGRestAPI(url="https://vmogg:7810", username="oggadmin", password="password")
admin_client.restart_all_extracts(only_if_running=True)
admin_client.restart_all_replicats(only_if_running=True)

Automating the whole patching in one call

The steps listed above (update home, restart deployment, restart processes for every deployment) is exactly what patch_deployment (a single deployment) and patch_deployments (all of them) already do in oggrestapi.py, internally calling restart_deployment for the restart step. They also handle the ServiceManager special case (patch and restart the deployment and its services, but never restart extracts and replicats on it) and the wait_until_deployment_status polling in between:

client = OGGRestAPI(url="https://vmogg:7809", username="oggadmin", password="password", reverse_proxy=True)
client.patch_deployments(new_home="/u01/app/ogg/product/23.26.2.0.1", ask_credentials=False)

Both methods take restart_after_patch and restart_processes_after_patch (both default to True) if you need to skip either step, for example to patch every home first and restart everything in a separate maintenance window:

client.patch_deployments(
    new_home="/u01/app/ogg/product/23.26.2.0.1",
    restart_after_patch=False,
    restart_processes_after_patch=False,
    ask_credentials=False,
)

restart_processes_after_patch=True needs per-deployment routing: restarting extracts and replicats on ogg_test_01 is a different call than on ogg_test_02, and a plain connection to the Service Manager’s own port has no way to reach either one. oggrestapi.py gives you two ways to get that routing from a single client:

• reverse_proxy=True, shown above, if you already run NGINX in front of your deployments.
• auto_discovery=True, with no reverse proxy at all. The client looks up each deployment’s real Administration/Distribution/Performance Metrics Service port through the Service Manager itself (the same GET .../deployments/{deployment}/services/{service} call), the first time each one is actually needed, and reuses that lookup for the rest of the run:

client = OGGRestAPI(url="https://vmogg:7809", username="oggadmin", password="password", auto_discovery=True)
client.patch_deployments(new_home="/u01/app/ogg/product/23.26.2.0.1", ask_credentials=False)

Without either flag, patch with restart_processes_after_patch=False and restart each deployment’s processes yourself through a separate client pointed at that deployment’s own admin URL.

Some services are still running on the old OGG_HOME

Same as with the web UI: a restart call on a deployment returns as soon as the Administration Service (adminsrvr) is back up. The Receiver Service (recvsrvr) or the Distribution Service (distsrvr) can take a bit longer to restart. If, after polling for a few minutes, a service is still reporting the old home, restart it individually with the same PATCH .../services/{service} call shown above for the AIService, or with the restart_service method.

Other things to consider

If you change the name of your home at every release, remember to update OGG_HOME in every script and environment that references it, for example:

• DMK environment files.
• systemd service files, which might hardcode the OGG_HOME variable.

L’article GoldenGate 26ai out-of-place patching with Python est apparu en premier sur dbi Blog.

When and why should I worry about long running transactions ?

In a standard extract life-cycle, you should not be worrying about long running transactions. In fact, the only time you should think about these is when you plan an extract migration. By this, I mean moving an ongoing extract to a new GoldenGate environment.

This could be the case if you are moving the extract to a new GoldenGate deployment, whether it’s because of a version upgrade, system change or architecture change.

Another candidate scenario would be if you wanted to rename an extract.

Checking for Long Running Transactions with the adminclient

To check for long running transactions in the source database, you can use the adminclient and the showtrans tabular option of the send command.

OGG (https://vmogg ogg_test_01) 1> send extract ext showtrans tabular

Sending showtrans tabular request to Extract group EXT ...



XID                     Items    Extract   Redo Thread  Start Time           SCN                               Redo Seq  Redo RBA            Status
------------------------------------------------------------------------------------------------------------------------------------------------------
0.17.18.1700953         0        EXT       1            2026-06-06:08:04:12  629.3084780551 (2704619209735)    48911     156909584           Running

WARNING: This command will query the database for ALL active transactions ! There is absolutely no filter in place to only show transactions that are relevant for the extract you are targeting. To confirm this, let’s look in the database to get more information about this transaction.

-- Query to get the schema associated with a specific transaction, based on the XID column from the OGG output above
SELECT s.username, t.xidusn, t.xidslot, t.xidsqn, t.start_time, t.start_scn
FROM v$transaction t
JOIN v$session s ON t.ses_addr = s.saddr
WHERE t.xidusn = 17
AND t.xidslot = 18
AND t.xidsqn = 1700953;

USERNAME       XIDUSN     XIDSLOT      XIDSQN START_TIME          START_SCN
---------  ----------  ----------  ---------- ------------------- ----------------
DBIBLOG            17          18     1700953 06/06/26 08:04:12   2704619209735

But if I look at the extract parameter file, the DBIBLOG schema is not even being extracted.

OGG (https://vmogg ogg_test_01) 1> view params EXT
EXTRACT EXT
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL pdb1/aa
SOURCECATALOG PDB1
TABLE APP_SCHEMA.*;

Of course, the DBIBLOG user might be editing data in the APP_SCHEMA schema, but there is no way to know for sure just by looking at the output of adminclient command above.

When searching for long running transactions, you should retrieve the START_SCN of the transaction. In the example given above, the START_SCN is 2704619209735.

Now that we have the START_SCN, we can check if the extract has already processed it or not by looking at the checkpoint information. From the adminclient, run the info extract EXT showch command:

OGG (https://vmogg ogg_test_01) 1> info extract EXT showch

Extract    EXT       Last Started 2026-06-06 07:45   Status RUNNING
Description          'Test extract'
Checkpoint Lag       00:01:45 (updated 00:00:32 ago)
Process ID           11711
Log Read Checkpoint  Oracle Integrated Redo Logs
                     2026-06-06:09:01:45
                     SCN 629.3086233843 (2704620663027)
Settings Profile     ogg:managedProcessSettings:dbiDefault


Current Checkpoint Detail:

Read Checkpoint #1

  Oracle Integrated Redo Log

  Startup Checkpoint (starting position in the data source):
    Timestamp: 2026-06-06:07:45:45.000000
    SCN: 0.0 (0)

  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
    Timestamp: 2026-06-06:08:04:13.000000
    SCN: 629.3084780551 (2704619209735)

  Current Checkpoint (position of last record read in the data source):
    Timestamp: 2026-06-06:09:01:45.000000
    SCN: 629.3086233843 (2704620663027)

  BR Startup Recovery Checkpoint:
    Timestamp: 2026-06-02 10:17:33.403806
    SCN: 0.0 (0)

  BR Begin Recovery Checkpoint:
    Timestamp: 2026-06-06 08:04:13.000000
    SCN: 629.3084780551 (2704619209735)

  BR End Recovery Checkpoint:
    Timestamp: 2026-06-06 08:08:45.000000
    SCN: 629.3084879559 (2704619308743)

Write Checkpoint #1

  GGS Log Trail

  Current Checkpoint (current write position):
    Sequence #: 41
    RBA: 50476
...

If we put side to side the START_SCN of the long running transaction and the SCN of the recovery checkpoint, we can see that they are exactly the same (2704619209735). This is expected, and it means that the extract has not yet processed this transaction.

# From SQL query on the source database
USERNAME       XIDUSN     XIDSLOT      XIDSQN START_TIME          START_SCN
---------  ----------  ----------  ---------- ------------------- ----------------
DBIBLOG            17          18     1700953 06/06/26 08:04:12   2704619209735

# From adminclient
  Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
    Timestamp: 2026-06-06:08:04:13.000000
    SCN: 629.3084780551 (2704619209735)

If you wanted to move the extract to another GoldenGate installation or rename it, this would be the SCN at which you would need to start the new extract to avoid missing transactions.

Checking for Long Running Transactions from the REST API

If you are trying to automate the process of checking for long running transactions, using the adminclient might not be the best option. In fact, the display of long running transactions in the adminclient is not designed to be easily parsed by scripts.

Fortunately, you can also check for long running transactions using the official GoldenGate REST API. The endpoint that you need to call is GET /services/{version}/connections/{connection}/activeTransactions. It is described in the GoldenGate REST API documentation.

The endpoint path parameters explain why the transactions shown in the output are not specific to the endpoint. In GoldenGate, a connection is database specific. Combine the domain name and the alias name with a dot separator to form the connection name. In my case, the connection name is OracleGoldenGate.source_cdb.

In Python, let’s see two ways of getting the same information:

• Using the production-ready Python client I presented in another blog.
• Using the requests library to call the REST API directly.

Using the Python client, you can just call the get_active_transactions method as follows:

from oggrestapi import OGGRestAPI

ogg_client = OGGRestAPI(
    url="https://vmogg:7809",
    username="ogg",
)

active_transactions = ogg_client.get_active_transactions('OracleGoldenGate.source_cdb')

>>> active_transactions
{'activeTransactions': [{'txnStartScn': 2704619209735, 'txnStatus': 'ACTIVE', 'txnStartDate': '2026-06-06T08:04:12.000Z', 'sid': 834, 'serialNum': 16450, 'instanceId': 1, 'userName': 'DBIBLOG', 'osUser': 'oracle', 'sessionStatus': 'INACTIVE', 'logonTime': '2026-06-06T08:04:11.456Z'}], 'currentScn': {'csn': 2704620465717, 'currentDate': '2026-06-06T08:27:45.717Z', 'userName': 'SYS'}, '$schema': 'ogg:activeTransactions'}

Otherwise, with the requests library, you can call the activeTransactions endpoint as follows:

import requests

connection_name = "OracleGoldenGate.source_cdb"
# Basic configuration
# Direct connection (no reverse proxy)
# url = f"https://vmogg:7809/services/v2/connections/{connection_name}/activeTransactions"
# NGINX reverse proxy
url = f"https://vmogg/services/ogg_test_01/adminsrvr/v2/connections/{connection_name}/activeTransactions"

auth = ("ogg", "ogg_password")
response = requests.get(
    url,
    auth=auth
)

Here is an example of the output that you should get when looking at the response.json() value:

>>> active_transactions = response.json()['response']
>>> active_transactions
{'activeTransactions': [{'txnStartScn': 2704619209735, 'txnStatus': 'ACTIVE', 'txnStartDate': '2026-06-06T08:04:12.000Z', 'sid': 834, 'serialNum': 16450, 'instanceId': 1, 'userName': 'DBIBLOG', 'osUser': 'oracle', 'sessionStatus': 'INACTIVE', 'logonTime': '2026-06-06T08:04:11.456Z'}], 'currentScn': {'csn': 2704620465717, 'currentDate': '2026-06-06T08:27:45.717Z', 'userName': 'SYS'}, '$schema': 'ogg:activeTransactions'}

Or using the json.dumps() method to get a more readable output:

>>> import json
>>> print(json.dumps(active_transactions, indent=4))
{
    "activeTransactions": [
        {
            "txnStartScn": 2704619209735,
            "txnStatus": "ACTIVE",
            "txnStartDate": "2026-06-06T08:04:12.000Z",
            "sid": 834,
            "serialNum": 16450,
            "instanceId": 1,
            "userName": "DBIBLOG",
            "osUser": "oracle",
            "sessionStatus": "INACTIVE",
            "logonTime": "2026-06-06T08:04:11.456Z"
        }
    ],
    "currentScn": {
        "csn": 2704620465717,
        "currentDate": "2026-06-06T08:27:45.717Z",
        "userName": "SYS"
    },
    "$schema": "ogg:activeTransactions"
}

Using the REST API, the information is more complete and easier to parse. As mentioned before, retrieving the SCN at which the transaction started is sometimes necessary. In that case, you can get it from the following command:

>>> start_scn = active_transactions['activeTransactions'][0]['txnStartScn']
>>> start_scn
2704619209735

If you have multiple long running transactions, you should retrieve the minimum value for the txnStartScn to be sure to get the SCN of the oldest long running transaction.

>>> start_scns = [txn['txnStartScn'] for txn in active_transactions['activeTransactions']]
>>> min(start_scns)
2704619209735

Now that we’ve retrieved the START_SCN of the long running transaction, we should check the checkpoint information.

Using the Python client, you can call the get_extract_checkpoint method as follows:

>>> extract_checkpoints = ogg_client.get_extract_checkpoint('EXT')
>>> extract_checkpoints
{'$schema': 'ogg:extractCheckpoints', 'current': {'input': [{'starting': {'timestamp': '2026-06-06T07:45:45.000Z', 'thread': 1, 'sequence': 0, 'offset': 0, 'csn': None, 'name': None}, 'recovery': {'timestamp': '2026-06-06T08:04:13.000Z', 'thread': 1, 'sequence': 48911, 'offset': 156909584, 'csn': 2704619209735, 'name': None}, 'current': {'timestamp': '2026-06-06T09:01:45.000Z', 'thread': 1, 'sequence': 0, 'offset': 0, 'csn': 2704620663027, 'name': None}, 'boundedRecoveryPrevious': {'timestamp': '2026-06-02 10:17:33.404Z', 'thread': 0, 'sequence': 0, 'offset': 0, 'csn': None, 'name': None}, 'boundedRecoveryBegin': {'timestamp': '2026-06-06T08:04:13.000Z', 'thread': 0, 'sequence': 48911, 'offset': 156909584, 'csn': 2704619209735, 'name': None}, 'boundedRecoveryEnd': {'timestamp': '2026-06-06T08:08:45.000Z', 'thread': 1, 'sequence': 48912, 'offset': 156918384, 'csn': 2704619308743, 'name': None}}]}

Or, using the requests library:

response = requests.get(
    "https://vmogg/services/ogg_test_01/adminsrvr/v2/extracts/EXT/checkpoint",
    auth=auth
)

extract_checkpoints = response.json()['response']

Here is a more readable output from the checkpoint information:

>>> print(json.dumps(extract_checkpoints, indent=4))
{
    "$schema": "ogg:extractCheckpoints",
    "current": {
        "input": [
            {
                "starting": {
                    "timestamp": "2026-06-06T07:45:45.000Z",
                    "thread": 1,
                    "sequence": 0,
                    "offset": 0,
                    "csn": null,
                    "name": null
                },
                "recovery": {
                    "timestamp": "2026-06-06T08:04:13.000Z",
                    "thread": 1,
                    "sequence": 48911,
                    "offset": 156909584,
                    "csn": 2704619209735,
                    "name": null
                },
                "current": {
                    "timestamp": "2026-06-06T09:01:45.000Z",
                    "thread": 1,
                    "sequence": 0,
                    "offset": 0,
                    "csn": 2704620663027,
                    "name": null
                },
                "boundedRecoveryPrevious": {
                    "timestamp": "2026-06-02T10:17:33.404Z",
                    "thread": 0,
                    "sequence": 0,
                    "offset": 0,
                    "csn": null,
                    "name": null
                },
                "boundedRecoveryBegin": {
                    "timestamp": "2026-06-06T08:04:13.000Z",
                    "thread": 0,
                    "sequence": 48911,
                    "offset": 156909584,
                    "csn": 2704619209735,
                    "name": null
                },
                "boundedRecoveryEnd": {
                    "timestamp": "2026-06-06T08:08:45.000Z",
                    "thread": 1,
                    "sequence": 48912,
                    "offset": 156918384,
                    "csn": 2704619308743,
                    "name": null
                }
            }
        ]
    }
}

And to finish with, from the json, you can retrieve the SCN of the recovery checkpoint:

>>> recovery_checkpoint_scn = extract_checkpoints['current']['input'][0]['recovery']['csn']
>>> recovery_checkpoint_scn
2704619209735

Whether it’s to rename or move an extract, you now know why you should check long running transactions in GoldenGate, and how to do it from the adminclient and the REST API.

L’article Checking Long Running Transactions in GoldenGate est apparu en premier sur dbi Blog.

In this GoldenGate upgrade, the previous driver was version 11.1 and the target version was 12.1. After installing the new driver, db2cli execsql commands that previously worked started failing with the following error:

db2cli execsql -db <database_alias> -user <username> -passwd <password> \
  -inputsql /home/oracle/input.sql

Where /home/oracle/input.sql just contains a trivial test query:

select 1 from sysibm.sysdummy1;

The sysibm.sysdummy1 table is DB2’s equivalent of Oracle’s DUAL, so this is about the simplest query you can run to check connectivity. It failed with the following error:

SQLError: 1 = 0 (SQL_SUCCESS)
SQLGetDiagRec: SQLState : 42968
NativeError : -1598
DiagMsg: [IBM][CLI Driver] SQL1598N An attempt to connect to the database server failed because of a licensing problem. SQLSTATE=42968

What SQL1598N means

SQL1598N means the DB2 client does not have a valid license to connect to this database. The CLI driver loaded fine. But when it tried to establish an authenticated connection the server rejected it on licensing grounds.

This is distinct from a connection failure or an authentication failure.

Root cause

It might not be obvious for Oracle-accustomed DBAs, but the DB2 CLI Driver does not ship with a license file for connecting to DB2 for z/OS. A separate license file named db2consv_zs.lic must be placed manually in the clidriver/license/ directory of the driver installation.

The critical point is that the license file is version-specific and cannot be reused across driver versions. The license file that worked with driver 11.1 is not valid for driver 12.1. After upgrading the driver, the new installation directory does not contain the license file in the license/ folder, and copying the old license file into it will not resolve the error.

Observed behavior

The error was reproducible every time the same command was run against the new driver. For reference, a successful run against a properly licensed driver returns:

FetchAll: Columns: 1
1
1
FetchAll: 1 rows fetched.

License file location

It is important to keep in mind that the license file belongs in the license/ subdirectory of the CLI driver installation. With CLI driver 11.1, the path looked like:

/opt/ibm/db2_odbc_cli_11_1/clidriver/license/db2consv_zs.lic

After upgrading to 12.1, the new driver has its own separate installation directory with its own license/ subdirectory. Placing the old 11.1 license file there will not work – the file is tied to the driver version.

How to fix the issue ?

Since the old file is unusable, you must obtain a new license file matching the installed driver version from IBM. Essentially, you have two options here:

• Contact your DB2 engineers: if someone on the team manages IBM software licenses, they should be able to provide the correct db2consv_zs.lic for the version you installed.
• Open a case with IBM customer support: IBM will provide the appropriate license file for the new driver version.

Once you have the correct file, place it in the clidriver/license/ directory of the new driver installation and retry the same db2cli execsql command given above. No restart is required.

DB2 CLI drivers are not that complicated to use and to debug. However, there are a few fundamentals that GoldenGate administrators should know before attempting a migration. Renewing the license file is one of them.

L’article DB2 SQL1598N Licensing Error When Upgrading GoldenGate est apparu en premier sur dbi Blog.

The client’s GoldenGate extract was running on a dedicated server, capturing changes from an Oracle 19c source database. Trail files were written on an NFS. Depending on the configuration, this is officially supported by Oracle, and works rather well.

OGG-02897 / OGG-01668 Input/Output Error

On a Monday morning, however, the extract was ABENDED. The extract had been down since Saturday night, with the following error messages:

2026-06-07T00:19:11.404+0200  ERROR   OGG-02897  Oracle GoldenGate Capture for Oracle, EXT.prm:  Failed to synchronize trail file. Error detail: Could not sync "PDB1/aa000000009" (error 5, Input/output error).
2026-06-07T00:19:11.404+0200  ERROR   OGG-01668  Oracle GoldenGate Capture for Oracle, EXT.prm:  PROCESS ABENDING.

The extract was failing with an OGG-02897 error. The OS-level error, errno 5: Input/output error, did not seem to indicate any good news for us. Needless to say that restarting the extract did not fix the issue.

Root Cause Analysis

A firewall upgrade had taken place that Saturday night. The firewall between the GoldenGate server and the NFS server was upgraded, and it briefly went down during the operation.

The real problem was what happened after the firewall came back up: some extracts caught up and managed to restart properly, while other were left in this ABENDED state, unable to restart. For these extracts, I/O operations kept failing even though the network path was healthy again.

Solution: Remount the NFS

The solution was to stop all GoldenGate processes whose trail files were generated on the NFS, including all the processes which were running fine, and then unmount and remount the NFS filesystem.

# Unmount the NFS path
umount /path/to/nfs

# Remount all filesystems defined in /etc/fstab, including the NFS
mount -a

Once that came back up, I restarted the extracts from the adminclient and they all started successfully.

In this case, the firewall upgrade happened during the night with no GoldenGate-aware procedure in place. Next time, a scheduled GoldenGate maintenance spanning over the firewall upgrade window will probably avoid crashing multiple replications during the week-end, or worse.

L’article GoldenGate Extract Abending on NFS Trail: OGG-02897 / OGG-01668 Input/Output Error est apparu en premier sur dbi Blog.

As you can see in the Product info it also has “Oracle Server – Standard Edition”. However, I haven’t found anything official yet.

I tried it and could install 23.26.3. as a Standard Edition ORACLE_HOME:

[oracle@oel10db26ai dbhome_1]$ mkdir -p /u01/app/oracle/product/26.0.0/dbhome_1
[oracle@oel10db26ai dbhome_1]$ cd /u01/app/oracle/product/26.0.0/dbhome_1
[oracle@oel10db26ai dbhome_1]$ unzip -q /tmp/p39581612_230000_Linux-x86-64.zip
[oracle@oel10db26ai dbhome_1]$ vi install/response/db_install_26ai.rsp
[oracle@oel10db26ai dbhome_1]$ cat install/response/db_install_26ai.rsp
oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v23.0.0
installOption=INSTALL_DB_SWONLY
UNIX_GROUP_NAME=oinstall
INVENTORY_LOCATION=/u01/app/oraInventory
ORACLE_HOME=/u01/app/oracle/product/26.0.0/dbhome_1
ORACLE_BASE=/u01/app/oracle
installEdition=SE2
OSDBA=oinstall
OSOPER=oinstall
OSBACKUPDBA=oinstall
OSDGDBA=oinstall
OSKMDBA=oinstall
OSRACDBA=oinstall
executeRootScript=false
dbType=GENERAL_PURPOSE
[oracle@oel10db26ai dbhome_1]$ 

[oracle@oel10db26ai dbhome_1]$ ./runInstaller -ignorePrereq -waitforcompletion -silent -responseFile install/response/db_install_26ai.rsp
Launching Oracle AI Database Setup Wizard...
...
[WARNING] [INS-13014] Target environment does not meet some optional requirements.
   CAUSE: Some of the optional prerequisites are not met. See logs for details. installActions2026-08-04_07-18-59PM.log.
   ACTION: Identify the list of failed prerequisite checks from the log: installActions2026-08-04_07-18-59PM.log. Then either from the log file or from installation manual find the appropriate configuration to meet the prerequisites and fix it manually.
The response file for this session can be found at:
 /u01/app/oracle/product/26.0.0/dbhome_1/install/response/db_2026-08-04_07-18-59PM.rsp

You can find the log of this install session at:
 /tmp/InstallActions2026-08-04_07-18-59PM/installActions2026-08-04_07-18-59PM.log


As a root user, run the following script(s):
	1. /u01/app/oraInventory/orainstRoot.sh
	2. /u01/app/oracle/product/26.0.0/dbhome_1/root.sh

Run /u01/app/oraInventory/orainstRoot.sh on the following nodes: 
[oel10db26ai]
Run /u01/app/oracle/product/26.0.0/dbhome_1/root.sh on the following nodes: 
[oel10db26ai]


Successfully Setup Software with warning(s).
Moved the install session logs to:
 /u01/app/oraInventory/logs/InstallActions2026-08-04_07-18-59PM
[oracle@oel10db26ai dbhome_1]$ 

After running the root-scripts I created a Database and verified that it is really a Standard Edition 2 DB:

[root@oel10db26ai ~]# mkdir /u02
[root@oel10db26ai ~]# chown oracle:oinstall /u02
[root@oel10db26ai ~]# 

[oracle@oel10db26ai ~]$ mkdir /u02/oradata
[oracle@oel10db26ai ~]$ 
[oracle@oel10db26ai ~]$ . oraenv
ORACLE_SID = [oracle] ? dummyx
ORACLE_HOME = [/home/oracle] ? /u01/app/oracle/product/26.0.0/dbhome_1
The Oracle base has been set to /u01/app/oracle
[oracle@oel10db26ai ~]$ 

[oracle@oel10db26ai ~]$ export ORACLE_SID=DB26SE2
[oracle@oel10db26ai ~]$ export PDB_NAME=pdb1
[oracle@oel10db26ai ~]$ export DATA_DIR=/u02/oradata

[oracle@oel10db26ai ~]$ dbca -silent -createDatabase                                                   \
     -templateName General_Purpose.dbc                                         \
     -gdbname ${ORACLE_SID} -sid  ${ORACLE_SID} -responseFile NO_VALUE         \
     -characterSet AL32UTF8                                                    \
     -sysPassword HEllo01__01                                                 \
     -systemPassword HEllo01__01                                              \
     -createAsContainerDatabase true                                           \
     -numberOfPDBs 1                                                           \
     -pdbName ${PDB_NAME}                                                      \
     -pdbAdminPassword HEllo01__01                                            \
     -databaseType MULTIPURPOSE                                                \
     -memoryMgmtType auto_sga                                                  \
     -totalMemory 2000                                                         \
     -storageType FS                                                           \
     -datafileDestination "${DATA_DIR}"                                        \
     -redoLogFileSize 100                                                       \
     -emConfiguration NONE                                                     \
     -ignorePreReqs
...

[oracle@oel10db26ai ~]$ sqlplus / as sysdba

SQL*Plus: Release 23.26.3.0.0 - Production on Wed Aug 5 10:42:48 2026
Version 23.26.3.0.0

Copyright (c) 1982, 2026, Oracle.  All rights reserved.


Connected to:
Oracle AI Database 26ai Standard Edition 2 Release 23.26.3.0.0 - Production
Version 23.26.3.0.0

SQL> select banner from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle AI Database 26ai Standard Edition 2 Release 23.26.3.0.0 - Production

SQL> show pdbs

    CON_ID CON_NAME			  OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
	 2 PDB$SEED			  READ ONLY  NO
	 3 PDB1 			  READ WRITE NO
SQL> show parameter control_management_pack_access

NAME				     TYPE	 VALUE
------------------------------------ ----------- ------------------------------
control_management_pack_access	     string	 NONE
SQL> 

It really seems a Standard Edition 2 DB. But let me check if it restricts me for a command not allowed in SE2:

SQL> select min(snap_id), max(snap_id) from dba_hist_snapshot;

MIN(SNAP_ID) MAX(SNAP_ID)
------------ ------------
	   1	       14

SQL> var retval number;
SQL> exec :retval:=dbms_spm.load_plans_from_awr(1,14);
BEGIN :retval:=dbms_spm.load_plans_from_awr(1,14); END;

*
ERROR at line 1:
ORA-38153: Software edition is incompatible with SQL plan management.
ORA-06512: at "SYS.DBMS_SPM", line 4009
ORA-06512: at "SYS.DBMS_SPM_INTERNAL", line 6479
ORA-06512: at "SYS.DBMS_SPM", line 3991
ORA-06512: at line 1
Help: https://docs.oracle.com/error-help/db/ora-38153/


SQL> ! oerr ora 38153
38153, 00000, "Software edition is incompatible with SQL plan management."
// *Cause: SQL plan management could be used only with Oracle Database Enterprise Edition.
// *Action: Ensure that Oracle is linked with the Enterprise Edition options.

Yes, it does not allow me to run a command, which is restricted for the use in Enterprise Edition DBs.

Summary

Oracle has released Release Update 23.26.3. recently for on-premises installations. According the download screen it contains the possibility to run a Standard Edition 2 DB with it. First tests showed that you really can use 23.26.3. as an ORACLE_HOME for Standard Edition 2 DBs. However, Oracle has not officially published this yet. Before using this release with a Standard Edition 2 DB I would recommend to wait for the official announcement from Oracle.

If there are news on this, I’ll update this Blog.

L’article Oracle: Standard Edition 2 available with 23.26.3.? est apparu en premier sur dbi Blog.

Bug 39415027: Generic – Simplified Distribution and Receiver Service Path Configuration

Enhanced the Create Distribution and Receiver Service Paths experience by introducing Simple and Advanced configuration modes. The simplified view displays only the required settings by default, while advanced options remain available for users who need additional configuration.

Anyone who has created a distribution path from the web UI knows the form used to be long. I already walked through the full setup in a previous blog on distribution paths in NGINX-secured deployments. This enhancement simplifies the creation form for most common use cases.

In this blog, I want to look at what changes: first in the web UI, then what the hidden fields default to, and finally whether anything changes at the REST API level.

What changes in the web UI

This enhancement is in fact two separate changes, shipped together.

First, the form collapsed to a single step. In 23.26.2 and earlier version of GoldenGate, creating a path was a six-step process: Path Information, Source Options, Target Options, Advanced Options, Filtering Options and Managed Options.

Starting with 23.26.3.0.0, these steps are gone. Instead, there are now only two steps: a configuration page, and a review page. Most of what used to be spread across the six screens now lives on the first page; the rest (the managed, format and network tuning options) moved onto the Review page, which is interactive rather than a read-only summary.

The second change is that this single page has a Default / Advanced toggle. This is the part the release notes mention:

Default mode: only the required settings are displayed, like path name, source (extract and trail) and target (host, port, protocol and target trail).

Advanced mode: the same single page, but every optional field is revealed: air gap security, trail file size, target type, HPE NonStop toggle, format options and network options. The reverse proxy toggle, encryption and filtering checkboxes are present in both modes (see below).

Switching to Advanced in 23.26.3 does not bring back the six steps. It stays on one page, revealing the hidden fields. Here are the two forms:

NB: The same Default / Advanced mechanism applies to the Receiver Service path creation form.

What do the hidden fields default to?

When Default mode hides a field, nothing is left blank. GoldenGate will silently apply a default value when calling the REST API. Knowing these defaults will help you decide whether to use the Default or the Advanced mode. Here is the list of what Advanced mode reveals.

So a path created in Default mode always gets a 2000 MB trail, no air gap security, and (for an ogg target) a Manager target type. If any of those needs to change, you should switch to Advanced mode.

The Review step carries the managed and tuning options

The second step (Review) is not a read-only summary. It always shows a summary of the path and an editable Managed Options section. In Advanced mode, it also shows Format options and a large Network Options section. The Default/Advanced mode toggle also changes what you see here:

To summarize, auto restart is on by default (10 retries, 2 minute delay) and you can adjust it without leaving Default mode. The network tuning parameters (compression, EOF delay, DSCP / TOS, TCP flags, socket buffers) keep their usual defaults unless you switch to Advanced mode and change them.

Default mode does not mean no security

The distribution path creation form is also adapted to the protocol you choose. Selecting the Target Protocol changes which fields appear, in both modes:

• ogg is the classic mode, without authentication fields. Advanced adds the Target Type and the HPE NonStop toggle.
• ws and wss: both add a reverse proxy toggle (disabled by default) and a Target Authentication Method: Certificate is the pre-selected value for wss. Switching to UserID Alias shows Domain: Network (greyed out, not editable) and an Alias dropdown (the same reserved Network domain used for path connection credentials).

Since GoldenGate 26ai, the default for trail file size is no longer 500 MB but 2000 MB. If you are fine with a 2000 MB trail, no air gap, a Manager target (for ogg protocol), and the default auto restart behaviour, you can keep the default mode. Switch to Advanced when you want a different trail size, air gap setup, a Collector or Receiver Service target, HPE NonStop, a specific target format, or any of the network tuning options.

Nothing changes in GoldenGate REST API

The Default / Advanced switch is purely a web UI convenience. It changes which fields the form renders, not what GoldenGate stores or how you create a path programmatically. The REST endpoints are unchanged:

If you automate distribution path creation (I will publish a blog about this soon) in your environments, nothing changes. The payload you send is identical before and after patching to 23.26.3.0.0.

From a web UI perspective, paths are created with the exact same payloads in Default and Advanced mode. For instance, I created one path from the web UI in Default mode (DEFPATH) and an equivalent one in Advanced mode (ADVPATH), with the same source and target, as well as every optional field left at its pre-filled value. Analyzing the restapi.log files, here is the content of the payload:

oracle@vmogg: jq -c 'select(.request.context.verb == "POST" and .request.context.uriTemplate == "/services/{version}/sources/{distpath}")' restapi.ndjson

Captured DEFPATH (Default mode), POST /services/v2/sources/DEFPATH:

{
  "name": "DEFPATH",
  "status": "stopped",
  "source": {
    "uri": "trail://localhost:7811/services/v2/sources?trail=e1",
    "details": {}
  },
  "target": {
    "isDynamicOggPort": true,
    "uri": "ogg://vmogg2:7812/services/v2/targets?trail=ea",
    "details": {
      "trail": { "seqLength": 9, "sizeMB": 2000 },
      "compression": { "enabled": false }
    }
  },
  "options": {
    "eofDelayCSecs": 10,
    "checkpointFrequency": 10,
    "critical": false,
    "autoRestart": { "retries": 10, "delay": 2 },
    "streaming": true
  },
  "begin": { "sequence": 0, "offset": 0 }
}

Captured ADVPATH (Advanced mode), POST /services/v2/sources/ADVPATH:

{
  "name": "ADVPATH",
  "status": "stopped",
  "source": {
    "uri": "trail://localhost:7811/services/v2/sources?trail=e1",
    "details": {}
  },
  "target": {
    "isDynamicOggPort": true,
    "uri": "ogg://vmogg2:7812/services/v2/targets?trail=eb",
    "details": {
      "trail": { "seqLength": 9, "sizeMB": 2000 },
      "compression": { "enabled": false }
    }
  },
  "options": {
    "eofDelayCSecs": 10,
    "checkpointFrequency": 10,
    "critical": false,
    "autoRestart": { "retries": 10, "delay": 2 },
    "streaming": true
  },
  "begin": { "sequence": 0, "offset": 0 }
}

The two bodies differ only in name and the target trail letter. Every optional key that Default mode is supposed to “hide” (sizeMB, seqLength, compression.enabled, eofDelayCSecs, checkpointFrequency, critical, autoRestart, streaming) is sent explicitly by both modes, with the same value.

If you work mostly from the web UI and create paths by hand, the new form will help you. And if you automate with the REST API, this enhancement does not affect you at all. Your existing calls keep working exactly as before, and you were already, in effect, in “advanced mode” because you send whatever properties you choose.

L’article Simplified Distribution Path Creation in GoldenGate 26.3 est apparu en premier sur dbi Blog.

Error:
Problem: The operation would result in removing the following protected packages: systemd
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

In this blog I would like to share the solution with you.

So I was just running dnf install, as described here:

[root@SRV ~]# dnf install libzstd
Last metadata expiration check: 0:03:23 ago on Tue 02 Jun 2026 04:18:15 PM CEST.
Package libzstd-1.4.4-1.0.1.el8.x86_64 is already installed.
Dependencies resolved.
=========================================================================================================================================================================================
Package                                     Architecture                               Version                                           Repository                                Size
=========================================================================================================================================================================================
Upgrading:
libzstd                                     x86_64                                     1.5.5-1.el7                                       epel                                     292 k

Transaction Summary
=========================================================================================================================================================================================
Upgrade  1 Package

Total download size: 292 k
Is this ok [y/N]: y
Downloading Packages:
[MIRROR] libzstd-1.5.5-1.el7.x86_64.rpm: Curl error (56): Failure when receiving data from the peer for https://fedora-archive.ip-connect.info/epel/7/x86_64/Packages/l/libzstd-1.5.5-1.el7.x86_64.rpm [Received HTTP code 403 from proxy after CONNECT]
[MIRROR] libzstd-1.5.5-1.el7.x86_64.rpm: Status code: 403 for http://fedora-archive.ip-connect.info/epel/7/x86_64/Packages/l/libzstd-1.5.5-1.el7.x86_64.rpm (IP: 172.16.1.200)
[MIRROR] libzstd-1.5.5-1.el7.x86_64.rpm: Curl error (56): Failure when receiving data from the peer for https://ftp-stud.hs-esslingen.de/pub/Mirrors/archive.fedoraproject.org/epel/7/x86_64/Packages/l/libzstd-1.5.5-1.el7.x86_64.rpm [Received HTTP code 403 from proxy after CONNECT]
[MIRROR] libzstd-1.5.5-1.el7.x86_64.rpm: Status code: 403 for http://ftp-stud.hs-esslingen.de/pub/Mirrors/archive.fedoraproject.org/epel/7/x86_64/Packages/l/libzstd-1.5.5-1.el7.x86_64.rpm (IP: 172.16.1.200)
libzstd-1.5.5-1.el7.x86_64.rpm                                                                                                                           384 kB/s | 292 kB     00:00
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                    306 kB/s | 292 kB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                                 1/1
  Upgrading        : libzstd-1.5.5-1.el7.x86_64                                                                                                                                      1/2
  Running scriptlet: libzstd-1.5.5-1.el7.x86_64                                                                                                                                      1/2
  Cleanup          : libzstd-1.4.4-1.0.1.el8.x86_64                                                                                                                                  2/2
  Running scriptlet: libzstd-1.4.4-1.0.1.el8.x86_64                                                                                                                                  2/2
  Verifying        : libzstd-1.5.5-1.el7.x86_64                                                                                                                                      1/2
  Verifying        : libzstd-1.4.4-1.0.1.el8.x86_64 

Unfortunately, I was too fast and did not realize dnf was using an el7 repo. And more over the command removed the proper el8 package to install the el7 package.

I agree, I should have pay attention and see:

Package libzstd-1.4.4-1.0.1.el8.x86_64 is already installed.

Or package version to be: 1.5.5-1.el7

Anyhow, I realized after having push y.

And trying to remove it, gave following error message:

[root@SRV ~]# dnf remove libzstd-1.5.5-1.el7.x86_64
Error:
Problem: The operation would result in removing the following protected packages: systemd
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)

So it seems it is a full mess now. But checking which installed rpm package requires libzstd, I was surprised to see none:

[root@SRV ~]# rpm -q --whatrequires libzstd
no package requires libzstd

The problem was that after a previous upgrade to Oracle linux 8, and as leapp upgrade does not remove custom repo, there was still an el7 customized repo, epel, activated.

[root@SRV ~]# cat /etc/yum.repos.d/epel.repo
[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
# It is much more secure to use the metalink, but if you wish to use a local mirror
# place its address here.
#baseurl=http://download.example/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch&infra=$infra&content=$contentdir
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

At that time, I asked one of my colleague having very good linux experience, Joel Cattin, who guided me to the resolution. I would like to take the opportunity here, to thank him again for the great help.

We first tried to cleanup the cache and to upgrade the package, but it did not helped:

[root@SRV yum.repos.d]# dnf clean all
66 files removed

[root@SRV yum.repos.d]# dnf make cache
No such command: make. Please use /usr/bin/dnf --help
It could be a DNF plugin command, try: "dnf install 'dnf-command(make)'"

[root@SRV yum.repos.d]# dnf upgrade libzstd
Oracle Linux 8 EPEL Packages for Development (x86_64)                                                                                                                        10 MB/s | 111 MB     00:10
Oracle Linux 8 EPEL Modular Packages for Development (x86_64)                                                                                                               2.3 MB/s | 332 kB     00:00
Oracle Linux 8 BaseOS Latest (x86_64)                                                                                                                                        10 MB/s | 143 MB     00:13
Oracle Linux 8 Application Stream (x86_64)                                                                                                                                   10 MB/s |  81 MB     00:07
Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)                                                                                                   11 MB/s | 146 MB     00:13
Dependencies resolved.
Nothing to do.
Complete!

[root@SRV yum.repos.d]# rpm -qa | grep -i el7
libzstd-1.5.5-1.el7.x86_64

Still getting the error:

[root@SRV yum.repos.d]# dnf remove libzstd
Error:
 Problem: The operation would result in removing the following protected packages: systemd
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
[root@SRV yum.repos.d]#

And we finally went to the magic command, dnf distro-sync, which will synchronize the installed package with the versions available in the enabled repositories, and most important the repository that should match the version. So in my case an el8 repo.

And this command did the work, removing the el7 package and installing the el8 version package.

[root@SRV ~]# dnf distro-sync libzstd
Last metadata expiration check: 0:23:38 ago on Wed 03 Jun 2026 07:27:26 AM CEST.
Dependencies resolved.
===========================================================================================================================================================================
 Package                             Architecture                       Version                                        Repository                                     Size
===========================================================================================================================================================================
Downgrading:
 libzstd                             x86_64                             1.4.4-1.0.1.el8                                ol8_baseos_latest                             266 k

Transaction Summary
===========================================================================================================================================================================
Downgrade  1 Package

Total download size: 266 k
Is this ok [y/N]: y
Downloading Packages:
libzstd-1.4.4-1.0.1.el8.x86_64.rpm                                                                                                         1.5 MB/s | 266 kB     00:00
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                      1.4 MB/s | 266 kB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                   1/1
  Downgrading      : libzstd-1.4.4-1.0.1.el8.x86_64                                                                                                                    1/2
  Cleanup          : libzstd-1.5.5-1.el7.x86_64                                                                                                                        2/2
  Running scriptlet: libzstd-1.5.5-1.el7.x86_64                                                                                                                        2/2
  Verifying        : libzstd-1.4.4-1.0.1.el8.x86_64                                                                                                                    1/2
  Verifying        : libzstd-1.5.5-1.el7.x86_64                                                                                                                        2/2

Downgraded:
  libzstd-1.4.4-1.0.1.el8.x86_64

Complete!

And finally, I did not have any remaining el7 package. The version of libzstd package was one from the ol8 distribution.

[root@SRV ~]# rpm -qa | grep -i el7
[root@SRV ~]# rpm -qa | grep -i libzstd
libzstd-1.4.4-1.0.1.el8.x86_64
[root@SRV ~]#

And to avoid problem again, I did what should be done after all leapp upgrade… Removing any el7 repo, in my case the epel el7 repo:

[root@SRV ~]# rpm -qa | grep -i epel
epel-release-7-14.noarch
[root@SRV ~]# dnf remove epel-release-7-14.noarch
Dependencies resolved.
=========================================================================================================================================================================================
 Package                                          Architecture                               Version                                   Repository                                   Size
=========================================================================================================================================================================================
Removing:
 epel-release                                     noarch                                     7-14                                      @System                                      25 k

Transaction Summary
=========================================================================================================================================================================================
Remove  1 Package

Freed space: 25 k
Is this ok [y/N]: y
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                                 1/1
  Running scriptlet: epel-release-7-14.noarch                                                                                                                                        1/1
  Erasing          : epel-release-7-14.noarch                                                                                                                                        1/1
  Running scriptlet: epel-release-7-14.noarch                                                                                                                                        1/1
  Verifying        : epel-release-7-14.noarch                                                                                                                                        1/1

Removed:
  epel-release-7-14.noarch

Complete!

I again checked that no other el7 repo was enabled:

[root@SRV ~]# dnf repolist all --enabled
repo id                                                         repo name
ol8_UEKR6                                                       Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)
ol8_appstream                                                   Oracle Linux 8 Application Stream (x86_64)
ol8_baseos_latest                                               Oracle Linux 8 BaseOS Latest (x86_64)
[root@SRV ~]#

I installed the el8 epel repo, as customer was using it:

[root@SRV yum.repos.d]# dnf install oracle-epel-release-el8
Last metadata expiration check: 0:50:57 ago on Tue 02 Jun 2026 04:18:15 PM CEST.
Dependencies resolved.
=========================================================================================================================================================================================
 Package                                              Architecture                        Version                                   Repository                                      Size
=========================================================================================================================================================================================
Installing:
 oracle-epel-release-el8                              x86_64                              1.0-5.el8                                 ol8_baseos_latest                               15 k

Transaction Summary
=========================================================================================================================================================================================
Install  1 Package

Total download size: 15 k
Installed size: 18 k
Is this ok [y/N]: y
Downloading Packages:
oracle-epel-release-el8-1.0-5.el8.x86_64.rpm                                                                                                             136 kB/s |  15 kB     00:00
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                    134 kB/s |  15 kB     00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Preparing        :                                                                                                                                                                 1/1
  Installing       : oracle-epel-release-el8-1.0-5.el8.x86_64                                                                                                                        1/1
  Verifying        : oracle-epel-release-el8-1.0-5.el8.x86_64                                                                                                                        1/1

Installed:
  oracle-epel-release-el8-1.0-5.el8.x86_64

Complete!

And checked again the enabled repo to ensure there is only el8 repo with now the epel el8 repo as additional one:

[root@SRV yum.repos.d]# dnf repolist all --enabled
repo id                                                              repo name
ol8_UEKR6                                                            Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)
ol8_appstream                                                        Oracle Linux 8 Application Stream (x86_64)
ol8_baseos_latest                                                    Oracle Linux 8 BaseOS Latest (x86_64)
ol8_developer_EPEL                                                   Oracle Linux 8 EPEL Packages for Development (x86_64)
ol8_developer_EPEL_modular                                           Oracle Linux 8 EPEL Modular Packages for Development (x86_64)
[root@SRV yum.repos.d]#

And last repo check in the repo files directly:

[root@SRV ~]# ls -ltrh /etc/yum.repos.d/
total 40K
-rw-r--r--. 1 root root  530 Mar 28  2022 oracle-epel-ol8.repo
-rw-r--r--. 1 root root  243 May 23  2024 virt-ol8.repo
-rw-r--r--. 1 root root 1.4K Apr 22  2025 epel-testing.repo
-rw-r--r--. 1 root root 1.8K Apr 22  2025 epel-testing-modular.repo
-rw-r--r--. 1 root root 1.7K Apr 22  2025 epel-modular.repo
-rw-r--r--. 1 root root 4.5K Sep 19  2025 leapp-upgrade-repos-ol8.repo.save
-rw-r--r--. 1 root root 4.1K Jun  2 13:46 oracle-linux-ol8.repo
-rw-r--r--. 1 root root  941 Jun  2 13:46 uek-ol8.repo

[root@SRV ~]# rm -f /etc/yum.repos.d/leapp-upgrade-repos-ol8.repo.save

[root@SRV ~]# grep -i el7 /etc/yum.repos.d/*
[root@SRV ~]# grep -i el8 /etc/yum.repos.d/* | wc -l
6
[root@SRV ~]# grep -i ol8 /etc/yum.repos.d/* | wc -l
50
[root@SRV ~]# grep -i ol7 /etc/yum.repos.d/* | wc -l
0
[root@SRV ~]#

L’article Removing rpm with dnf implies removing systemd est apparu en premier sur dbi Blog.

There are unfinished DB8actions remaining. You might consider running yum-complete-DB8action, or "yum-complete-DB8action --cleanup-only" and "yum history redo last", first to finish them. If those don't work you'll have to try removing/installing packages by hand (maybe package-cleanup can help).

And I was wondering how to deal with this. I would like in this blog share with you my troubleshooting, as it might help someone sooner than later.

I was at that time running el7 and it was before upgrading the machine to el8. Let me first share with you the error message:

[root@SRV ~]# yum remove mariadb-libs-5.5.65-1.el7.x86_64
Loaded plugins: ulninfo
Resolving Dependencies
There are unfinished DB8actions remaining. You might consider running yum-complete-DB8action, or "yum-complete-DB8action --cleanup-only" and "yum history redo last", first to finish them. If those don't work you'll have to try removing/installing packages by hand (maybe package-cleanup can help).
--> Running DB8action check
---> Package mariadb-libs.x86_64 1:5.5.65-1.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================================================================================================
 Package                                           Arch                                        Version                                             Repository                                          Size
============================================================================================================================================================================================================
Removing:
 mariadb-libs                                      x86_64                                      1:5.5.65-1.el7                                      @anaconda/7.8                                      4.4 M

DB8action Summary
============================================================================================================================================================================================================
Remove  1 Package

Installed size: 4.4 M
Is this ok [y/N]: N
Exiting on user command
Your DB8action was saved, rerun it with:
 yum load-DB8action /tmp/yum_save_tx.2026-06-17.16-16.CupcSE.yumtx
[root@SRV ~]#

I ran a yum history command:

[root@SRV ~]# yum history
Loaded plugins: ulninfo
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    26 | root               | 2026-06-17 15:17 | E, I, U        |  184 EE
    25 | root               | 2026-06-17 14:59 | Install        |   25
    24 | root               | 2026-06-17 14:59 | Update         |    1
    23 | root               | 2026-05-07 15:21 | Install        |    1
    22 |                  | 2022-11-18 10:42 | Install        |    1
    21 |                  | 2022-11-18 09:56 | Install        |    1
    20 | root               | 2021-11-10 11:24 | Install        |    7
    19 | root               | 2021-10-26 16:54 | Install        |    1
    18 | root               | 2021-10-26 16:54 | Install        |    1
    17 | root               | 2021-10-26 16:54 | Install        |    1
    16 | root               | 2021-10-26 16:53 | Install        |    1
    15 | root               | 2021-04-08 09:30 | Install        |   14
    14 |                  | 2021-03-19 11:28 | Install        |    1
    13 | root               | 2021-01-21 11:36 | Install        |    2
    12 | root               | 2021-01-21 10:53 | Erase          |    1
    11 | root               | 2021-01-21 10:28 | E, I, U        |   37 EE
    10 | root               | 2020-11-26 11:13 | Install        |    2
     9 | root               | 2020-11-16 14:41 | I, U           |    8 PP
     8 | root               | 2020-11-16 14:35 | I, U           |  152 **
     7 |                 | 2020-10-28 15:45 | Install        |    1
history list
[root@SRV ~]# 

If I check the last transaction, it is successful. For sure, I have just run it.

[root@SRV ~]# yum history info 26 | grep Return-Code
Return-Code    : Success
[root@SRV ~]#

But if I check the transaction id 8, I see that this one was aborted:

[root@SRV ~]# yum history info 8 | grep Return-Code
Return-Code    : ** Aborted **

If I look to the RPM database changes log dated for this transaction I see the following file:

[root@SRV ~]# ls -l /var/lib/yum/DB8action-*
-rw-r--r--. 1 root root 13671 Nov 16  2020 /var/lib/yum/DB8action-all.2020-11-16.14:35.57
-rw-r--r--. 1 root root  9424 Nov 16  2020 /var/lib/yum/DB8action-done.2020-11-16.14:35.57
[root@SRV ~]#

I can check it’s content…

[root@SRV ~]# tail /var/lib/yum/DB8action-all.2020-11-16.14:35.57
erase 0:file-libs-5.11-36.el7.x86_64
erase 0:iptables-1.4.21-34.el7.x86_64
erase 2:vim-minimal-7.4.629-6.0.1.el7.x86_64
erase 0:libxml2-2.9.1-6.0.1.el7.4.x86_64
erase 0:libteam-1.29-1.el7.x86_64
erase 0:mokutil-15-2.0.3.el7.x86_64
erase 0:numactl-libs-2.0.12-5.el7.x86_64
erase 1:dmidecode-3.2-3.el7.x86_64
erase 0:iprutils-2.4.17.1-3.el7.x86_64
erase 1:mariadb-libs-5.5.65-1.el7.x86_64

[root@SRV ~]# tail  /var/lib/yum/DB8action-done.2020-11-16.14:35.57
erase 999:iwl7260-firmware-22.0.7.0-999.4.el7.noarch
erase 0:ca-certificates-2019.2.32-76.el7_7.noarch
erase 999:iwl6000g2a-firmware-17.168.5.3-999.4.el7.noarch
erase 999:iwl5000-firmware-8.83.5.1_1-999.4.el7.noarch
erase 999:iwl100-firmware-39.31.5.1-999.4.el7.noarch
erase 1:NetworkManager-tui-1.18.8-1.el7.x86_64
erase 0:rpm-python-4.11.3-43.el7.x86_64
erase 1:NetworkManager-glib-1.18.8-1.el7.x86_64
erase 32:bind-utils-9.11.4-26.P2.el7.x86_64
erase 7:lvm2-2.02.186-7.0.1.el7.x86_64
[root@SRV ~]#

Let’s take mariadb-libs RPM as example. Checking this package, I can see that it is duplicated.

[root@SRV ~]# rpm -q --last mariadb-libs
mariadb-libs-5.5.68-1.el7.x86_64              Mon 16 Nov 2020 02:38:01 PM CET
mariadb-libs-5.5.65-1.el7.x86_64              Wed 28 Oct 2020 10:39:07 AM CET
[root@SRV ~]#

Having duplicated RPM is not good. I suspect it is coming from this aborted yum transaction, old for past 6 years.

Let’s check if there is several other duplicated RPM.

[root@SRV ~]# package-cleanup --dupes
libcroco-0.6.12-6.el7_9.x86_64
libcroco-0.6.12-4.el7.x86_64
lz4-1.8.3-1.el7.x86_64
lz4-1.7.5-3.el7.x86_64
iprutils-2.4.17.1-3.el7.x86_64
iprutils-2.4.17.1-3.el7_7.x86_64
numactl-libs-2.0.12-5.el7.x86_64
numactl-libs-2.0.12-5.0.3.el7.x86_64
file-libs-5.11-36.el7.x86_64
file-libs-5.11-37.el7.x86_64
sed-4.2.2-6.el7.x86_64
sed-4.2.2-7.el7.x86_64
lshw-B.02.18-17.el7.x86_64
lshw-B.02.18-14.el7.x86_64
file-5.11-36.el7.x86_64
file-5.11-37.el7.x86_64
kmod-20-28.0.1.el7.x86_64
kmod-20-28.0.3.el7.x86_64
coreutils-8.22-24.0.1.el7.x86_64
coreutils-8.22-24.0.1.el7_9.2.x86_64
dbus-libs-1.10.24-13.0.1.el7_6.x86_64
dbus-libs-1.10.24-15.0.1.el7.x86_64
elfutils-libelf-0.176-5.el7.x86_64
elfutils-libelf-0.176-4.el7.x86_64
freetype-2.8-14.el7.x86_64
freetype-2.8-14.el7_9.1.x86_64
plymouth-core-libs-0.8.9-0.34.20140113.0.1.el7.x86_64
plymouth-core-libs-0.8.9-0.33.20140113.0.1.el7.x86_64
cpio-2.11-27.el7.x86_64
cpio-2.11-28.el7.x86_64
kmod-libs-20-28.0.3.el7.x86_64
kmod-libs-20-28.0.1.el7.x86_64
libpng-1.5.13-8.el7.x86_64
libpng-1.5.13-7.el7_2.x86_64
libteam-1.29-1.el7.x86_64
libteam-1.29-3.el7.x86_64
elfutils-libs-0.176-4.el7.x86_64
elfutils-libs-0.176-5.el7.x86_64
dbus-1.10.24-13.0.1.el7_6.x86_64
dbus-1.10.24-15.0.1.el7.x86_64
mariadb-libs-5.5.65-1.el7.x86_64
mariadb-libs-5.5.68-1.el7.x86_64
elfutils-default-yama-scope-0.176-5.el7.noarch
elfutils-default-yama-scope-0.176-4.el7.noarch
teamd-1.29-3.el7.x86_64
teamd-1.29-1.el7.x86_64
device-mapper-persistent-data-0.8.5-2.el7.x86_64
device-mapper-persistent-data-0.8.5-3.el7_9.2.x86_64
[root@SRV ~]#

Yes there are and many!

For each of the rpm, I ran following query to find the latest one.

[root@SRV ~]# rpm -q --last lz4
lz4-1.8.3-1.el7.x86_64                        Mon 16 Nov 2020 02:36:12 PM CET
lz4-1.7.5-3.el7.x86_64                        Wed 28 Oct 2020 10:34:25 AM CET
[root@SRV ~]# 

And decided to remove the last oldest version. For each yum remove command, I ensured there were no dependencies issues.

[root@SRV ~]# yum remove lz4-1.7.5-3.el7.x86_64
Loaded plugins: ulninfo
Resolving Dependencies
There are unfinished DB8actions remaining. You might consider running yum-complete-DB8action, or "yum-complete-DB8action --cleanup-only" and "yum history redo last", first to finish them. If those don't work you'll have to try removing/installing packages by hand (maybe package-cleanup can help).
--> Running DB8action check
---> Package lz4.x86_64 0:1.7.5-3.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================================================================================================================================
 Package                                        Arch                                              Version                                                 Repository                                                Size
=========================================================================================================================================================================================================================
Removing:
 lz4                                            x86_64                                            1.7.5-3.el7                                             @anaconda/7.8                                            358 k

DB8action Summary
=========================================================================================================================================================================================================================
Remove  1 Package

Installed size: 358 k
Is this ok [y/N]: y
Downloading packages:
Running DB8action check
Running DB8action test
DB8action test succeeded
Running DB8action
  Erasing    : lz4-1.7.5-3.el7.x86_64                                                                                                                                                                                1/1
  Verifying  : lz4-1.7.5-3.el7.x86_64                                                                                                                                                                                1/1

Removed:
  lz4.x86_64 0:1.7.5-3.el7

Complete!

I did that for all until having no duplicated any more.

[root@SRV ~]# package-cleanup --dupes
[root@SRV ~]#

So the duplicated came for sure due to this aborted transaction, id 8 that should have replaced the previous version package.

And I can confirm it. If I look to the all DB action transaction log for this transaction 8, /var/lib/yum/DB8action-all.2020-11-16.14:35.57, I can find both install and erase:

[root@SRV ~]# cat /var/lib/yum/DB8action-all.2020-11-16.14:35.57
install 1:mariadb-libs-5.5.68-1.el7.x86_64
...
erase 1:mariadb-libs-5.5.65-1.el7.x86_64

So it was planned that yum installs new version and removes old one.

But if I look to the done file, /var/lib/yum/DB8action-done.2020-11-16.14:35.57, file showing what really yum did, I will only find the install and not the erase:

[root@SRV ~]# cat /var/lib/yum/DB8action-done.2020-11-16.14:35.57
...
install 1:mariadb-libs-5.5.68-1.el7.x86_64
...

So the intention was to install version 5.5.68 and remove old 5.5.65, but as the yum transaction was aborted after the installation package, yum only installed 5.5.68 but could not remove the old one 5.5.65, thus the duplicated. Yum transaction was aborted in between.

Knowing I resolved manually the duplication, I decided to complete the aborted transaction by just doing cleanup.

[root@SRV ~]# yum-complete-DB8action --cleanup-only
Cleaning up unfinished DB8action journals
Cleaning up 2020-11-16.14:35.57
[root@SRV ~]#

cleanup-only will simply delete the stale journal. Knowing I manually resolved the problem, I think it was the right think to do.

And now I’m clean…

[root@SRV ~]# yum update
Loaded plugins: ulninfo
No packages marked for update
[root@SRV ~]#

L’article Oracle Linux – Unfinished DB8actions remaining est apparu en premier sur dbi Blog.

I would like to share with you the reason and how to resolve it.

Problem description

After in-place Oracle linux upgrade from el7 to el8, I could see that the oracle service was not working any more. This service is used to automatically start and stop the databases during server reboot according to the entry in the /etc/oratab.

Here is the initial script:

[root@SRV ~]# cat /usr/lib/systemd/system/oracle.service
[Unit]
Description=Oracle Database Service
After=syslog.target network.target

[Service]
LimitMEMLOCK=infinity
LimitNOFILE=65535
Type=simple
RemainAfterExit=yes
User=oracle
Group=oinstall
ExecStart=/rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh start
ExecStop=/rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh stop
TimeoutStartSec=200s
TimeoutStopSec=200s

[Install]
WantedBy=multi-user.target

As we can see the service goes in error when running start and stop:

[root@SRV ~]# systemctl stop oracle.service
[root@SRV ~]# systemctl status oracle.service
● oracle.service - Oracle Database Service
   Loaded: loaded (/usr/lib/systemd/system/oracle.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2026-06-18 10:52:43 CEST; 2s ago
  Process: 33420 ExecStop=/rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh stop (code=exited, status=203/EXEC)
 Main PID: 1949 (code=exited, status=0/SUCCESS)

Jun 18 09:43:29 SRV.INT.custname.CH service_start_stop.ksh[8220]: 2026-06-18_09:43:29::database.ksh::SetOraEnv            ::INFO ==> Environment: DB6 (/rdbms/u01/app/oracle/product/19.>
Jun 18 09:43:29 SRV.INT.custname.CH service_start_stop.ksh[8221]: ls: cannot access '/rdbms/u01/app/oracle/admin/DB6/dmk/pdbs/': No such file or directory
Jun 18 09:43:29 SRV.INT.custname.CH service_start_stop.ksh[8229]: 2026-06-18_09:43:29::database.ksh::ProcessAllDB         ::INFO ==> START database DB6
Jun 18 09:43:29 SRV.INT.custname.CH service_start_stop.ksh[8237]: 2026-06-18_09:43:29::database.ksh::ProcessAllDB         ::INFO ==> Database DB6 not started as the ORATAB flag is "N"
Jun 18 09:43:31 SRV.INT.custname.CH service_start_stop.ksh[9889]: 2026-06-18_09:43:31::service_start_stop.ksh::ExecScripts ::INFO ==> Return Code : 0
Jun 18 09:43:31 SRV.INT.custname.CH service_start_stop.ksh[9897]: 2026-06-18_09:43:31::service_start_stop.ksh::CleanExit  ::INFO ==> Program exited with ExitCode : 0
Jun 18 10:52:43 SRV.INT.custname.CH systemd[1]: Stopping Oracle Database Service...
Jun 18 10:52:43 SRV.INT.custname.CH systemd[1]: oracle.service: Control process exited, code=exited status=203
Jun 18 10:52:43 SRV.INT.custname.CH systemd[1]: oracle.service: Failed with result 'exit-code'.
Jun 18 10:52:43 SRV.INT.custname.CH systemd[1]: Stopped Oracle Database Service.

[root@SRV ~]# systemctl start oracle.service
[root@SRV ~]# systemctl status oracle.service
● oracle.service - Oracle Database Service
   Loaded: loaded (/usr/lib/systemd/system/oracle.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2026-06-18 10:53:06 CEST; 1s ago
  Process: 33420 ExecStop=/rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh stop (code=exited, status=203/EXEC)
  Process: 33428 ExecStart=/rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh start (code=exited, status=203/EXEC)
 Main PID: 33428 (code=exited, status=203/EXEC)

Jun 18 10:53:06 SRV.INT.custname.CH systemd[1]: Started Oracle Database Service.
Jun 18 10:53:06 SRV.INT.custname.CH systemd[1]: oracle.service: Main process exited, code=exited, status=203/EXEC
Jun 18 10:53:06 SRV.INT.custname.CH systemd[1]: oracle.service: Failed with result 'exit-code'.
[root@SRV ~]#

Analyzing the problem

Checking the output of journalctl command I could see following permission issue.

[root@SRV ~]# journalctl -xe
Jun 02 15:30:25 SRV.INT.custname.CH su[20823]: (to root) oracle on pts/0
Jun 02 15:30:25 SRV.INT.custname.CH su[20823]: pam_unix(su-l:session): session opened for user root by oracle(uid=54321)
Jun 02 15:30:29 SRV.INT.custname.CH systemd[1]: Started Oracle Database Service.
-- Subject: Unit oracle.service has finished start-up
-- Defined-By: systemd
-- Support: https://support.oracle.com
--
-- Unit oracle.service has finished starting up.
--
-- The start-up result is done.
Jun 02 15:30:29 SRV.INT.custname.CH systemd[20852]: oracle.service: Failed to execute command: Permission denied
Jun 02 15:30:29 SRV.INT.custname.CH systemd[20852]: oracle.service: Failed at step EXEC spawning /rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh: Permiss>
-- Subject: Process /rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh could not be executed

This problem comes from SELinux, where under el8 only binaries are authorized in the service and not shell script any more.

Solution

The solution is to add /bin/bash into both start and stop lines.

[root@SRV ~]# vi /usr/lib/systemd/system/oracle.service

[root@SRV ~]# cat /usr/lib/systemd/system/oracle.service
[Unit]
Description=Oracle Database Service
After=syslog.target network.target

[Service]
LimitMEMLOCK=infinity
LimitNOFILE=65535
Type=simple
RemainAfterExit=yes
User=oracle
Group=oinstall
ExecStart=/bin/bash /rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh start
ExecStop=/bin/bash /rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh stop
TimeoutStartSec=200s
TimeoutStopSec=200s

[Install]
WantedBy=multi-user.target
[root@SRV ~]#

And then the service could be successfully started and stopped again.

[root@SRV ~]# systemctl start oracle.service

[root@SRV ~]# systemctl status oracle.service
● oracle.service - Oracle Database Service
   Loaded: loaded (/usr/lib/systemd/system/oracle.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2026-06-18 10:54:52 CEST; 4s ago
 Main PID: 33585 (bash)
    Tasks: 52 (limit: 3295056)
   Memory: 127.8M
   CGroup: /system.slice/oracle.service
           ├─33585 /bin/bash /rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh start
           ├─33698 /bin/bash /rdbms/u01/app/oracle/local/dmk/bin/service_start_stop.ksh start
           ├─33855 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB1 -inherit
           ├─34041 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB2 -inherit
           ├─34227 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DG -inherit
           ├─34413 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB3 -inherit
           ├─34599 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB4 -inherit
           ├─34825 /rdbms/u01/app/oracle/product/19.30.260120_MX/bin/tnslsnr LISTENER_DB5 -inherit
           ├─35051 /rdbms/u01/app/oracle/product/19.30.260120_MX/bin/tnslsnr LISTENER_DB6 -inherit
...
...
...

To wrap up…

I took a lot of time to understand what could happen here, moreover it was working without any problem under el7. This is why I think it is good to know and decided to share it. I thank my collegue, Jérôme Witt, who could face this problem earlier and shared this good tips with me.

L’article Oracle database linux service not working properly after Oracle Linux upgrade est apparu en premier sur dbi Blog.

Backup your current server

Knowing we are going to run an in-place upgrade, it is important that we backup the server in order to restore it if something would not run smoothly.

There is several why to do this.

• You are running a VM and can take a snapshot. This is the easiest and quicker way to backup and restore.
• Take a full backup or image
• Have any tool like Veeam backup that will secure your operating system
• Look for existing free tool that will help you to create a bootable disaster recovery backup (to be previously tested)
• Perform a manual backup

What is also important is to ensure your backup is usable.

In my case, it was a physical server, no backup tool, no snapshot possibility. So I had to perform some manual backup.

• I ensured to have database backups and also my server was only running standby databases
• I wrote a script to save all the important linux configurations that will help me to restore the system reinstalling it from scratch if needed

Here is my script:

#!/bin/bash
#-----------------------------------------------------------------
#
# Author: Marc Wagner, dbi services
#
# Purpose:To backup OS configuration before OS patching
#
# To be run as root: ./OS_backup.sh
#
# History:
# 28.05.2026 - Initial
#
#
#-----------------------------------------------------------------

# Create backup directory if not existing
if [ ! -d "/rdbms/OS_backup" ]; then
    mkdir -p "/rdbms/OS_backup"
fi

# Backup OS configuration file into tar file
cd /
tar czpf /rdbms/OS_backup/ol7-os-backup-$(hostname)-$(date +%Y%m%d_%H%M).tgz \
--xattrs \
--acls \
./etc \
./boot \
./home \
./root \
./usr/local \
./var/spool/cron \
./opt \
./var/lib/rpm

# Backup Package inventory
rpm -qa > /rdbms/OS_backup/rpm-list-$(hostname)-$(date +%Y%m%d_%H%M).txt

# Backup current release version
cat /etc/oracle-release > /rdbms/OS_backup/OS-release-$(hostname)-$(date +%Y%m%d_%H%M).txt

# Backup Boot loader metadata
grub2-mkconfig -o /rdbms/OS_backup//grub-$(hostname)-$(date +%Y%m%d_%H%M).cfg
echo "*************************************" > /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# lsblk" >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
lsblk >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo  >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo  >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# lsblk -f" >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
lsblk -f >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo  >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo  >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# blkid" >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt
blkid >> /rdbms/OS_backup/lsblk-$(hostname)-$(date +%Y%m%d_%H%M).txt

# Backup service
systemctl list-unit-files > /rdbms/OS_backup/systemd-units-$(hostname)-$(date +%Y%m%d_%H%M).txt

# Backup live Network configuration
ip addr > /rdbms/OS_backup/ip-$(hostname)-$(date +%Y%m%d_%H%M).txt
ip route > /rdbms/OS_backup/routes-$(hostname)-$(date +%Y%m%d_%H%M).txt

# Backup LVM configuration
echo "*************************************" > /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# vgs" >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
vgs >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# lvs" >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
lvs >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# pvs" >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
pvs >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/LVM-$(hostname)-$(date +%Y%m%d_%H%M).txt

# SELinux
echo "*************************************" > /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# getenforce" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
getenforce >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# sestatus" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
sestatus >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# selinux config file" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
cat /etc/selinux/config >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# SELinux is enabled at kernel level?" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
cat /proc/cmdline | grep -i selinux >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "# detailed policy and booleans" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo "*************************************" >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
semanage boolean -l >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt
echo >> /rdbms/OS_backup/SELinux-$(hostname)-$(date +%Y%m%d_%H%M).txt

I ran the scripts:

[root@SRV scripts]# ./OS_backup.sh
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.17-2036.102.0.2.el7uek.x86_64
Found initrd image: /boot/initramfs-5.4.17-2036.102.0.2.el7uek.x86_64.img
Found linux image: /boot/vmlinuz-5.4.17-2036.100.6.1.el7uek.x86_64
Found initrd image: /boot/initramfs-5.4.17-2036.100.6.1.el7uek.x86_64.img
Found linux image: /boot/vmlinuz-4.14.35-2025.402.2.1.el7uek.x86_64
Found initrd image: /boot/initramfs-4.14.35-2025.402.2.1.el7uek.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-1160.11.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-1160.11.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-1160.6.1.el7.x86_64
Found linux image: /boot/vmlinuz-0-rescue-939798bf09ac467188081e34260fbcfd
Found initrd image: /boot/initramfs-0-rescue-939798bf09ac467188081e34260fbcfd.img
done
lsblk: nvme2c2n1: hidden, ignore
lsblk: nvme1c1n1: hidden, ignore
lsblk: nvme0c0n1: hidden, ignore
lsblk: nvme5c5n1: hidden, ignore
lsblk: nvme4c4n1: hidden, ignore
lsblk: nvme3c3n1: hidden, ignore
lsblk: nvme2c2n1: hidden, ignore
lsblk: nvme1c1n1: hidden, ignore
lsblk: nvme0c0n1: hidden, ignore
lsblk: nvme5c5n1: hidden, ignore
lsblk: nvme4c4n1: hidden, ignore
lsblk: nvme3c3n1: hidden, ignore
[root@SRV scripts]#

And I checked the backup files:

[root@SRV OS_backup]# pwd
/rdbms/OS_backup

[root@SRV OS_backup]# ls -ltrh
total 2.6G
-rw-r--r--. 1 root root 2.6G Jun 17 14:38 ol7-os-backup-SRV.INT.CUSTNAME.CH-20260617_1436.tgz
-rw-r--r--. 1 root root  17K Jun 17 14:38 rpm-list-SRV.INT.CUSTNAME.CH-20260617_1438.txt
-rw-r--r--. 1 root root   32 Jun 17 14:38 OS-release-SRV.INT.CUSTNAME.CH-20260617_1438.txt
-rw-r--r--. 1 root root 8.3K Jun 17 14:38 grub-SRV.INT.CUSTNAME.CH-20260617_1438.cfg
-rw-r--r--. 1 root root 9.0K Jun 17 14:38 lsblk-SRV.INT.CUSTNAME.CH-20260617_1438.txt
-rw-r--r--. 1 root root  16K Jun 17 14:38 systemd-units-SRV.INT.CUSTNAME.CH-20260617_1438.txt
-rw-r--r--. 1 root root 2.0K Jun 17 14:38 ip-SRV.INT.CUSTNAME.CH-20260617_1438.txt
-rw-r--r--. 1 root root  131 Jun 17 14:38 routes-SRV.INT.CUSTNAME.CH-20260617_1438.txt
-rw-r--r--. 1 root root 1.6K Jun 17 14:38 LVM-SRV.INT.CUSTNAME.CH-20260617_1438.txt
-rw-r--r--. 1 root root  26K Jun 17 14:38 SELinux-SRV.INT.CUSTNAME.CH-20260617_1438.txt
[root@SRV OS_backup]#

I also saved this file on a NFS mount point to get them out of the server.

Check Oracle Linux current version

I confirmed we are currently running OL 7.9.

[root@SRV scripts]# cat /etc/oracle-release
Oracle Linux Server release 7.9

Stop Oracle resources: databases and listener

Databases and listener need to be stop during the in-place upgrade process and we need to ensure that will not be started during reboot. We will therefore stop the oracle resources and update /etc/oratab.

Check current running oracle resources

oracle@SRV:~/ [rdbms193000] ps -ef | grep -i [p]mon
oracle    5761     1  0 14:12 ?        00:00:00 ora_pmon_DB6
oracle    5763     1  0 14:12 ?        00:00:00 ora_pmon_DB1
oracle    5767     1  0 14:12 ?        00:00:00 ora_pmon_DB8
oracle    5797     1  0 14:12 ?        00:00:00 ora_pmon_DB2
oracle    5803     1  0 14:12 ?        00:00:00 ora_pmon_DB7
oracle    5805     1  0 14:12 ?        00:00:00 ora_pmon_DB4
oracle    5807     1  0 14:12 ?        00:00:00 ora_pmon_DB3
oracle    5809     1  0 14:12 ?        00:00:00 ora_pmon_DB5
oracle    5855     1  0 14:12 ?        00:00:00 ora_pmon_DB9

oracle@SRV:~/ [rdbms193000] ps -ef | grep -i [t]nslsn
oracle    2316     1  0 14:12 ?        00:00:00 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB1 -inherit
oracle    2545     1  0 14:12 ?        00:00:00 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB2 -inherit
oracle    2731     1  0 14:12 ?        00:00:00 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DG -inherit
oracle    2938     1  0 14:12 ?        00:00:00 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB3 -inherit
oracle    3133     1  0 14:12 ?        00:00:00 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB4 -inherit
oracle    3416     1  0 14:12 ?        00:00:00 /rdbms/u01/app/oracle/product/19.30.260120_MX/bin/tnslsnr LISTENER_DB5 -inherit
oracle    3639     1  0 14:12 ?        00:00:00 /rdbms/u01/app/oracle/product/19.30.260120_MX/bin/tnslsnr LISTENER_DB6 -inherit
oracle    3822     1  0 14:12 ?        00:00:00 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB7 -inherit
oracle    4005     1  0 14:12 ?        00:00:00 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB8 -inherit
oracle    4189     1  5 14:12 ?        00:02:07 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB9 -inherit
oracle    4372     1  0 14:12 ?        00:00:00 /rdbms/u01/app/oracle/product/19.30.260120/bin/tnslsnr LISTENER_DB10 -inherit
oracle@SRV:~/ [rdbms193000]

Also I ensured all the running databases are standby databases (see below mo for mount status and mrp for physical standby database). Switchover has been run previously.

DB DB1 mo mrp /rdbms/u01/app/oracle/product/19.30.260120
DB DB2 mo mrp /rdbms/u01/app/oracle/product/19.30.260120
DB DB3 mo mrp /rdbms/u01/app/oracle/product/19.30.260120
DB DB4 mo mrp /rdbms/u01/app/oracle/product/19.30.260120
DB DB5 mo mrp /rdbms/u01/app/oracle/product/19.30.260120_MX
DB DB6 mo mrp /rdbms/u01/app/oracle/product/19.30.260120_MX
DB DB7 mo mrp /rdbms/u01/app/oracle/product/19.30.260120
DB DB8 mo mrp /rdbms/u01/app/oracle/product/19.30.260120
DB DB9 mo mrp /rdbms/u01/app/oracle/product/19.30.260120
DB DB10 of /rdbms/u01/app/oracle/product/19.30.260120

Update oratab

Put all DB to N in oratab to ensure they will not start automatically on reboot.

oracle@SRV:~/ [rdbms193000] vi /etc/oratab
oracle@SRV:~/ [rdbms193000] cat /etc/oratab
#



# This file is used by ORACLE utilities.  It is created by root.sh
# and updated by either Database Configuration Assistant while creating
# a database or ASM Configuration Assistant while creating ASM instance.

# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
#
# Entries are of the form:
#   $ORACLE_SID:$ORACLE_HOME::
#
# The first and second fields are the system identifier and home
# directory of the database respectively.  The third field indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.
#
# Multiple entries with the same $ORACLE_SID are not allowed.
#
#
DB10:/rdbms/u01/app/oracle/product/19.30.260120:N
DB3:/rdbms/u01/app/oracle/product/19.30.260120:N
DB9:/rdbms/u01/app/oracle/product/19.30.260120:N
DB4:/rdbms/u01/app/oracle/product/19.30.260120:N
DB1:/rdbms/u01/app/oracle/product/19.30.260120:N
DB8:/rdbms/u01/app/oracle/product/19.30.260120:N
DB7:/rdbms/u01/app/oracle/product/19.30.260120:N
DB2:/rdbms/u01/app/oracle/product/19.30.260120:N
DB5:/rdbms/u01/app/oracle/product/19.30.260120_MX:N
DB6:/rdbms/u01/app/oracle/product/19.30.260120_MX:N
oracle@SRV:~/ [rdbms193000]

Stop databases

I then stopped all databases. I was using our dmk tool, and I’m sure everybody knows how to stop Oracle databases. shutdown immediate command will make the job.

oracle@SRV:~/ [rdbms193000] database.ksh stop
2026-06-17_14:52:48::database.ksh::ProcessAllDB         ::INFO ==> Number of database(s) to process: 10
2026-06-17_14:52:48::database.ksh::ProcessAllDB         ::INFO ==> Number of available CPUs        : 16
2026-06-17_14:52:48::database.ksh::ProcessAllDB         ::INFO ==> Number of usable CPUs           : 15
2026-06-17_14:52:48::database.ksh::ProcessAllDB         ::INFO ==> Nbr of database(s) to process per CPU: 1
2026-06-17_14:52:48::database.ksh::ProcessAllDB         ::INFO ==> Nbr of database(s) undispached       : 0
...
2026-06-17_14:53:13::database.ksh::CheckStatus          ::INFO ==> Current Status for DB7 is ... stopped
2026-06-17_14:53:13::database.ksh::CheckStatus          ::INFO ==> Current Status for DB2 is ... stopped
2026-06-17_14:53:13::database.ksh::CheckStatus          ::INFO ==> Current Status for DB4 is ... stopped
2026-06-17_14:53:13::database.ksh::CheckStatus          ::INFO ==> Current Status for DB5 is ... stopped
2026-06-17_14:53:13::database.ksh::CheckStatus          ::INFO ==> Current Status for DB9 is ... stopped
oracle@SRV:~/ [rdbms193000]

Stop listeners

I also stopped all listeners. I used our dmk took but you could run lsnrctl stop command.

oracle@SRV:~/ [rdbms193000] listener.ksh stop
...
...
...
LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 17-JUN-2026 14:53:49

Copyright (c) 1991, 2025, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=TCP)(HOST=SRV.INT.custname.CH)(PORT=1560))
The command completed successfully
2026-06-17_14:53:49::listener.ksh::CheckStatus          ::INFO ==> Current Status for LISTENER_DB5 is ... stopped
2026-06-17_14:53:49::listener.ksh::DoCommand            ::INFO ==> Command Return Code : 0
2026-06-17_14:53:49::listener.ksh::DoCommand            ::INFO ==> STOP listener LISTENER_DB6
2026-06-17_14:53:49::listener.ksh::CheckStatus          ::INFO ==> Status for LISTENER_DB6 is ... started

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 17-JUN-2026 14:53:49

Copyright (c) 1991, 2025, Oracle.  All rights reserved.

Connecting to (ADDRESS=(PROTOCOL=TCP)(HOST=SRV.INT.custname.CH)(PORT=1561))
The command completed successfully
2026-06-17_14:53:49::listener.ksh::CheckStatus          ::INFO ==> Current Status for LISTENER_DB6 is ... stopped
2026-06-17_14:53:49::listener.ksh::DoCommand            ::INFO ==> Command Return Code : 0
2026-06-17_14:53:49::listener.ksh::CleanExit            ::INFO ==> Program exited with ExitCode : 0
oracle@SRV:~/ [rdbms193000]

Check Oracle running resources

Let’s ensure all Oracle resources have been stopped:

oracle@SRV:~/ [rdbms193000] ps -ef | grep -i [p]mon
oracle@SRV:~/ [rdbms193000] ps -ef | grep -i [t]nslsn
oracle@SRV:~/ [rdbms193000]

Install leapp

The in-place upgrade will be done with leapp. We need to install the leapp package.

I checked existing leapp package:

[root@SRV scripts]# rpm -qa | grep -i leapp
[root@SRV scripts]# 

Leapp package is not installed.

I installed the package and could see none is existing in current repo, and I do not have any leapp repo:

[root@SRV scripts]# yum install -y leapp-upgrade --enablerepo=ol7_leapp,ol7_latest
Loaded plugins: ulninfo
epel/x86_64/metalink                                                                                                                                               | 3.5 kB  00:00:00
ol7_UEKR6                                                                                                                                                          | 3.0 kB  00:00:00
ol7_latest                                                                                                                                                         | 3.6 kB  00:00:00
No package leapp-upgrade available.
Error: Nothing to do

[root@SRV scripts]# yum repolist all | grep -i leapp
[root@SRV scripts]#

[root@SRV scripts]# ls -ltrh /etc/yum.repos.d/
total 20K
-rw-r--r--. 1 root root  226 Oct  1  2020 virt-ol7.repo
-rw-r--r--. 1 root root 2.6K Oct  1  2020 uek-ol7.repo
-rw-r--r--. 1 root root 4.0K Oct  1  2020 oracle-linux-ol7.repo
-rw-r--r--. 1 root root 1.5K Sep  4  2021 epel-testing.repo
-rw-r--r--. 1 root root 1.4K Sep  4  2021 epel.repo
[root@SRV scripts]#

I updated the oraclelinux-release-el7 repository release package to last 1.0-17.el7 version:

[root@SRV scripts]# yum update oraclelinux-release-el7
Loaded plugins: ulninfo
Resolving Dependencies
There are unfinished DB8actions remaining. You might consider running yum-complete-DB8action, or "yum-complete-DB8action --cleanup-only" and "yum history redo last", first to finish them. If those don't work you'll have to try removing/installing packages by hand (maybe package-cleanup can help).
--> Running DB8action check
---> Package oraclelinux-release-el7.x86_64 0:1.0-13.1.el7 will be updated
---> Package oraclelinux-release-el7.x86_64 0:1.0-17.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

==========================================================================================================================================================================================
 Package                                                Arch                                  Version                                     Repository                                 Size
==========================================================================================================================================================================================
Updating:
 oraclelinux-release-el7                                x86_64                                1.0-17.el7                                  ol7_latest                                 22 k

DB8action Summary
==========================================================================================================================================================================================
Upgrade  1 Package

Total download size: 22 k
Is this ok [y/d/N]: y
Downloading packages:
Delta RPMs disabled because /usr/bin/applydeltarpm not installed.
oraclelinux-release-el7-1.0-17.el7.x86_64.rpm                                                                                                                      |  22 kB  00:00:00
Running DB8action check
Running DB8action test
DB8action test succeeded
Running DB8action
  Updating   : oraclelinux-release-el7-1.0-17.el7.x86_64                                                                                                                              1/2
  Cleanup    : oraclelinux-release-el7-1.0-13.1.el7.x86_64                                                                                                                            2/2
  Verifying  : oraclelinux-release-el7-1.0-17.el7.x86_64                                                                                                                              1/2
  Verifying  : oraclelinux-release-el7-1.0-13.1.el7.x86_64                                                                                                                            2/2

Updated:
  oraclelinux-release-el7.x86_64 0:1.0-17.el7

Complete!

Now I have a ol7_leapp repository:

[root@SRV scripts]# yum repolist all | grep -i leapp
ol7_leapp/x86_64                  Leapp Upgrade Utilities for Or disabled
[root@SRV scripts]#

And I could installed leapp package:

[root@SRV scripts]# yum install -y leapp-upgrade --enablerepo=ol7_leapp,ol7_latest
Loaded plugins: ulninfo
ol7_leapp                                                                                                                                                          | 3.0 kB  00:00:00
(1/2): ol7_leapp/x86_64/updateinfo                                                                                                                                 |  47 kB  00:00:00
(2/2): ol7_leapp/x86_64/primary_db                                                                                                                                 |  44 kB  00:00:00
...
Installed:
  leapp-upgrade-el7toel8.noarch 0:0.20.0-2.0.11.el7_9

Dependency Installed:
  dnf.noarch 0:4.0.9.2-1.el7_6                                dnf-data.noarch 0:4.0.9.2-1.el7_6          leapp.noarch 0:0.17.0-1.0.2.el7_9         leapp-deps.noarch 0:0.17.0-1.0.2.el7_9
  leapp-upgrade-el7toel8-deps.noarch 0:0.20.0-2.0.11.el7_9    libcomps.x86_64 0:0.1.8-14.el7             libdnf.x86_64 0:0.22.5-1.el7_8            libmodulemd.x86_64 0:1.6.3-1.el7
  librepo.x86_64 0:1.8.1-8.el7_9                              libsolv.x86_64 0:0.6.34-4.el7              libyaml.x86_64 0:0.1.4-11.el7_0           python-backports.x86_64 0:1.0-8.el7
  python-backports-ssl_match_hostname.noarch 0:3.5.0.1-1.el7  python-enum34.noarch 0:1.0.4-1.el7         python-ipaddress.noarch 0:1.0.16-2.el7    python-requests.noarch 0:2.6.0-10.el7
  python-setuptools.noarch 0:0.9.8-7.0.1.el7                  python-six.noarch 0:1.9.0-2.el7            python-urllib3.noarch 0:1.10.2-7.0.1.el7  python2-dnf.noarch 0:4.0.9.2-1.el7_6
  python2-hawkey.x86_64 0:0.22.5-1.el7_8                      python2-leapp.noarch 0:0.17.0-1.0.2.el7_9  python2-libcomps.x86_64 0:0.1.8-14.el7    python2-libdnf.x86_64 0:0.22.5-1.el7_8

Complete!

And I could confirm leapp rpm has been successfully installed and is available:

[root@SRV scripts]# rpm -qa | grep -i leapp
leapp-deps-0.17.0-1.0.2.el7_9.noarch
leapp-upgrade-el7toel8-deps-0.20.0-2.0.11.el7_9.noarch
leapp-0.17.0-1.0.2.el7_9.noarch
python2-leapp-0.17.0-1.0.2.el7_9.noarch
leapp-upgrade-el7toel8-0.20.0-2.0.11.el7_9.noarch
[root@SRV scripts]#

System prechecks and prepare system for the upgrade

There is a few requirements that needs to be done before starting in-place upgrade with leapp.

Set PermitRootLogin to yes

[root@SRV ~]# grep -i PermitRootLogin /etc/ssh/sshd_config
#PermitRootLogin yes
# the setting of "PermitRootLogin without-password".

[root@SRV ~]# vi /etc/ssh/sshd_config

[root@SRV ~]# grep -i PermitRootLogin /etc/ssh/sshd_config
PermitRootLogin yes
# the setting of "PermitRootLogin without-password".
[root@SRV ~]#

Restart sshd service

[root@SRV ~]# systemctl restart sshd
[root@SRV ~]#

Deactivate CIFS

No CIFS mount point should be existing during the upgrade. Use command mount -t cifs to check if some are existing. If it is the case they should be visible with df -h command. All should be unmounted with root user using command umount.

It is also important to comment out the CIFS mount point from the /etc/fstab file to ensure they will be not automatically mounted during upgrade reboot.

Check secureboot is disabled

Ensure secure boot is disabled:

[root@SRV ~]# bootctl status
System:
   Machine ID: 939798bf09ac467188081e34260fbcfd
      Boot ID: 50f116f91fe1424c97890e75a8f48915
  Secure Boot: disabled
   Setup Mode: user

Selected Firmware Entry:
        Title: Oracle Linux
    Partition: /dev/disk/by-partuuid/27483f47-6405-48f9-a000-23e722ff4add
         File: └─/EFI/redhat/shimx64.efi

No suitable data is provided by the boot manager. See:
  http://www.freedesktop.org/wiki/Software/systemd/BootLoaderInterface
  http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec
for details.

[root@SRV ~]#

Configure proxy in yum.conf if needed

If proxy is needed to connect to outside, it is important to have it configured in yum.conf.

[root@SRV ~]# grep -i proxy /etc/yum.conf
proxy=http://172.X.X.X:3128

Check if version lock installed

No version lock rpm should be installed.

[root@SRV ~]# rpm -qa | grep -i yum-plugin-versionlock
[root@SRV ~]#

Get last el7 package version

Ensure we are getting last version for all installed packages.

[root@SRV ~]# yum update -y
Loaded plugins: ulninfo
Resolving Dependencies
There are unfinished DB8actions remaining. You might consider running yum-complete-DB8action, or "yum-complete-DB8action --cleanup-only" and "yum history redo last", first to finish them. If those don't work you'll have to try removing/installing packages by hand (maybe package-cleanup can help).
--> Running DB8action check
---> Package NetworkManager.x86_64 1:1.18.8-1.el7 will be updated
---> Package NetworkManager.x86_64 1:1.18.8-2.el7_9 will be updated
---> Package NetworkManager.x86_64 1:1.18.8-2.0.1.el7_9 will be an update
---> Package NetworkManager-config-server.noarch 1:1.18.8-2.el7_9 will be updated
---> Package NetworkManager-config-server.noarch 1:1.18.8-2.0.1.el7_9 will be an update
---> Package NetworkManager-glib.x86_64 1:1.18.8-2.el7_9 will be updated
---> Package NetworkManager-glib.x86_64 1:1.18.8-2.0.1.el7_9 will be an update
---> Package NetworkManager-libnm.x86_64 1:1.18.8-1.el7 will be updated
---> Package NetworkManager-libnm.x86_64 1:1.18.8-2.el7_9 will be updated
---> Package NetworkManager-libnm.x86_64 1:1.18.8-2.0.1.el7_9 will be an update
---> Package NetworkManager-team.x86_64 1:1.18.8-1.el7 will be updated
---> Package NetworkManager-team.x86_64 1:1.18.8-2.el7_9 will be updated
---> Package NetworkManager-team.x86_64 1:1.18.8-2.0.1.el7_9 will be an update
---> Package NetworkManager-tui.x86_64 1:1.18.8-2.el7_9 will be updated
---> Package NetworkManager-tui.x86_64 1:1.18.8-2.0.1.el7_9 will be an update
---> Package bash.x86_64 0:4.2.46-34.el7 will be updated
---> Package bash.x86_64 0:4.2.46-35.el7_9 will be an update
...
...
...
(181/183): zlib-1.2.7-21.el7_9.x86_64.rpm                                                                                                                          |  90 kB  00:00:00
(182/183): kernel-uek-5.4.17-2136.338.4.2.el7uek.x86_64.rpm                                                                                                        | 112 MB  00:00:33
(183/183): linux-firmware-20241003-999.35.git95bfe086.el7.noarch.rpm                                                                                               | 382 MB  00:00:56
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                     9.9 MB/s | 731 MB  00:01:13
Running DB8action check
Running DB8action test
DB8action test succeeded
Running DB8action
  Updating   : 1:grub2-common-2.02-0.87.0.26.el7_9.14.noarch                                                                                                                        1/415
  Updating   : 1:redhat-release-server-7.9-6.0.1.el7_9.x86_64                                                                                                                       2/415
  Updating   : 32:bind-license-9.11.4-26.0.1.P2.el7_9.16.noarch                                                                                                                     3/415
  Updating   : 1:grub2-pc-modules-2.02-0.87.0.26.el7_9.14.noarch                                                                                                                    4/415
  Updating   : kbd-misc-1.15.5-16.el7_9.noarch                                                                                                                                      5/415
  Updating   : libX11-common-1.6.7-5.el7_9.noarch                                                                                                                                   6/415
  Updating   : kernel-headers-3.10.0-1160.119.1.0.5.el7.x86_64                                                                                                                      7/415
  Updating   : firewalld-filesystem-0.6.3-13.0.1.el7_9.noarch                                                                                                                       8/415
  Updating   : libreport-filesystem-2.1.11-53.0.3.el7.x86_64                                                                                                                        9/415
  Updating   : kbd-legacy-1.15.5-16.el7_9.noarch                                                                                                                                   10/415
  Installing : 999:iwlax2xx-firmware-20241003-999.35.el7.noarch [###########################                                                                                    ]  11/415...
...
...
...
  Cleanup    : glibc-common-2.17-317.0.1.el7.x86_64                                                                                                                               409/415
  Cleanup    : bash-4.2.46-34.el7.x86_64                                                                                                                                          410/415
  Cleanup    : nspr.x86_64                                                                                                                                                        411/415
  Cleanup    : nss-util.x86_64                                                                                                                                                    412/415
  Cleanup    : nss-softokn-freebl.x86_64                                                                                                                                          413/415
  Cleanup    : glibc-2.17-317.0.1.el7.x86_64                                                                                                                                      414/415
  Cleanup    : tzdata-2020f-1.el7.noarch                                                                                                                                          415/415
  ...
  ...
  ...
  rpm-build-libs.x86_64 0:4.11.3-48.0.3.el7_9                 rpm-libs.x86_64 0:4.11.3-48.0.3.el7_9                             rpm-python.x86_64 0:4.11.3-48.0.3.el7_9
  rsync.x86_64 0:3.1.2-12.el7_9                               rsyslog.x86_64 0:8.24.0-57.0.3.el7_9.3                            samba-client-libs.x86_64 0:4.10.16-25.0.5.el7_9
  samba-common.noarch 0:4.10.16-25.0.5.el7_9                  samba-common-libs.x86_64 0:4.10.16-25.0.5.el7_9                   selinux-policy.noarch 0:3.13.1-268.0.25.el7_9.2
  selinux-policy-targeted.noarch 0:3.13.1-268.0.25.el7_9.2    shim-x64.x86_64 0:15.8-1.0.3.el7                                  strace.x86_64 0:4.24-7.el7_9
  sudo.x86_64 0:1.8.23-10.el7_9.3                             sysstat.x86_64 0:10.1.5-20.0.3.el7_9                              systemd.x86_64 0:219-78.0.17.el7_9.9
  systemd-libs.x86_64 0:219-78.0.17.el7_9.9                   systemd-sysv.x86_64 0:219-78.0.17.el7_9.9                         tuned.noarch 0:2.11.0-12.0.3.el7_9
  tzdata.noarch 0:2024b-2.el7                                 unzip.x86_64 0:6.0-24.0.1.el7_9                                   util-linux.x86_64 0:2.23.2-65.0.4.el7_9.1
  virt-what.x86_64 0:1.18-4.el7_9.1                           wpa_supplicant.x86_64 1:2.6-12.el7_9.2                            xz.x86_64 0:5.2.2-2.el7_9
  xz-libs.x86_64 0:5.2.2-2.el7_9                              yum.noarch 0:3.4.3-168.0.5.el7                                    zlib.x86_64 0:1.2.7-21.el7_9

Complete!
[root@SRV ~]#

It is important to reboot the server so it can start on the last kernel, otherwise we will have a leapp report error.

[root@SRV ~]# systemctl reboot

login as: root
root@SRV's password:
Last failed login: Wed Jun 17 15:26:51 CEST 2026 from ts3-back.int.custname.ch on ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Wed Jun 17 14:37:30 2026 from ts3-back.int.custname.ch


[root@SRV ~]# uptime
 15:26:56 up 1 min,  1 user,  load average: 0.49, 0.23, 0.09
[root@SRV ~]#

ULN Registration

Check that system is not register with ULN.

[root@SRV ~]# rpm -qa | grep -Ei 'uln|rhn'
rhnsd-5.0.13-10.0.1.el7.x86_64
rhn-setup-2.0.2-24.0.11.el7.x86_64
rhn-check-2.0.2-24.0.11.el7.x86_64
yum-plugin-ulninfo-0.2-13.el7.noarch
yum-rhn-plugin-2.0.1-10.0.1.el7.noarch
rhn-client-tools-2.0.2-24.0.11.el7.x86_64
rhnlib-2.5.65-8.0.5.el7.noarch

[root@SRV ~]# ls -l /etc/sysconfig/rhn
total 8
drwxr-xr-x. 4 root root   39 Aug  1  2023 allowed-actions
drwxr-xr-x. 2 root root    6 Aug  1  2023 clientCaps.d
-rw-r--r--. 1 root root   13 Jun 17  2013 rhnsd
-rw-r--r--. 1 root root 1897 Aug  1  2023 up2date

[root@SRV ~]# yum repolist all | grep -iE 'uln|oraclelinux|linux.oracle.com'
Loaded plugins: ulninfo
ol8_oraclelinuxmanager210_client/x86_64 Oracle Linux Manager Cli disabled

[root@SRV ~]# grep -Ri "linux.oracle.com\|uln" /etc/yum.repos.d/

[root@SRV ~]# uln-channel -l
Unable to locate SystemId file. Is this system registered?
[root@SRV ~]#

Run pre-upgrade

We can now run the preupgrade.

[root@SRV ~]# leapp preupgrade --oraclelinux
==> Processing phase `configuration_phase`
====> * ipu_workflow_config
        IPU workflow config actor
==> Processing phase `FactsCollection`
====> * DB8action_workarounds
        Provides additional RPM DB8action tasks based on bundled RPM packages.
====> * scan_kernel_cmdline
        No documentation has been provided for the scan_kernel_cmdline actor.
====> * persistentnetnames
        Get network interface information for physical ethernet interfaces of the original system.
====> * common_leapp_dracut_modules
        Influences the generation of the initram disk
====> * scanmemory
        Scan Memory of the machine.
...
...
...
====> * target_userspace_creator
        Initializes a directory to be populated as a minimal environment to run binaries from the target system.
Latest Unbreakable Enterprise Kernel Release 6  0.0  B/s |   0  B     00:00
Oracle Linux 8 Application Stream (x86_64)      0.0  B/s |   0  B     00:00
Oracle Linux 8 BaseOS Latest (x86_64)           0.0  B/s |   0  B     00:00
No match for argument: dnf
No match for argument: util-linux
No match for argument: dnf-command(config-manager)

============================================================
                           ERRORS
============================================================

2026-06-17 15:42:12.075669 [ERROR] Actor: target_userspace_creator
Message: Unable to install OL 8 userspace packages.
Summary:
    Details: DNF failed to install userspace packages, likely due to the proxy configuration detected in the YUM/DNF configuration file. Make sure the proxy is properly configured in /etc/dnf/dnf.conf. It's also possible the proxy settings in the DNF configuration file are incompatible with the target system. A compatible configuration can be placed in /etc/leapp/files/dnf.conf which, if present, will be used during the upgrade instead of /etc/dnf/dnf.conf. In such case the configuration will also be applied to the target system.
    Stderr: Host and machine ids are equal (939798bf09ac467188081e34260fbcfd): refusing to link journals
            Failed to synchronize cache for repo 'ol8_UEKR6', ignoring this repo.
            Failed to synchronize cache for repo 'ol8_appstream', ignoring this repo.
            Failed to synchronize cache for repo 'ol8_baseos_latest', ignoring this repo.
            Error: Unable to find a match: dnf util-linux dnf-command(config-manager)

============================================================
                       END OF ERRORS
============================================================

Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                      REPORT OVERVIEW
============================================================

Following errors occurred and the upgrade cannot continue:
    1. Actor: target_userspace_creator
       Message: Unable to install OL 8 userspace packages.

HIGH and MEDIUM severity reports:
    1. Packages available in excluded repositories will not be installed
    2. Packages not signed by Oracle found on the system
    3. Detected customized configuration for dynamic linker.
    4. Difference in Python versions and support in OL 8
    5. Default Boot Kernel

Reports summary:
    Errors:                      1
    Inhibitors:                  0
    HIGH severity reports:       4
    MEDIUM severity reports:     1
    LOW severity reports:        5
    INFO severity reports:       3

Before continuing consult the full report:
    A report has been generated at /var/log/leapp/leapp-report.json
    A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                   END OF REPORT OVERVIEW
============================================================

Answerfile has been generated at /var/log/leapp/answerfile
[root@SRV ~]#

Check preupgrade report

From the preupgrade command output, we can see the number of errors. All errors and inhibitor are mandatory to be resolved. I would fully recommend to resolve as well all high severity issues and to, at least review the medium, low and info severity.

Some issues need to be resolved before the upgrade, some after.

I can have details of the issue from the leapp-report.txt file. Here extract of mine:

[root@SRV ~]# cat /var/log/leapp/leapp-report.txt
Risk Factor: high (error)
Title: Unable to install OL 8 userspace packages.
Summary: {"details": "DNF failed to install userspace packages, likely due to the proxy configuration detected in the YUM/DNF configuration file. Make sure the proxy is properly configured in /etc/dnf/dnf.conf. It's also possible the proxy settings in the DNF configuration file are incompatible with the target system. A compatible configuration can be placed in /etc/leapp/files/dnf.conf which, if present, will be used during the upgrade instead of /etc/dnf/dnf.conf. In such case the configuration will also be applied to the target system.", "stderr": "Host and machine ids are equal (939798bf09ac467188081e34260fbcfd): refusing to link journals
Failed to synchronize cache for repo 'ol8_UEKR6', ignoring this repo.
Failed to synchronize cache for repo 'ol8_appstream', ignoring this repo.
Failed to synchronize cache for repo 'ol8_baseos_latest', ignoring this repo.
Error: Unable to find a match: dnf util-linux dnf-command(config-manager)
"}
Key: d090c9f87ad7eae313bd4101ba68dbcf8697f3e4
----------------------------------------
Risk Factor: high
Title: Packages available in excluded repositories will not be installed
Summary: 4 packages will be skipped because they are available only in target system repositories that are intentionally excluded from the list of repositories used during the upgrade. See the report message titled "Excluded target system repositories" for details.
The list of these packages:
- libnsl2-devel (repoid: ol8_codeready_builder)
- python3-pyxattr (repoid: ol8_codeready_builder)
- rpcgen (repoid: ol8_codeready_builder)
- rpcsvc-proto-devel (repoid: ol8_codeready_builder)
Key: 2437e204808f987477c0e9be8e4c95b3a87a9f3e
----------------------------------------
Risk Factor: high
Title: Packages not signed by Oracle found on the system
Summary: The following packages have not been signed by Oracle and may be removed during the upgrade process in case Oracle-signed packages to be removed during the upgrade depend on them:
- collectd
- epel-release
- libzstd
Key: f5a5d58476a97bf0a8904d00df5d1321189849ad
----------------------------------------
Risk Factor: high
Title: Detected customized configuration for dynamic linker.
Summary: Custom configurations to the dynamic linker could potentially impact the upgrade in a negative way. The custom configuration includes modifications to /etc/ld.so.conf, custom or modified drop in config files in the /etc/ld.so.conf.d directory and additional entries in the LD_LIBRARY_PATH or LD_PRELOAD variables. These modifications configure the dynamic linker to use different libraries that might not be provided by Oracle products or might not be present during the whole upgrade process. The following custom configurations were detected by leapp:
- The following drop in config files were marked as custom:
    - /etc/ld.so.conf.d/mariadb-x86_64.conf
Remediation: [hint] Remove or revert the custom dynamic linker configurations and apply the changes using the ldconfig command. In case of possible active software collections we suggest disabling them persistently.
Key: cc9bd972af70b7a27f66a37b11a00dcfcb73b1bc
----------------------------------------
Risk Factor: high
Title: Difference in Python versions and support in OL 8
Summary: In OL 8, there is no 'python' command. Python 3 (backward incompatible) is the primary Python version and Python 2 is available with limited support and limited set of packages. If you no longer require Python 2 packages following the upgrade, please remove them. Read more here: https://docs.oracle.com/en/operating-systems/oracle-linux/8/python/
Related links:
    - Difference in Python versions and support in OL 8: https://docs.oracle.com/en/operating-systems/oracle-linux/8/python/
Remediation: [hint] Please run "alternatives --set python /usr/bin/python3" after upgrade
Key: 2f3a43f4f448995eec953217d54f388ed94838b2
...
...
...

Resolve issues

I resolved the issue that needs to be resolved before the upgrade: 1 error and 2 high severity. In this chapter I describe how I resolved them.

Solve issue #1 : Unable to install OL 8 userspace packages. – high (error)

The problem here is that leapp can not download the OL 8 packages because the proxy is not part of the dnf configuration. Let’s add it.

[root@SRV ~]# grep -i proxy /etc/yum.conf
proxy=http://172.X.X.X:3128

[root@SRV ~]# grep -i proxy /etc/dnf/dnf.conf
[root@SRV ~]# vi /etc/dnf/dnf.conf

[root@SRV ~]# grep -i proxy /etc/dnf/dnf.conf
proxy=http://172.X.X.X:3128
[root@SRV ~]#

Solve issue #2 – Detected customized configuration for dynamic linker. – (high)

Looking to the next command, it seems the MariaDB library installation is broken. Not sure what happened during a previous yum installation.

[root@SRV ~]# ls -ltrh /etc/ld.so.conf.d/mariadb-x86_64.conf
-rw-r--r--. 1 root root 17 Oct  1  2020 /etc/ld.so.conf.d/mariadb-x86_64.conf

[root@SRV ~]# cat /etc/ld.so.conf.d/mariadb-x86_64.conf
/usr/lib64/mysql

[root@SRV ~]# rpm -qa | grep -i mariadb
mariadb-libs-5.5.65-1.el7.x86_64
mariadb-libs-5.5.68-1.el7.x86_64

[root@SRV ~]# rpm -qa | grep -i mysql
[root@SRV ~]# ldconfig -p | grep -i maria
[root@SRV ~]#

[root@SRV ~]# rpm -qf /etc/ld.so.conf.d/mariadb-x86_64.conf
mariadb-libs-5.5.65-1.el7.x86_64
mariadb-libs-5.5.68-1.el7.x86_64
[root@SRV ~]#

Moreover there is 2 versions of the same mariadb package installed simultaneously, which should never happened.

I decided to check if there were other duplicated packages:

[root@SRV ~]# package-cleanup --dupes
libcroco-0.6.12-6.el7_9.x86_64
libcroco-0.6.12-4.el7.x86_64
lz4-1.8.3-1.el7.x86_64
lz4-1.7.5-3.el7.x86_64
iprutils-2.4.17.1-3.el7.x86_64
iprutils-2.4.17.1-3.el7_7.x86_64
numactl-libs-2.0.12-5.el7.x86_64
numactl-libs-2.0.12-5.0.3.el7.x86_64
file-libs-5.11-36.el7.x86_64
file-libs-5.11-37.el7.x86_64
sed-4.2.2-6.el7.x86_64
sed-4.2.2-7.el7.x86_64
lshw-B.02.18-17.el7.x86_64
lshw-B.02.18-14.el7.x86_64
file-5.11-36.el7.x86_64
file-5.11-37.el7.x86_64
kmod-20-28.0.1.el7.x86_64
kmod-20-28.0.3.el7.x86_64
coreutils-8.22-24.0.1.el7.x86_64
coreutils-8.22-24.0.1.el7_9.2.x86_64
dbus-libs-1.10.24-13.0.1.el7_6.x86_64
dbus-libs-1.10.24-15.0.1.el7.x86_64
elfutils-libelf-0.176-5.el7.x86_64
elfutils-libelf-0.176-4.el7.x86_64
freetype-2.8-14.el7.x86_64
freetype-2.8-14.el7_9.1.x86_64
plymouth-core-libs-0.8.9-0.34.20140113.0.1.el7.x86_64
plymouth-core-libs-0.8.9-0.33.20140113.0.1.el7.x86_64
cpio-2.11-27.el7.x86_64
cpio-2.11-28.el7.x86_64
kmod-libs-20-28.0.3.el7.x86_64
kmod-libs-20-28.0.1.el7.x86_64
libpng-1.5.13-8.el7.x86_64
libpng-1.5.13-7.el7_2.x86_64
libteam-1.29-1.el7.x86_64
libteam-1.29-3.el7.x86_64
elfutils-libs-0.176-4.el7.x86_64
elfutils-libs-0.176-5.el7.x86_64
dbus-1.10.24-13.0.1.el7_6.x86_64
dbus-1.10.24-15.0.1.el7.x86_64
mariadb-libs-5.5.65-1.el7.x86_64
mariadb-libs-5.5.68-1.el7.x86_64
elfutils-default-yama-scope-0.176-5.el7.noarch
elfutils-default-yama-scope-0.176-4.el7.noarch
teamd-1.29-3.el7.x86_64
teamd-1.29-1.el7.x86_64
device-mapper-persistent-data-0.8.5-2.el7.x86_64
device-mapper-persistent-data-0.8.5-3.el7_9.2.x86_64
[root@SRV ~]#

There were many!

For each of them I checked, which package is really the oldest:

[root@SRV ~]# rpm -q --last libcroco
libcroco-0.6.12-6.el7_9.x86_64                Mon 16 Nov 2020 02:37:57 PM CET
libcroco-0.6.12-4.el7.x86_64                  Wed 28 Oct 2020 10:35:18 AM CET
[root@SRV ~]# 

And removed the oldest one:

[root@SRV ~]# yum remove libcroco-0.6.12-4.el7.x86_64
Loaded plugins: ulninfo
Resolving Dependencies
--> Running DB8action check
---> Package libcroco.x86_64 0:0.6.12-4.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================================================================================================================================
 Package                                           Arch                                            Version                                                  Repository                                              Size
=========================================================================================================================================================================================================================
Removing:
 libcroco                                          x86_64                                          0.6.12-4.el7                                             @anaconda/7.8                                          313 k

DB8action Summary
=========================================================================================================================================================================================================================
Remove  1 Package

Installed size: 313 k
Is this ok [y/N]: y
Downloading packages:
Running DB8action check
Running DB8action test
DB8action test succeeded
Running DB8action
  Erasing    : libcroco-0.6.12-4.el7.x86_64                                                                                                                                                                          1/1
  Verifying  : libcroco-0.6.12-4.el7.x86_64                                                                                                                                                                          1/1

Removed:
  libcroco.x86_64 0:0.6.12-4.el7

Complete!
[root@SRV ~]#

And I did this for all duplicate packages, removing the oldest one.

To finally have a clean system:

[root@SRV ~]# package-cleanup --dupes
[root@SRV ~]#

Knowing maria package was not used, I removed mariadb libs one.

[root@SRV ~]# rpm -qf /etc/ld.so.conf.d/mariadb-x86_64.conf
mariadb-libs-5.5.68-1.el7.x86_64

[root@SRV ~]# yum remove mariadb-libs
Loaded plugins: ulninfo
Resolving Dependencies
--> Running DB8action check
---> Package mariadb-libs.x86_64 1:5.5.68-1.el7 will be erased
--> Processing Dependency: libmysqlclient.so.18()(64bit) for package: 2:postfix-2.10.1-9.el7.x86_64
--> Processing Dependency: libmysqlclient.so.18(libmysqlclient_18)(64bit) for package: 2:postfix-2.10.1-9.el7.x86_64
--> Running DB8action check
---> Package postfix.x86_64 2:2.10.1-9.el7 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

=========================================================================================================================================================================================================================
 Package                                              Arch                                           Version                                                 Repository                                             Size
=========================================================================================================================================================================================================================
Removing:
 mariadb-libs                                         x86_64                                         1:5.5.68-1.el7                                          installed                                             4.4 M
Removing for dependencies:
 postfix                                              x86_64                                         2:2.10.1-9.el7                                          @anaconda/7.8                                          12 M

DB8action Summary
=========================================================================================================================================================================================================================
Remove  1 Package (+1 Dependent package)

Installed size: 17 M
Is this ok [y/N]: N
Exiting on user command
Your DB8action was saved, rerun it with:
 yum load-DB8action /tmp/yum_save_tx.2026-06-17.17-17.bwc_7l.yumtx
[root@SRV ~]#

I checked system cache libraries:

[root@SRV ~]# ldconfig -p | grep -i maria
[root@SRV ~]# ldconfig -p | grep -i mysql
        libmysqlclient.so.18 (libc6,x86-64) => /usr/lib64/mysql/libmysqlclient.so.18
[root@SRV ~]#

And knowing there were none for mariadb package I decided to move the mariadb configuration file that tells ldconfig where MariaDB’s shared libraries are located. In any case, customer was not using mariadb and mysql.

[root@SRV ~]# mkdir /root/leap_issue

[root@SRV ~]# mv /etc/ld.so.conf.d/mariadb-x86_64.conf /root/leap_issue/

[root@SRV ~]# ls -ltrh /etc/ld.so.conf.d/mariadb-x86_64.conf
ls: cannot access /etc/ld.so.conf.d/mariadb-x86_64.conf: No such file or directory

[root@SRV ~]# ls -ltrh /root/leap_issue/
total 4.0K
-rw-r--r--. 1 root root 17 Oct  1  2020 mariadb-x86_64.conf

[root@SRV ~]# ldconfig
[root@SRV ~]#

Remove old kernel

I also made some free space in the /boot file system removing old kernel.

I check boot file system occupency:

[root@SRV ~]# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb2       482M  318M  165M  66% /boot

I checked the kernel that I’m currently running:

[root@SRV ~]# uname -r
5.4.17-2136.338.4.2.el7uek.x86_64

I checked the installed kernel:

[root@SRV ~]# rpm -qa | grep -i kernel
kernel-tools-3.10.0-1160.119.1.0.5.el7.x86_64
kernel-tools-libs-3.10.0-1160.119.1.0.5.el7.x86_64
kernel-uek-5.4.17-2036.102.0.2.el7uek.x86_64
kernel-3.10.0-1160.6.1.el7.x86_64
kernel-3.10.0-1160.119.1.0.5.el7.x86_64
kernel-uek-5.4.17-2136.338.4.2.el7uek.x86_64
kernel-uek-5.4.17-2036.100.6.1.el7uek.x86_64
kernel-3.10.0-1160.11.1.el7.x86_64
kernel-headers-3.10.0-1160.119.1.0.5.el7.x86_64
[root@SRV ~]#

And removed the old one:

[root@SRV ~]# rpm -e kernel-uek-5.4.17-2036.102.0.2.el7uek.x86_64
[root@SRV ~]# rpm -e kernel-uek-5.4.17-2036.100.6.1.el7uek.x86_64

And I could then free some space in the file system:

[root@SRV ~]# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb2       482M  218M  264M  46% /boot

Run a preupgrade report again

I ran a preupgrade report again:

[root@SRV ~]# leapp preupgrade --oraclelinux
==> Processing phase `configuration_phase`
====> * ipu_workflow_config
        IPU workflow config actor
==> Processing phase `FactsCollection`
====> * scan_systemd_source
        Provides info about systemd on the source system
====> * scan_source_files
        Scan files (explicitly specified) of the source system.
====> * repository_mapping
...
...
...
Latest Unbreakable Enterprise Kernel Release 6   10 MB/s | 148 MB     00:14
Oracle Linux 8 Application Stream (x86_64)       11 MB/s |  82 MB     00:07
Oracle Linux 8 BaseOS Latest (x86_64)            11 MB/s | 145 MB     00:13
Last metadata expiration check: 0:00:23 ago on Thu Jun 18 07:55:00 2026.
Dependencies resolved.
================================================================================
 Package              Arch   Version                    Repository         Size
================================================================================
Installing:
 dnf                  noarch 4.7.0-21.0.1.el8_10        ol8_baseos_latest 542 k
 dnf-plugins-core     noarch 4.0.21-25.0.1.el8          ol8_baseos_latest  76 k
 util-linux           x86_64 2.32.1-48.0.2.el8_10       ol8_baseos_latest 2.5 M
Installing dependencies:
 libcom_err           x86_64 1.46.2-2.el8               ol8_UEKR6          51 k

...
...
...

 irqbalance                                x86_64  2:1.9.2-1.el8                                  ol8_baseos_latest   72 k
 libcgroup                                 x86_64  0.41-19.el8                                    ol8_baseos_latest   70 k
 libcroco                                  x86_64  0.6.12-4.el8_2.1                               ol8_baseos_latest  113 k
 libzstd                                   x86_64  1.4.4-1.0.1.el8                                ol8_baseos_latest  266 k
 oracle-database-preinstall-19c            x86_64  1.0-2.el8                                      ol8_appstream       31 k
 sg3_utils                                 x86_64  1.44-6.el8                                     ol8_baseos_latest  918 k
 sg3_utils-libs                            x86_64  1.44-6.el8                                     ol8_baseos_latest   99 k
Enabling module streams:
 gimp                                              2.8
 mariadb                                           10.3
 python27                                          2.7
 python36                                          3.6
 satellite-5-client                                1.0

DB8action Summary
==========================================================================================================================
Install    231 Packages
Upgrade    373 Packages
Remove      72 Packages
Downgrade    8 Packages

Total size: 1.3 G
Total download size: 1.1 G
Downloading Packages:
Check completed.
==> Processing phase `Reports`
====> * verify_check_results
        Check all dialogs and notify that user needs to make some choices.
====> * verify_check_results
        Check all generated results messages and notify user about them.

Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                      REPORT OVERVIEW
============================================================

Upgrade has been inhibited due to the following problems:
    1. Missing required answers in the answer file

HIGH and MEDIUM severity reports:
    1. Packages available in excluded repositories will not be installed
    2. Packages not signed by Oracle found on the system
    3. Difference in Python versions and support in OL 8
    4. Default Boot Kernel

Reports summary:
    Errors:                      0
    Inhibitors:                  1
    HIGH severity reports:       3
    MEDIUM severity reports:     1
    LOW severity reports:        5
    INFO severity reports:       3

Before continuing consult the full report:
    A report has been generated at /var/log/leapp/leapp-report.json
    A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                   END OF REPORT OVERVIEW
============================================================

Answerfile has been generated at /var/log/leapp/answerfile
[root@SRV ~]#

I could already see that now leapp can download the OL8 packages.

I have 1 inhibitors errors to resolve and let’s see the 3 high issues.

Check leapp preupgrade new report

I checked the report for details on the issue:

root@SRV ~]# ls -ltrh /var/log/leapp/leapp-report.txt
-rw-r--r--. 1 root root 8.7K Jun 18 07:57 /var/log/leapp/leapp-report.txt

[root@SRV ~]# date
Thu Jun 18 07:59:45 CEST 2026

[root@SRV ~]# cat /var/log/leapp/leapp-report.txt
Risk Factor: high (inhibitor)
Title: Missing required answers in the answer file
Summary: One or more sections in answerfile are missing user choices: remove_pam_pkcs11_module_check.confirm
For more information consult https://docs.oracle.com/en/operating-systems/oracle-linux/8/leapp/leapp-UpgradingtheSystem.html#preupgrade-report.
Remediation: [hint] Please register user choices with leapp answer cli command or by manually editing the answerfile.
[command] leapp answer --section remove_pam_pkcs11_module_check.confirm=True
Key: d35f6c6b1b1fa6924ef442e3670d90fa92f0d54b
----------------------------------------
Risk Factor: high
Title: Packages available in excluded repositories will not be installed
Summary: 4 packages will be skipped because they are available only in target system repositories that are intentionally excluded from the list of repositories used during the upgrade. See the report message titled "Excluded target system repositories" for details.
The list of these packages:
- libnsl2-devel (repoid: ol8_codeready_builder)
- python3-pyxattr (repoid: ol8_codeready_builder)
- rpcgen (repoid: ol8_codeready_builder)
- rpcsvc-proto-devel (repoid: ol8_codeready_builder)
Key: 2437e204808f987477c0e9be8e4c95b3a87a9f3e
----------------------------------------
Risk Factor: high
Title: Packages not signed by Oracle found on the system
Summary: The following packages have not been signed by Oracle and may be removed during the upgrade process in case Oracle-signed packages to be removed during the upgrade depend on them:
- collectd
- epel-release
- libzstd
Key: f5a5d58476a97bf0a8904d00df5d1321189849ad
----------------------------------------
Risk Factor: high
Title: Difference in Python versions and support in OL 8
Summary: In OL 8, there is no 'python' command. Python 3 (backward incompatible) is the primary Python version and Python 2 is available with limited support and limited set of packages. If you no longer require Python 2 packages following the upgrade, please remove them. Read more here: https://docs.oracle.com/en/operating-systems/oracle-linux/8/python/
Related links:
    - Difference in Python versions and support in OL 8: https://docs.oracle.com/en/operating-systems/oracle-linux/8/python/
Remediation: [hint] Please run "alternatives --set python /usr/bin/python3" after upgrade
Key: 2f3a43f4f448995eec953217d54f388ed94838b2

There is only 1 inhibitor error to resolve, the 3 others high issue will be resolved after the upgrade.

Resolve the inhibitor issue

We just need to update the answer file by running following command:

[root@SRV ~]# leapp answer --section remove_pam_pkcs11_module_check.confirm=True

And I can check the answer file:

[root@SRV ~]# ls -ltrh /var/log/leapp/answerfile
-rw-r--r--. 1 root root 49 Jun 18 08:02 /var/log/leapp/answerfile
[root@SRV ~]# cat /var/log/leapp/answerfile
[remove_pam_pkcs11_module_check]
confirm = True

[root@SRV ~]#

A last preupgrade leapp report

I decided to run the preupgrade one last time and could see that I do not have any inhibitor error any more. And the 3 high severity are known and will be addressed at the end.

[root@SRV ~]# leapp preupgrade --oraclelinux
...
...
...
Reports summary:
    Errors:                      0
    Inhibitors:                  0
    HIGH severity reports:       3
    MEDIUM severity reports:     2
    LOW severity reports:        5
    INFO severity reports:       3

Before continuing consult the full report:
    A report has been generated at /var/log/leapp/leapp-report.json
    A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                   END OF REPORT OVERVIEW
============================================================

Answerfile has been generated at /var/log/leapp/answerfile
[root@SRV ~]#

Check file system occupancy

I checked file system occupancy:

[root@SRV ~]# df -h
Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       252G     0  252G   0% /dev
tmpfs                          252G     0  252G   0% /dev/shm
tmpfs                          252G   11M  252G   1% /run
tmpfs                          252G     0  252G   0% /sys/fs/cgroup
/dev/mapper/vgroot--lv-root    7.5G  3.2G  4.3G  43% /
/dev/mapper/vgroot--lv-usr      12G  2.4G  8.9G  21% /usr
/dev/mapper/vgdata-lv--data    8.8T  5.0T  3.8T  57% /data
/dev/mapper/vgroot--lv-home    7.5G  3.9G  3.6G  53% /home
/dev/mapper/vgroot--lv-tmp     4.7G   33M  4.7G   1% /tmp
/dev/mapper/vgroot--lv-var     9.4G  3.4G  6.0G  36% /var
/dev/sdb2                      482M  218M  264M  46% /boot
/dev/mapper/vgrdbms-lv--rdbms   11T  1.9T  8.7T  18% /rdbms
/dev/mapper/vgroot--lv-opt      15G  623M   15G   5% /opt
/dev/sdb1                      952M  7.4M  944M   1% /boot/efi
tmpfs                           51G     0   51G   0% /run/user/0
[root@SRV ~]#

Which is ok.

Leapp answer file

I checked leapp answer file:

[root@SRV ~]# cat /var/log/leapp/answerfile
[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 OL-8 since it was replaced by SSSD.
# Reason:             Leaving this module in PAM configuration may lock out the system.
# Type:               bool
# Default:            None
# Available choices: True/False
confirm = True

[root@SRV ~]#

All good.

Run the upgrade

Now I’m ready to run the upgrade.

It is important to have a console opened. I decided to run the upgrade in the console, but I could do it in a ssh session. The console is a must so we can see what is happening once we will reboot after the first part of the upgrade is done.

Starting leapp upgrade with the command leapp upgrade --oraclelinux.

End of the first upgrade execution:

During this execution, I can also tail the leapp upgrade log file:

[root@SRV ~]# ls -ltrh /var/log/leapp/leapp-upgrade.log
-rw-r--r--. 1 root root 224K Jun 18 08:52 /var/log/leapp/leapp-upgrade.log

[root@SRV ~]# tail -f /var/log/leapp/leapp-upgrade.log
2026-06-18 08:52:27.495 DEBUG    PID: 32639 leapp.workflow.FactsCollection.rpm_scanner: python|2.7.5|94.0.1.el7_9|0|(none)|x86_64|RSA/SHA256, Mon 13 Nov 2023 10:38:45 AM CET, Key ID 72f97b74ec551f03
2026-06-18 08:52:27.496 DEBUG    PID: 32639 leapp.workflow.FactsCollection.rpm_scanner: kmod|20|28.0.3.el7|0|(none)|x86_64|RSA/SHA256, Mon 20 Jul 2020 09:02:02 AM CEST, Key ID 72f97b74ec551f03
2026-06-18 08:52:27.497 DEBUG    PID: 32639 leapp.workflow.FactsCollection.rpm_scanner: bind-libs|9.11.4|26.0.1.P2.el7_9.16|32|(none)|x86_64|RSA/SHA256, Mon 14 Oct 2024 09:41:52 PM CEST, Key ID 72f97b74ec551f03
2026-06-18 08:52:27.497 DEBUG    PID: 32639 leapp.workflow.FactsCollection.rpm_scanner: rhnlib|2.5.65|8.0.5.el7|0|(none)|noarch|RSA/SHA256, Thu 06 Apr 2023 06:15:51 PM CEST, Key ID 72f97b74ec551f03
2026-06-18 08:52:27.498 DEBUG    PID: 32639 leapp.workflow.FactsCollection.rpm_scanner: libcurl|7.29.0|59.0.3.el7_9.2|0|(none)|x86_64|RSA/SHA256, Tue 12 Dec 2023 07:37:52 PM CET, Key ID 72f97b74ec551f03
2026-06-18 08:52:27.499 DEBUG    PID: 32639 leapp.workflow.FactsCollection.rpm_scanner: openldap|2.4.44|25.el7_9|0|(none)|x86_64|RSA/SHA256, Tue 22 Feb 2022 06:12:32 PM CET, Key ID 72f97b74ec551f03
2026-06-18 08:52:27.500 DEBUG    PID: 32639 leapp.workflow.FactsCollection.rpm_scanner: cronie-anacron|1.4.11|25.el7_9|0|(none)|x86_64|RSA/SHA256, Wed 26 Apr 2023 05:57:25 AM CEST, Key ID 72f97b74ec551f03
2026-06-18 08:52:27.500 DEBUG    PID: 32639 leapp.workflow.FactsCollection.rpm_scanner: ebtables|2.0.10|16.el7|0|(none)|x86_64|RSA/SHA256, Sat 27 Jan 2018 02:33:10 PM CET, Key ID 72f97b74ec551f03
2026-06-18 08:52:27.501 DEBUG    PID: 32639 leapp.workflow.FactsCollection.rpm_scanner: device-mapper-libs|1.02.170|6.0.5.el7_9.5|7|(none)|x86_64|RSA/SHA256, Fri 21 May 2021 01:16:51 PM CEST, Key ID 72f97b74ec551f03
2026-06-18 08:52:27.504 DEBUG    PID: 32639 leapp.workflow.FactsCollection.rpm_scanner: External command has finished: ['/bin/rpm', '-qa', '--queryformat', '%{NAME}|%{VERSION}|%{RELEASE}|%|EPOCH?{%{EPOCH}}:{0}||%|PACKAGER?{%{PACKAGER}}:{(none)}||%|ARCH?{%{ARCH}}:{}||%|DSAHEADER?{%{DSAHEADER:pgpsig}}:{%|RSAHEADER?{%{RSAHEADER:pgpsig}}:{(none)}|}|\\n']

...
...
...

2026-06-18 09:06:05.56  DEBUG    PID: 24169 leapp.workflow.InterimPreparation.add_upgrade_boot_entry: External command has finished: ['/usr/sbin/grubby', '--remove-kernel', '/boot/vmlinuz-upgrade.x86_64']
2026-06-18 09:06:05.57  DEBUG    PID: 24169 leapp.workflow.InterimPreparation.add_upgrade_boot_entry: External command has started: ['/usr/sbin/grubby', '--add-kernel', '/boot/vmlinuz-upgrade.x86_64', '--initrd', '/boot/initramfs-upgrade.x86_64.img', '--title', 'OL-Upgrade-Initramfs', '--copy-default', '--make-default', '--args', ' enforcing=0 rd.plymouth=0 plymouth.enable=0']
2026-06-18 09:06:05.102 DEBUG    PID: 24169 leapp.workflow.InterimPreparation.add_upgrade_boot_entry: External command has finished: ['/usr/sbin/grubby', '--add-kernel', '/boot/vmlinuz-upgrade.x86_64', '--initrd', '/boot/initramfs-upgrade.x86_64.img', '--title', 'OL-Upgrade-Initramfs', '--copy-default', '--make-default', '--args', ' enforcing=0 rd.plymouth=0 plymouth.enable=0']
2026-06-18 09:06:05.108 INFO     PID: 31824 leapp.workflow.InterimPreparation: Starting stage After of phase InterimPreparation
2026-06-18 09:06:05.116 INFO     PID: 31824 leapp: Answerfile will be created at /var/log/leapp/answerfile

Check leapp report and answer file

Check leapp upgrade report

As for the preupgrade, I will check the leapp report file and address all issue. There is 3 high severity issue, the same we had in the preupgrade report, and that we will address after the upgrade.

[root@SRV ~]# ls -ltrh /var/log/leapp/leapp-report.txt
-rw-r--r--. 1 root root 8.7K Jun 18 09:06 /var/log/leapp/leapp-report.txt

[root@SRV ~]# date
Thu Jun 18 09:07:27 CEST 2026

[root@SRV ~]# cat /var/log/leapp/leapp-report.txt
Risk Factor: high
Title: Packages available in excluded repositories will not be installed
Summary: 4 packages will be skipped because they are available only in target system repositories that are intentionally excluded from the list of repositories used during the upgrade. See the report message titled "Excluded target system repositories" for details.
The list of these packages:
- libnsl2-devel (repoid: ol8_codeready_builder)
- python3-pyxattr (repoid: ol8_codeready_builder)
- rpcgen (repoid: ol8_codeready_builder)
- rpcsvc-proto-devel (repoid: ol8_codeready_builder)
Key: 2437e204808f987477c0e9be8e4c95b3a87a9f3e
----------------------------------------
Risk Factor: high
Title: Packages not signed by Oracle found on the system
Summary: The following packages have not been signed by Oracle and may be removed during the upgrade process in case Oracle-signed packages to be removed during the upgrade depend on them:
- collectd
- epel-release
- libzstd
Key: f5a5d58476a97bf0a8904d00df5d1321189849ad
----------------------------------------
Risk Factor: high
Title: Difference in Python versions and support in OL 8
Summary: In OL 8, there is no 'python' command. Python 3 (backward incompatible) is the primary Python version and Python 2 is available with limited support and limited set of packages. If you no longer require Python 2 packages following the upgrade, please remove them. Read more here: https://docs.oracle.com/en/operating-systems/oracle-linux/8/python/
Related links:
    - Difference in Python versions and support in OL 8: https://docs.oracle.com/en/operating-systems/oracle-linux/8/python/
Remediation: [hint] Please run "alternatives --set python /usr/bin/python3" after upgrade
Key: 2f3a43f4f448995eec953217d54f388ed94838b2

Check the answer file

Ensure the answer file is ok.

[root@SRV ~]# ls -ltrh /var/log/leapp/answerfile
-rw-r--r--. 1 root root 589 Jun 18 09:06 /var/log/leapp/answerfile
[root@SRV ~]# cat /var/log/leapp/answerfile
[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 OL-8 since it was replaced by SSSD.
# Reason:             Leaving this module in PAM configuration may lock out the system.
# Type:               bool
# Default:            None
# Available choices: True/False
confirm = True

Reboot

Now that all is ok and that we are ready to upgrade, we will reboot and the second part of the leapp upgrade will upgrade the OL7 to OL8.

Check file system occupancy to ensure there is no full partition:

[root@SRV ~]# df -h
Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       252G     0  252G   0% /dev
tmpfs                          252G     0  252G   0% /dev/shm
tmpfs                          252G   11M  252G   1% /run
tmpfs                          252G     0  252G   0% /sys/fs/cgroup
/dev/mapper/vgroot--lv-root    7.5G  3.2G  4.3G  43% /
/dev/mapper/vgroot--lv-usr      12G  2.4G  8.9G  21% /usr
/dev/mapper/vgdata-lv--data    8.8T  5.0T  3.8T  57% /data
/dev/mapper/vgroot--lv-home    7.5G  3.9G  3.6G  53% /home
/dev/mapper/vgroot--lv-tmp     4.7G   33M  4.7G   1% /tmp
/dev/mapper/vgroot--lv-var     9.4G  6.9G  2.5G  74% /var
/dev/sdb2                      482M  315M  167M  66% /boot
/dev/mapper/vgrdbms-lv--rdbms   11T  1.9T  8.7T  18% /rdbms
/dev/mapper/vgroot--lv-opt      15G  625M   15G   5% /opt
/dev/sdb1                      952M  7.4M  944M   1% /boot/efi
tmpfs                           51G     0   51G   0% /run/user/0
[root@SRV ~]#

And reboot!

[root@SRV ~]# systemctl reboot

Monitor the console

Now the console is very important and we can monitor how the upgrade is on-going.

Following pictures shows some of the screen.

The server is rebooting.

Reboot on the Upgrade initramfs.

rpm package are upgraded from ol7 to ol8.

We have one more high severity issue to check and resolve once the upgrade is done.

The server is automatically rebooted several times.

And we are done.

Check leapp report files

Now we have a new leapp report file, and we will check it for issue to be resolved.

Check file date.

[root@SRV ~]# date
Thu Jun 18 09:46:13 CEST 2026

[root@SRV ~]# uptime
 09:46:14 up 3 min,  1 user,  load average: 0.27, 0.32, 0.14

[root@SRV ~]# ls -ltrh /var/log/leapp/leapp-report.txt
-rw-r--r--. 1 root root 11K Jun 18 09:43 /var/log/leapp/leapp-report.txt

[root@SRV ~]# ls -ltrh /var/log/leapp/answerfile
-rw-r--r--. 1 root root 0 Jun 18 09:43 /var/log/leapp/answerfile

Check answer file content, it should be empty.

[root@SRV ~]# cat /var/log/leapp/answerfile
[root@SRV ~]#

Check leapp report issue. We will resolve them later on.

[root@SRV ~]# cat /var/log/leapp/leapp-report.txt
Risk Factor: high
Title: Packages available in excluded repositories will not be installed
Summary: 4 packages will be skipped because they are available only in target system repositories that are intentionally excluded from the list of repositories used during the upgrade. See the report message titled "Excluded target system repositories" for details.
The list of these packages:
- libnsl2-devel (repoid: ol8_codeready_builder)
- python3-pyxattr (repoid: ol8_codeready_builder)
- rpcgen (repoid: ol8_codeready_builder)
- rpcsvc-proto-devel (repoid: ol8_codeready_builder)
Key: 2437e204808f987477c0e9be8e4c95b3a87a9f3e
----------------------------------------
Risk Factor: high
Title: Packages not signed by Oracle found on the system
Summary: The following packages have not been signed by Oracle and may be removed during the upgrade process in case Oracle-signed packages to be removed during the upgrade depend on them:
- collectd
- epel-release
- libzstd
Key: f5a5d58476a97bf0a8904d00df5d1321189849ad
----------------------------------------
Risk Factor: high
Title: Difference in Python versions and support in OL 8
Summary: In OL 8, there is no 'python' command. Python 3 (backward incompatible) is the primary Python version and Python 2 is available with limited support and limited set of packages. If you no longer require Python 2 packages following the upgrade, please remove them. Read more here: https://docs.oracle.com/en/operating-systems/oracle-linux/8/python/
Related links:
    - Difference in Python versions and support in OL 8: https://docs.oracle.com/en/operating-systems/oracle-linux/8/python/
Remediation: [hint] Please run "alternatives --set python /usr/bin/python3" after upgrade
Key: 2f3a43f4f448995eec953217d54f388ed94838b2
----------------------------------------
Risk Factor: high
Title: Some OL 7 packages have not been upgraded
Summary: Following OL 7 packages have not been upgraded:
kernel-3.10.0-1160.119.1.0.5.el7
kernel-uek-5.4.17-2136.338.4.2.el7uek
kernel-3.10.0-1160.11.1.el7
leapp-upgrade-el7toel8-0.20.0-2.0.11.el7_9
Please remove these packages to keep your system in supported state.

Key: 1e4e21ca7b2b7d9c59556f4b9813ef0d801af32c
...
...
...

Check new sysetm release and kernel

I checked release and kernel.

[root@SRV ~]# cat /etc/oracle-release
Oracle Linux Server release 8.10

[root@SRV ~]# uname -r
5.4.17-2136.356.4.2.el8uek.x86_64

[root@SRV ~]# grubby --default-kernel
/boot/vmlinuz-5.4.17-2136.356.4.2.el8uek.x86_64
[root@SRV ~]#

Which is correct, as I can see from following link that the last el8 release is 8.10:

https://yum.oracle.com/repo/OracleLinux/OL8/baseos/latest/x86_64/index.html

Check file system occupancy

I checked the file system occupancy and could confirm all is ok.

[root@SRV ~]# df -h
Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       252G     0  252G   0% /dev
tmpfs                          252G     0  252G   0% /dev/shm
tmpfs                          252G   11M  252G   1% /run
tmpfs                          252G     0  252G   0% /sys/fs/cgroup
/dev/mapper/vgroot--lv-root    7.5G  3.2G  4.3G  43% /
/dev/mapper/vgroot--lv-usr      12G  3.6G  7.7G  32% /usr
/dev/mapper/vgdata-lv--data    8.8T  5.0T  3.8T  57% /data
/dev/mapper/vgroot--lv-home    7.5G  3.9G  3.6G  53% /home
/dev/mapper/vgrdbms-lv--rdbms   11T  1.9T  8.7T  18% /rdbms
/dev/mapper/vgroot--lv-tmp     4.7G   33M  4.7G   1% /tmp
/dev/sdb2                      482M  330M  153M  69% /boot
/dev/sdb1                      952M  6.1M  946M   1% /boot/efi
/dev/mapper/vgroot--lv-opt      15G  627M   15G   5% /opt
/dev/mapper/vgroot--lv-var     9.4G  2.2G  7.2G  23% /var
tmpfs                           51G     0   51G   0% /run/user/0
[root@SRV ~]#

Postupgrade tasks

Now I will perform the standard and known postupgrade tasks to be run after an Oracle linux upgrade.

Doing this will also resolve all my high severity issue from the leapp report.

alternative for python

The command provided by the process did not work:

[root@SRV ~]# alternatives --set python /usr/bin/python3
failed to rename link /etc/alternatives/tmpdir.X8lXqU/tmp_sl -> /usr/share/man/man1/python.1.gz: Invalid cross-device link

If I check, I think I’m good as it is:

[root@SRV ~]# alternatives --display python
python - status is manual.
 link currently points to /usr/bin/python3
/usr/libexec/no-python - priority 404
 slave unversioned-python: (null)
 slave unversioned-python-man: /usr/share/man/man1/unversioned-python.1.gz
/usr/bin/python3 - priority 300
 slave unversioned-python: /usr/bin/python3
 slave unversioned-python-man: /usr/share/man/man1/python3.1.gz
/usr/bin/python2 - priority 200
 slave unversioned-python: /usr/bin/python2
 slave unversioned-python-man: /usr/share/man/man1/python2.1.gz
Current `best' version is /usr/libexec/no-python.

[root@SRV ~]# alternatives --display unversioned-python
[root@SRV ~]# readlink -f /usr/bin/python
/usr/libexec/platform-python3.6
[root@SRV ~]#

Moreover python is working:

[root@SRV ~]# which python
/usr/bin/python

[root@SRV ~]# ls -ltrh /usr/bin/python
lrwxrwxrwx. 1 root root 36 Jun 18 09:53 /usr/bin/python -> /etc/alternatives/unversioned-python

[root@SRV ~]# python --version
Python 3.6.8
[root@SRV ~]#

firewalld daemon

firewalld daemon was inactive before the upgrade, so I kept it as inactive.

[root@SRV ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)
[root@SRV ~]#

SELinux

I changed SE Linux from permissive to enforcing.

[root@SRV ~]# getenforce
Permissive

[root@SRV ~]# setenforce enforcing

[root@SRV ~]# getenforce
Enforcing

Permissive mode: SELinux logs policy violations but does not block them.
Enforcing mode: SELinux logs and blocks actions that violate the active policy.

I made the changes permanent:

[root@SRV ~]# grep -i ^SELINUX /etc/selinux/config
SELINUX=permissive
SELINUXTYPE=targeted

[root@SRV ~]# vi /etc/selinux/config

[root@SRV ~]# grep -i ^SELINUX /etc/selinux/config
SELINUX=Enforcing
SELINUXTYPE=targeted

[root@SRV ~]# cat /etc/selinux/config

# 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 three values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted


[root@SRV ~]#

Update dnf.conf

Edit /etc/dnf/dnf.conf and comment out exclude= that refer to leapp packages

[root@SRV ~]# grep -i leapp /etc/dnf/dnf.conf
exclude=python2-leapp,snactor,leapp-upgrade-el7toel8,leapp

[root@SRV ~]# vi /etc/dnf/dnf.conf

[root@SRV ~]# grep -i leapp /etc/dnf/dnf.conf
#exclude=python2-leapp,snactor,leapp-upgrade-el7toel8,leapp
[root@SRV ~]#

[root@SRV ~]# cat /etc/dnf/dnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
proxy=http://172.X.X.X:3128
#exclude=python2-leapp,snactor,leapp-upgrade-el7toel8,leapp
[root@SRV ~]#

set PermitRootLogin no and restart sshd service

We will add security here and not permitting to use root to login directly through ssh.

[root@SRV ~]# grep -i PermitRootLogin /etc/ssh/sshd_config
PermitRootLogin yes
# the setting of "PermitRootLogin without-password".

[root@SRV ~]# vi /etc/ssh/sshd_config

[root@SRV ~]# grep -i PermitRootLogin /etc/ssh/sshd_config
PermitRootLogin no
# the setting of "PermitRootLogin without-password".

[root@SRV ~]# systemctl restart sshd
[root@SRV ~]#

Remove old linux repo and package

We need to remove any el7 old package and repo that is still existing. We also need to remove leapp package.

I checked existing old ol7 one:

[root@SRV ~]# rpm -qa | grep el7
kernel-3.10.0-1160.119.1.0.5.el7.x86_64
leapp-0.17.0-1.0.2.el7_9.noarch
kernel-uek-5.4.17-2136.338.4.2.el7uek.x86_64
kernel-3.10.0-1160.11.1.el7.x86_64
python2-leapp-0.17.0-1.0.2.el7_9.noarch
leapp-upgrade-el7toel8-0.20.0-2.0.11.el7_9.noarch

I checked existing leapp package:

[root@SRV ~]# rpm -qa | grep leapp
leapp-0.17.0-1.0.2.el7_9.noarch
leapp-repository-deps-el8-5.0.8-100.202401121819Z.0e51aebb.master.el8.noarch
python2-leapp-0.17.0-1.0.2.el7_9.noarch
leapp-upgrade-el7toel8-0.20.0-2.0.11.el7_9.noarch
leapp-deps-el8-5.0.8-100.202401121819Z.0e51aebb.master.el8.noarch
[root@SRV ~]#

So I removed all those packages, as for example:

[root@SRV ~]# dnf remove kernel-3.10.0-1160.11.1.el7.x86_64
Dependencies resolved.
=============================================================================================================================================================================================
 Package                                  Architecture                             Version                                                   Repository                                 Size
=============================================================================================================================================================================================
Removing:
 kernel                                   x86_64                                   3.10.0-1160.11.1.el7                                      @System                                    64 M

DB8action Summary
=============================================================================================================================================================================================
Remove  1 Package

Freed space: 64 M
Is this ok [y/N]: y
Running DB8action check
DB8action check succeeded.
Running DB8action test
DB8action test succeeded.
Running DB8action
  Preparing        :                                                                                                                                                                     1/1
  Running scriptlet: kernel-3.10.0-1160.11.1.el7.x86_64                                                                                                                                  1/1
  Erasing          : kernel-3.10.0-1160.11.1.el7.x86_64                                                                                                                                  1/1
  Running scriptlet: kernel-3.10.0-1160.11.1.el7.x86_64                                                                                                                                  1/1
  Verifying        : kernel-3.10.0-1160.11.1.el7.x86_64                                                                                                                                  1/1

Removed:
  kernel-3.10.0-1160.11.1.el7.x86_64

Complete!

To finally have no more el7 and leapp package:

[root@SRV ~]# rpm -qa | grep el7
[root@SRV ~]# rpm -qa | grep leapp
[root@SRV ~]#

And of course I have got el8 package:

[root@SRV ~]# rpm -qa | grep el8 | wc -l
610
[root@SRV ~]#

Check kernel

I confirmed all is ok with the kernel and boot file system occupancy.

[root@SRV ~]# uname -r
5.4.17-2136.356.4.2.el8uek.x86_64

[root@SRV ~]# rpm -qa | grep -i kernel
kernel-modules-extra-4.18.0-553.132.1.el8_10.x86_64
kernel-core-4.18.0-553.132.1.el8_10.x86_64
kernel-tools-4.18.0-553.132.1.el8_10.x86_64
kernel-workaround-0.1-1.el8.noarch
kernel-4.18.0-553.132.1.el8_10.x86_64
kernel-headers-4.18.0-553.132.1.el8_10.x86_64
kernel-uek-5.4.17-2136.356.4.2.el8uek.x86_64
kernel-modules-4.18.0-553.132.1.el8_10.x86_64
kernel-tools-libs-4.18.0-553.132.1.el8_10.x86_64

[root@SRV ~]# df -h /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb2       482M  213M  270M  45% /boot

[root@SRV ~]# ls -ltrh /boot
total 188M
drwx------. 3 root root 4.0K Jan  1  1970 efi
-rw-------. 1 root root  60M Oct 28  2020 initramfs-0-rescue-939798bf09ac467188081e34260fbcfd.img
-rwxr-xr-x. 1 root root 6.5M Oct 28  2020 vmlinuz-0-rescue-939798bf09ac467188081e34260fbcfd
-rw-------. 1 root root 4.3M Jun  5 05:34 System.map-5.4.17-2136.356.4.2.el8uek.x86_64
-rw-r--r--. 1 root root 215K Jun  5 05:34 config-5.4.17-2136.356.4.2.el8uek.x86_64
-rwxr-xr-x. 1 root root  11M Jun  5 05:35 vmlinuz-5.4.17-2136.356.4.2.el8uek.x86_64
-rw-------. 1 root root 4.4M Jun 11 11:40 System.map-4.18.0-553.132.1.el8_10.x86_64
-rw-r--r--. 1 root root 198K Jun 11 11:40 config-4.18.0-553.132.1.el8_10.x86_64
-rwxr-xr-x. 1 root root  11M Jun 11 11:40 vmlinuz-4.18.0-553.132.1.el8_10.x86_64
drwxr-xr-x. 3 root root   21 Jun 18 09:33 loader
lrwxrwxrwx. 1 root root   57 Jun 18 09:35 symvers-5.4.17-2136.356.4.2.el8uek.x86_64.gz -> /lib/modules/5.4.17-2136.356.4.2.el8uek.x86_64/symvers.gz
lrwxrwxrwx. 1 root root   54 Jun 18 09:35 symvers-4.18.0-553.132.1.el8_10.x86_64.gz -> /lib/modules/4.18.0-553.132.1.el8_10.x86_64/symvers.gz
-rw-------. 1 root root  29M Jun 18 09:35 initramfs-4.18.0-553.132.1.el8_10.x86_64.img
drwx------. 2 root root   21 Jun 18 09:36 grub2
-rw-------. 1 root root  31M Jun 18 09:37 initramfs-5.4.17-2136.356.4.2.el8uek.x86_64.img
-rw-------. 1 root root  33M Jun 18 09:43 initramfs-5.4.17-2136.356.4.2.el8uek.x86_64kdump.img
[root@SRV ~]#

Relink oracle binaries

After a linux operating system, it is mandatory to relink all rdbms. This is mandatory to relink oracle executables to new operating system libraries.

I did following for all my dbhomes. As an example I will show you the process for rdbms193000.

First all oracle resources need to be stoppe. I stopped databases and listeners.

oracle@SRV:~/ [rdbms193000] ps -ef | grep -i [t]nslsn
oracle@SRV:~/ [rdbms193000] ps -ef | grep -i [p]mon
oracle@SRV:~/ [rdbms193000] 

Relink oracle dbhome:

oracle@SRV:~/ [rdbms193000] echo $ORACLE_HOME
/rdbms/u01/app/oracle/product/19.30.260120

oracle@SRV:~/ [rdbms193000] cd $ORACLE_HOME/bin

oracle@SRV:/rdbms/u01/app/oracle/product/19.30.260120/bin/ [rdbms193000] relink all
writing relink log to: /rdbms/u01/app/oracle/product/19.30.260120/install/relinkActions2026-06-18_10-31-37AM.log
oracle@SRV:/rdbms/u01/app/oracle/product/19.30.260120/bin/ [rdbms193000] tail /rdbms/u01/app/oracle/product/19.30.260120/install/relinkActions2026-06-18_10-31-37AM.log
rm -f /rdbms/u01/app/oracle/product/19.30.260120/bin/drdaproc

INFO:
mv /rdbms/u01/app/oracle/product/19.30.260120/rdbms/lib/drdaproc /rdbms/u01/app/oracle/product/19.30.260120/bin/drdaproc

INFO:
chmod 751 /rdbms/u01/app/oracle/product/19.30.260120/bin/drdaproc

INFO: End output from spawned process.
INFO: ----------------------------------
oracle@SRV:/rdbms/u01/app/oracle/product/19.30.260120/bin/ [rdbms193000]

But relink might change ownership and permissions on some oracle files:

oracle@SRV:~/ [rdbms193000] ls -ltrh  $ORACLE_HOME/bin/oracle
-rwsr-s--x. 1 oracle oinstall 448M Jun 18 10:32 /rdbms/u01/app/oracle/product/19.30.260120/bin/oracle

oracle@SRV:~/ [rdbms193000] ls -ltrh  $ORACLE_HOME/bin/extjob
-rwxr-xr-x. 1 oracle oinstall 3.0M Jun 18 10:31 /rdbms/u01/app/oracle/product/19.30.260120/bin/extjob

oracle@SRV:~/ [rdbms193000] ls -ltrh $ORACLE_HOME/rdbms/admin/externaljob.ora
-rw-r-----. 1 root oinstall 1.5K Dec 21  2005 /rdbms/u01/app/oracle/product/19.30.260120/rdbms/admin/externaljob.ora

oracle@SRV:~/ [rdbms193000] ls -ltrh $ORACLE_HOME/bin/jssu
-rwxr-xr-x. 1 oracle oinstall 2.3M Jun 18 10:31 /rdbms/u01/app/oracle/product/19.30.260120/bin/jssu
oracle@SRV:~/ [rdbms193000] 

This is why it is mandatory, after relink, to run root.sh. See also Executing “relink all” resets permission of extjob, jssu, oradism, externaljob.ora – KB148555.

Running root.sh goes went in failure:

[root@SRV ~]# cd /rdbms/u01/app/oracle/product/19.30.260120

[root@SRV 19.30.260120]# ./root.sh
Check /rdbms/u01/app/oracle/product/19.30.260120/install/root_SRV.INT.custname.CH_2026-06-18_10-37-33-682660639.log for the output of root script
[root@SRV 19.30.260120]# cat /rdbms/u01/app/oracle/product/19.30.260120/install/root_SRV.INT.custname.CH_2026-06-18_10-37-33-682660639.log
Performing root user operation.

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /rdbms/u01/app/oracle/product/19.30.260120
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
./root.sh: line 5: /rdbms/u01/app/oracle/product/19.30.260120/suptools/tfa/release/tfa_home/install/roottfa.sh: No such file or directory

See known issue: “Roottfa.sh: Not Found” after executing root.sh script. – KB104521

You might want to know that if you run root.sh as part of an ansible playbook you would have the same error, but the script would return a return code of 0, and you might not see that in fact root.sh could not be executed.

Resolve the problem by commenting out the tfa line, as we do not have tfa installed on our server.

[root@SRV 19.30.260120]# cat ./root.sh
#!/bin/sh
unset WAS_ROOTMACRO_CALL_MADE
. /rdbms/u01/app/oracle/product/19.30.260120/install/utl/rootmacro.sh "$@"
. /rdbms/u01/app/oracle/product/19.30.260120/install/utl/rootinstall.sh
/rdbms/u01/app/oracle/product/19.30.260120/suptools/tfa/release/tfa_home/install/roottfa.sh
/rdbms/u01/app/oracle/product/19.30.260120/install/root_schagent.sh

#
# Root Actions related to network
#
/rdbms/u01/app/oracle/product/19.30.260120/network/install/sqlnet/setowner.sh

#
# Invoke standalone rootadd_rdbms.sh
#
/rdbms/u01/app/oracle/product/19.30.260120/rdbms/install/rootadd_rdbms.sh

/rdbms/u01/app/oracle/product/19.30.260120/rdbms/install/rootadd_filemap.sh

[root@SRV 19.30.260120]# vi ./root.sh

[root@SRV 19.30.260120]# cat ./root.sh
#!/bin/sh
unset WAS_ROOTMACRO_CALL_MADE
. /rdbms/u01/app/oracle/product/19.30.260120/install/utl/rootmacro.sh "$@"
. /rdbms/u01/app/oracle/product/19.30.260120/install/utl/rootinstall.sh
#/rdbms/u01/app/oracle/product/19.30.260120/suptools/tfa/release/tfa_home/install/roottfa.sh
/rdbms/u01/app/oracle/product/19.30.260120/install/root_schagent.sh

#
# Root Actions related to network
#
/rdbms/u01/app/oracle/product/19.30.260120/network/install/sqlnet/setowner.sh

#
# Invoke standalone rootadd_rdbms.sh
#
/rdbms/u01/app/oracle/product/19.30.260120/rdbms/install/rootadd_rdbms.sh

/rdbms/u01/app/oracle/product/19.30.260120/rdbms/install/rootadd_filemap.sh

And I could successfully run root.sh.

[root@SRV 19.30.260120]# ./root.sh
Check /rdbms/u01/app/oracle/product/19.30.260120/install/root_SRV.INT.custname.CH_2026-06-18_10-39-42-830060996.log for the output of root script
[root@SRV 19.30.260120]# cat /rdbms/u01/app/oracle/product/19.30.260120/install/root_SRV.INT.custname.CH_2026-06-18_10-39-42-830060996.log
Performing root user operation.

The following environment variables are set as:
    ORACLE_OWNER= oracle
    ORACLE_HOME=  /rdbms/u01/app/oracle/product/19.30.260120
   Copying dbhome to /usr/local/bin ...
   Copying oraenv to /usr/local/bin ...
   Copying coraenv to /usr/local/bin ...

Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
[root@SRV 19.30.260120]#

And if I check, my files permissions are now all good:

oracle@SRV:~/ [rdbms193000] ls -ltrh  $ORACLE_HOME/bin/oracle
-rwsr-s--x. 1 oracle oinstall 448M Jun 18 10:32 /rdbms/u01/app/oracle/product/19.30.260120/bin/oracle

oracle@SRV:~/ [rdbms193000] ls -ltrh  $ORACLE_HOME/bin/extjob
-rwsr-x---. 1 root oinstall 3.0M Jun 18 10:31 /rdbms/u01/app/oracle/product/19.30.260120/bin/extjob

oracle@SRV:~/ [rdbms193000] ls -ltrh $ORACLE_HOME/rdbms/admin/externaljob.ora
-rw-r-----. 1 root oinstall 1.5K Dec 21  2005 /rdbms/u01/app/oracle/product/19.30.260120/rdbms/admin/externaljob.ora

oracle@SRV:~/ [rdbms193000] ls -ltrh $ORACLE_HOME/bin/jssu
-rwsr-x---. 1 root oinstall 2.3M Jun 18 10:31 /rdbms/u01/app/oracle/product/19.30.260120/bin/jssu
oracle@SRV:~/ [rdbms193000]

Activate CIFS again

Now I can update the fstab if I deactivated at the beginning the CIFS mount point, and I can mount all of them.

oratab file

I will also update my oratab so the needed database will be restarted automatically at next reboot.

oracle@SRV:~/ [rdbms193000] vi /etc/oratab

oracle@SRV:~/ [rdbms193000] cat /etc/oratab
#



# This file is used by ORACLE utilities.  It is created by root.sh
# and updated by either Database Configuration Assistant while creating
# a database or ASM Configuration Assistant while creating ASM instance.

# A colon, ':', is used as the field terminator.  A new line terminates
# the entry.  Lines beginning with a pound sign, '#', are comments.
#
# Entries are of the form:
#   $ORACLE_SID:$ORACLE_HOME::
#
# The first and second fields are the system identifier and home
# directory of the database respectively.  The third field indicates
# to the dbstart utility that the database should , "Y", or should not,
# "N", be brought up at system boot time.
#
# Multiple entries with the same $ORACLE_SID are not allowed.
#
#
DB10:/rdbms/u01/app/oracle/product/19.30.260120:N
DB3:/rdbms/u01/app/oracle/product/19.30.260120:Y
DB9:/rdbms/u01/app/oracle/product/19.30.260120:Y
DB4:/rdbms/u01/app/oracle/product/19.30.260120:Y
DB1:/rdbms/u01/app/oracle/product/19.30.260120:Y
DB8:/rdbms/u01/app/oracle/product/19.30.260120:Y
DB7:/rdbms/u01/app/oracle/product/19.30.260120:Y
DB2:/rdbms/u01/app/oracle/product/19.30.260120:Y
DB5:/rdbms/u01/app/oracle/product/19.30.260120_MX:Y
DB6:/rdbms/u01/app/oracle/product/19.30.260120_MX:Y

Cleanup

I will remove leapp directory.

[root@SRV ~]# ls -ltrh /root/tmp_leapp_py3
total 4.0K
-rwxrwx---. 1 root root 118 Jun 18 09:36 leapp3
lrwxrwxrwx. 1 root root  38 Jun 18 09:36 leapp -> /usr/lib/python2.7/site-packages/leapp

[root@SRV ~]# rm -rf /root/tmp_leapp_py3

[root@SRV ~]# ls -ltrh /root/tmp_leapp_py3
ls: cannot access '/root/tmp_leapp_py3': No such file or directory
[root@SRV ~]#

Check rpm release

I ensured that I only have el8 package and no more el7 package.

[root@SRV ~]# rpm -qa | grep -i el7
[root@SRV ~]# rpm -qa | grep -i ol7
[root@SRV ~]# rpm -qa | grep -i el8 | wc -l
610
[root@SRV ~]# rpm -qa | grep -i el8 | tail -n3
libxmlb-0.1.15-1.el8.x86_64
libnetfilter_conntrack-1.0.6-5.el8.x86_64
librepo-1.14.2-5.el8.x86_64
[root@SRV ~]#

Remove el7 repo

It is also important to check the repo, because leapp upgrade will not remove customized repo running on el7.

As I can see here, I still have epel el7 repo.

[root@SRV ~]# dnf repolist all
repo id                                                           repo name                                                                                                          status
epel                                                              Extra Packages for Enterprise Linux 7 - x86_64                                                                     enabled
epel-debuginfo                                                    Extra Packages for Enterprise Linux 7 - x86_64 - Debug                                                             disabled
epel-source                                                       Extra Packages for Enterprise Linux 7 - x86_64 - Source                                                            disabled
epel-testing                                                      Extra Packages for Enterprise Linux 7 - Testing - x86_64                                                           disabled
epel-testing-debuginfo                                            Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Debug                                                   disabled
epel-testing-source                                               Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Source                                                  disabled
ol8_MODRHCK                                                       Latest RHCK with fixes from Oracle for Oracle Linux 8 (x86_64)                                                     disabled
ol8_UEKR6                                                         Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)                                         enabled
ol8_UEKR6_RDMA                                                    Oracle Linux 8 UEK6 RDMA (x86_64)                                                                                  disabled
ol8_UEKR7                                                         Latest Unbreakable Enterprise Kernel Release 7 for Oracle Linux 8 (x86_64)                                         disabled
ol8_UEKR7_RDMA                                                    Oracle Linux 8 UEK7 RDMA (x86_64)                                                                                  disabled
...
...
...

Moreover those el7 repo are enabled.

I removed it.

[root@SRV ~]# rpm -qa | grep -i epel
epel-release-7-14.noarch

[root@SRV ~]# ls -ltrh /etc/yum.repos.d/*epel*
-rw-r--r--. 1 root root 1.5K Sep  4  2021 /etc/yum.repos.d/epel-testing.repo
-rw-r--r--. 1 root root 1.4K Sep  4  2021 /etc/yum.repos.d/epel.repo

[root@SRV ~]# dnf remove epel-release-7-14.noarch
Dependencies resolved.
=============================================================================================================================================================================================
 Package                                           Architecture                                Version                                    Repository                                    Size
=============================================================================================================================================================================================
Removing:
 epel-release                                      noarch                                      7-14                                       @System                                       25 k

DB8action Summary
=============================================================================================================================================================================================
Remove  1 Package

Freed space: 25 k
Is this ok [y/N]: y
Running DB8action check
DB8action check succeeded.
Running DB8action test
DB8action test succeeded.
Running DB8action
  Preparing        :                                                                                                                                                                     1/1
  Running scriptlet: epel-release-7-14.noarch                                                                                                                                            1/1
  Erasing          : epel-release-7-14.noarch                                                                                                                                            1/1
  Running scriptlet: epel-release-7-14.noarch                                                                                                                                            1/1
  Verifying        : epel-release-7-14.noarch                                                                                                                                            1/1

Removed:
  epel-release-7-14.noarch

Complete!

And I’m good.

[root@SRV ~]# rpm -qa | grep -i epel
[root@SRV ~]# ls -ltrh /etc/yum.repos.d/*epel*
ls: cannot access '/etc/yum.repos.d/*epel*': No such file or directory
[root@SRV ~]#

And I can ensure that only el8 repo are enabled.

[root@SRV ~]# dnf repolist all --enabled
repo id                                                           repo name
ol8_UEKR6                                                         Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)
ol8_appstream                                                     Oracle Linux 8 Application Stream (x86_64)
ol8_baseos_latest                                                 Oracle Linux 8 BaseOS Latest (x86_64)
[root@SRV ~]#

If needed I can install epel for el8.

[root@SRV ~]# dnf install oracle-epel-release-el8
Oracle Linux 8 BaseOS Latest (x86_64)                                                                                                                        3.6 MB/s | 145 MB     00:40
Oracle Linux 8 Application Stream (x86_64)                                                                                                                   2.9 MB/s |  82 MB     00:28
Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)                                                                                   4.4 MB/s | 148 MB     00:33
Last metadata expiration check: 0:00:23 ago on Thu 18 Jun 2026 11:04:31 AM CEST.
Dependencies resolved.
=============================================================================================================================================================================================
 Package                                               Architecture                         Version                                    Repository                                       Size
=============================================================================================================================================================================================
Installing:
 oracle-epel-release-el8                               x86_64                               1.0-5.el8                                  ol8_baseos_latest                                15 k

DB8action Summary
=============================================================================================================================================================================================
Install  1 Package

Total download size: 15 k
Installed size: 18 k
Is this ok [y/N]: y
Downloading Packages:
oracle-epel-release-el8-1.0-5.el8.x86_64.rpm                                                                                                                 133 kB/s |  15 kB     00:00
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total                                                                                                                                                        131 kB/s |  15 kB     00:00
Running DB8action check
DB8action check succeeded.
Running DB8action test
DB8action test succeeded.
Running DB8action
  Preparing        :                                                                                                                                                                     1/1
  Installing       : oracle-epel-release-el8-1.0-5.el8.x86_64                                                                                                                            1/1
  Verifying        : oracle-epel-release-el8-1.0-5.el8.x86_64                                                                                                                            1/1

Installed:
  oracle-epel-release-el8-1.0-5.el8.x86_64

Complete!

I can check again my list of activated repo and I will find the new one in.

[root@SRV ~]# dnf repolist all --enabled
repo id                                                                repo name
ol8_UEKR6                                                              Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)
ol8_appstream                                                          Oracle Linux 8 Application Stream (x86_64)
ol8_baseos_latest                                                      Oracle Linux 8 BaseOS Latest (x86_64)
ol8_developer_EPEL                                                     Oracle Linux 8 EPEL Packages for Development (x86_64)
ol8_developer_EPEL_modular                                             Oracle Linux 8 EPEL Modular Packages for Development (x86_64)
[root@SRV ~]#

I also remove leapp repository, as I do not need it any more.

[root@SRV ~]# ls -ltrh /etc/yum.repos.d/
total 28K
-rw-r--r--. 1 root root  530 Mar 28  2022 oracle-epel-ol8.repo
-rw-r--r--. 1 root root  243 May 23  2024 virt-ol8.repo
-rw-r--r--. 1 root root 4.5K Sep 19  2025 leapp-upgrade-repos-ol8.repo.save
-rw-r--r--. 1 root root 4.1K Jun 18 09:43 oracle-linux-ol8.repo
-rw-r--r--. 1 root root  941 Jun 18 09:43 uek-ol8.repo

[root@SRV ~]# rm -f /etc/yum.repos.d/leapp-upgrade-repos-ol8.repo.save

[root@SRV ~]# ls -ltrh /etc/yum.repos.d/
total 20K
-rw-r--r--. 1 root root  530 Mar 28  2022 oracle-epel-ol8.repo
-rw-r--r--. 1 root root  243 May 23  2024 virt-ol8.repo
-rw-r--r--. 1 root root 4.1K Jun 18 09:43 oracle-linux-ol8.repo
-rw-r--r--. 1 root root  941 Jun 18 09:43 uek-ol8.repo

I also could verify that I do not have any el7 old repo any more.

[root@SRV ~]# grep -i el7 /etc/yum.repos.d/*
[root@SRV ~]# grep -i el8 /etc/yum.repos.d/* | wc -l
0
[root@SRV ~]# grep -i ol8 /etc/yum.repos.d/* | wc -l
50
[root@SRV ~]# grep -i ol7 /etc/yum.repos.d/* | wc -l
0
[root@SRV ~]#

Reboot

I finally rebooted the server one last time before giving it back to the application team, to ensure all is ok.

To wrap up…

I showed how to upgrade an Oracle Linux from version el7 to el8. The process would exactly be the same for higher. I could not upgrade to el9 because the server was not supporting it. It is a production server that will still be replaced by customer, in one or two years, and it was important to upgrade Oracle Linux for security audit.

Also I could confirm that the last critical CVE as Dirty Frag (Copy Fail 2) are covered and that the last el8 version has the correction:

[root@SRV ~]# uname -r
5.4.17-2136.356.4.2.el8uek.x86_64

[root@SRV ~]# rpm -q --changelog kernel-uek-5.4.17-2136.356.4.2.el8uek | grep -iE 'CVE-2026-31431|CVE-2026-43284|CVE-2026-46300'
- net: skbuff: propagate shared-frag marker through frag-DB8fer helpers (Hyunwoo Kim) [Orabug: 39368828,39441326] {CVE-2026-43503,CVE-2026-46300}
- net: skbuff: preserve shared-frag marker during coalescing (William Bowling) [Orabug: 39368828] {CVE-2026-46300}
- xfrm: esp: avoid in-place decrypt on shared skb frags (Kuan-Ting Chen) [Orabug: 39334580,39367147] {CVE-2026-43284}
- crypto: algif_aead - Revert to operating out-of-place (Herbert Xu) [Orabug: 39250687,39283868,39292250] {CVE-2026-31431}
- crypto: algif_aead - use memcpy_sglist() instead of null skcipher (Eric Biggers) [Orabug: 39250687] {CVE-2026-31431}
[root@SRV ~]#

L’article Upgrading Oracle Linux when running Oracle databases est apparu en premier sur dbi Blog.