Great sessions

We had the opportunity to participate to great sessions. We discussed about some customer use cases, as for example having multiple standby. Such configuration are easy to implement and the product gives the facility to ship the archived log from the primary to multiple standby, which is the recommended configuration, or even cascading standby, having one standby been updated through another standby. The only catch is that, after performing a switchover, you need to manually update the other standby databases with the new source hostname. Also, all your standby databases need to be recreated from scratch after a failover. Of course, with Standard Edition, there is no Flashback Database, so there is no reinstate. A failover also results in a new database incarnation. I could really recall some of our customers configuration during those discussions.

We also discussed about the need to have all customer old version 9, 10 and 11 upgraded to version 12.

There were also some good discussions for new VIP implementations simplifying the application connection after a switchover. There is mainly several solutions for connecting the database from the application side without having to change anything for the business after a switchover:

• Connection with address list using an oracle service that would only be started on primary. If and only if the application supports it. The same could be done for standby database connection used for reporting.
• Have a Virtual IP address created and automatically started on the primary database host
• Network alias

The objective to have all managed automatically on the database side with no change on the application connection string.

Let’s wait for a great new feature on dbvisit having the possibility to create and administrate those configurations directly from the GUI. GUI which could monitor the oracle services and the VIP.

We also discussed the snapshot capabilities provided by Dbvisit. I took the opportunity to reiterate how great it would be to have ACFS snapshots supported. This would help all our ODA customers avoid having them to rely on third-party scripts.

Zero Data Loss

We also had the chance to discuss about the great new functionality of dbvisit : Zero Data Loss.

Thanks Alex!

This feature will give the opportunity for Standard Edition 2 Oracle database customer to improve a lot their RPO, reducing dramatically the data loss after a disaster. This will give Standard Edition customers the ability to get closed to data service availability proposed by the Enterprise Edition.

How it works? The archived log shipment thread would remain and we would have an additional redo log shipment thread to have the redo as well synchronized. The redo on the standby side would only be used, after a failover to apply last redo transactions.

What is also good is that a low RPO would also help to improve the RTO. And we could even activate it in a multiple standby databases environment. And what about a standby database configured with delay? We can also activate ZDL with a standby database configured with delay as the software will allow us to apply all last archive log and last redo transaction after activating it.

This feature needs to be activated with an additional license.

If you want to learn more about the feature, please visit following links:

https://dbvisit.com/solutions/standby-software#how

Great visit of Paris

What a great way to combine work and a visit to Paris — all while cruising along the Seine!

And thanks for the nice goodies.

L’article A great day at Dbvisit Partner Summit 2026 in Paris for oracle SE databases 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.

Prepare OMS connection to host target

I need to have a ssh key pair to be able to connect from my OEM to the target DB System when adding the agent.

Create ssh key pair

I first need to create a ssh key pair. I created the ssh key with ops user from the OMS server.

[opc@oms1 ~]$ cd .ssh

[opc@oms1 .ssh]$ pwd
/home/opc/.ssh

[opc@oms1 .ssh]$ ls -al
total 8
drwx------. 2 opc opc   48 Jul 21 11:50 .
drwx------. 3 opc opc  115 Jul 13 09:13 ..
-rw-------. 1 opc opc 1467 Jul 13 08:02 authorized_keys
-rw-r--r--. 1 opc opc   95 Jul 21 11:50 known_hosts

[opc@oms1 .ssh]$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/oem_agent_key
Generating public/private rsa key pair.
Enter passphrase for "/home/opc/.ssh/oem_agent_key" (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/opc/.ssh/oem_agent_key
Your public key has been saved in /home/opc/.ssh/oem_agent_key.pub
The key fingerprint is:
SHA256:K5xoWmpI6WCEmKlPVUthV9Ckwg6ehjkbPHWYc7D6RL4 opc@oms1
The key's randomart image is:
+---[RSA 4096]----+
|    . o.o=o      |
|     Bo. ..      |
|oo  Oo=..        |
|=o O.B..         |
|o X.* . S        |
|o+.O + . .       |
|=+. E + .        |
|..o=   .         |
| .o              |
+----[SHA256]-----+

[opc@oms1 .ssh]$ ls -al
total 16
drwx------. 2 opc opc   94 Jul 21 14:26 .
drwx------. 3 opc opc  115 Jul 13 09:13 ..
-rw-------. 1 opc opc 1467 Jul 13 08:02 authorized_keys
-rw-r--r--. 1 opc opc   95 Jul 21 11:50 known_hosts
-rw-------. 1 opc opc 3369 Jul 21 14:26 oem_agent_key
-rw-r--r--. 1 opc opc  734 Jul 21 14:26 oem_agent_key.pub
[opc@oms1 .ssh]$

I have now both private and public keys, named respectively, oem_agent_key and oem_agent_key.pub.

Add the key on the target DB-System

I will get the content of my public key:

[opc@oms1 .ssh]$ cat oem_agent_key.pub
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA...D8XdH9w7OCaTl9STwQhml1llLmznDdJu2QmfcWT/Wj1u+JM/zpYyA2EhMY6lsQ== opc@oms1
[opc@oms1 .ssh]$

And add the content of the public key to my DB System authorized_keys file.

[opc@svl-orap-chz0-cl1n1 ~]$ cd .ssh

[opc@svl-orap-chz0-cl1n1 .ssh]$ pwd
/home/opc/.ssh

[opc@svl-orap-chz0-cl1n1 .ssh]$ ls -ltrh
total 8.0K
-rw------- 1 root root 102 Jul 22 06:35 authorized_keys.bkp
-rw------- 1 opc  opc  503 Jul 22 06:58 authorized_keys

[opc@svl-orap-chz0-cl1n1 .ssh]$ cp -p authorized_keys authorized_keys.bkp.20260722

[opc@svl-orap-chz0-cl1n1 .ssh]$ vi authorized_keys

[opc@svl-orap-chz0-cl1n1 .ssh]$ tail -n1 authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAADAQAB...1ID8XdH9w7OCaTl9STwQhml1llLmznDdJu2QmfcWT/Wj1u+JM/zpYyA2EhMY6lsQ== opc@oms1
[opc@svl-orap-chz0-cl1n1 .ssh]$

Test connection from opc oms

I will test the connection and see if I can connect from my OMS server to the DB System.

[opc@oms1 .ssh]$ pwd
/home/opc/.ssh

[opc@oms1 .ssh]$ ls -ltrh
total 16K
-rw-------. 1 opc opc 1.5K Jul 13 08:02 authorized_keys
-rw-r--r--. 1 opc opc   95 Jul 21 11:50 known_hosts
-rw-r--r--. 1 opc opc  734 Jul 21 14:26 oem_agent_key.pub
-rw-------. 1 opc opc 3.3K Jul 21 14:26 oem_agent_key

[opc@oms1 .ssh]$ ssh -i oem_agent_key opc@192.168.1.245
Last login: Wed Jul 22 07:27:49 2026 from 192.168.0.89
[opc@svl-orap-chz0-cl1n1 ~]$

Which is successful.

Installing a Standalone Oracle Management Agent Using Add Host Targets Wizard or EM CLI

Deployment of the agent through the console

Now I can deploy my agent on the DB Systems through EOM console. For this I will use, the “Add Targets Manually” option from the “Setup” menu.

I will use “Add Host Targets” and “Install Agent on Host”.

I will provide all needed information as hostname, platform. As it is a lab and I do not have any DNS I have used the IP address. This is perfectly working, but of course for a production system you will be using the hostname and rarely IP addresses.

I will therefore get the warning message which I will accept.

I will need to provide agent installation directories before clicking the “next” button.

I will get following error because the credentials are missing.

I will provide the credential to OMS to connect to the DB System through the OPC user with sudo privilege, using the key pair I had initially created.

I will do the same for the root credential.

And finally click the “Next” button again.

Now I can deploy the agent on the DB System.

The installation is starting.

Issue #1: Agent deployed as OPC user

I could first see that the agent would be deployed with OPC user. Which make sense, I have given opc as username.

Let’s change the user and provide oracle and root as username in the configuration of the GUI to deploy the agent.

I will first add the key for the oracle user.

[oracle@svl-orap-chz0-cl1n1 .ssh]$ pwd
/home/oracle/.ssh

[oracle@svl-orap-chz0-cl1n1 .ssh]$ ls -ltrh
total 16K
-rw-r--r-- 1 oracle oinstall  580 Jun 18 05:59 id_rsa.pub
-rw------- 1 oracle oinstall 2.6K Jun 18 05:59 id_rsa
-rw-r--r-- 1 oracle oinstall  580 Jun 18 05:59 authorized_keys
-rw-r--r-- 1 oracle oinstall  573 Jun 18 05:59 known_hosts

[oracle@svl-orap-chz0-cl1n1 .ssh]$ cp -p authorized_keys authorized_keys.bkp.20260722

[oracle@svl-orap-chz0-cl1n1 .ssh]$ echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC0gtuJAJuw7eS/luTIo4Z0P7ixDEjVlv+q9rLcDgS3Jb8dy4kdAUjgnLjsRYKHZm+LD857hC/C69dT5Xc3TiZgTO/jvORnZRoIGmKFKc6g497AVkm0y...9RPodK1ID8XdH9w7OCaTl9STwQhml1llLmznDdJu2QmfcWT/Wj1u+JM/zpYyA2EhMY6lsQ== opc@oms1' > authorized_keys
[oracle@svl-orap-chz0-cl1n1 .ssh]$

Let’s test the connection.

[opc@oms1 .ssh]$ ssh -i oem_agent_key oracle@192.168.1.245
Last login: Wed Jul 22 08:07:00 2026
[oracle@svl-orap-chz0-cl1n1 ~]$

Successful.

Doing the same for user root will not be possible:

[opc@oms1 .ssh]$ ssh -i oem_agent_key root@192.168.1.245
root@192.168.1.245's password:

Because of the sshd configuration:

[root@svl-orap-chz0-cl1n1 ~]# sudo grep -E '^(PermitRootLogin|PubkeyAuthentication|PasswordAuthentication)' /etc/ssh/sshd_config
PasswordAuthentication yes
PermitRootLogin no
PermitRootLogin no
[root@svl-orap-chz0-cl1n1 ~]#

root ssh login are disabled. So leave it as it is for root. Root access will be needed to run root.sh script which we can do manually.

So now I will update the inputs and retry the installation.

As previously told, I will change username opc with oracle for named credential.

I changed the root credential with username root as well, which will not work, but it is not a problem, I will run the root.sh script manually. I later wondered if I would not better had to keep opc. I will be able to test this on a next agent installation.

Issue #2: Permissions for directory creation

Facing next issue:

I could easily determine the problem. Oracle has no permission to write in the oracle directory.

Which is correct, as root is owner of the oracle directory and other group do not have access to it.

[oracle@svl-orap-chz0-cl1n1 opt]$ pwd
/opt

[oracle@svl-orap-chz0-cl1n1 opt]$ ls -ld oracle
drwxr-xr-x 13 root root 4096 Jul 22 07:55 oracle
[oracle@svl-orap-chz0-cl1n1 opt]$

Let’s create the directory manually.

[root@svl-orap-chz0-cl1n1 ~]# cd /opt/oracle

[root@svl-orap-chz0-cl1n1 oracle]# mkdir agentem24ai

[root@svl-orap-chz0-cl1n1 oracle]# chown oracle: agentem24ai

[root@svl-orap-chz0-cl1n1 oracle]# ls -ld agentem24ai
drwxr-xr-x 2 oracle oinstall 4096 Jul 22 08:22 agentem24ai
[root@svl-orap-chz0-cl1n1 oracle]#

And I retried using same inputs. This will use same installation configuration parameters, cleaning the existing agent installation and starting a new installation.

This step was then successful.

Next warning can be ignored as I will run root.sh manually.

Issue #3: Naming resolution issue

I then got next error:

This is a naming resolution issue from target to OMS server.

[opc@svl-orap-chz0-cl1n1 ~]$ sudo ping oms1
ping: oms1: Name or service not known

As workaround, knowing I do not have any DNS server, I have just updated /etc/hosts file.

[opc@svl-orap-chz0-cl1n1 ~]$ sudo grep -i oms1 /etc/hosts
[opc@svl-orap-chz0-cl1n1 ~]$ sudo vi /etc/hosts
[opc@svl-orap-chz0-cl1n1 ~]$ sudo grep -i oms1 /etc/hosts
192.168.1.142  oms1

And could now successfully confirmed naming resolution is working.

[opc@svl-orap-chz0-cl1n1 ~]$ sudo ping oms1
PING oms1 (192.168.1.142) 56(84) bytes of data.
64 bytes from oms1 (192.168.1.142): icmp_seq=1 ttl=64 time=0.304 ms
64 bytes from oms1 (192.168.1.142): icmp_seq=2 ttl=64 time=0.315 ms
^C
--- oms1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1011ms
rtt min/avg/max/mdev = 0.304/0.309/0.315/0.018 ms
[opc@svl-orap-chz0-cl1n1 ~]$

I have then retried a new installation with the menu “Retry Using Same Inputs”

Issue #4: Need to manually run root.sh

I then faced the expected error, where I will need to run root.sh manually.

This is expected as oracle has no root sudo privilege. So let’s run root.sh manually.

[opc@svl-orap-chz0-cl1n1 ~]$ sudo su - root
Last login: Wed Jul 22 08:30:59 UTC 2026

[root@svl-orap-chz0-cl1n1 ~]# /opt/oracle/agentem24ai/agent_24.1.0.0.0/root.sh

Finished product-specific root actions.
/etc exist

Creating /etc/oragchomelist file...
[root@svl-orap-chz0-cl1n1 ~]#

And I retried a new installation with the menu “Retry Using Same Inputs”.

Issue #5: Agent service start issue

I then faced a new issue, see below:

This seems correct, the agent is not started and starting it is failing.

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl status agent
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
Agent is Not Running

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl start agent
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
Starting agent ......... failed.
HTTP Listener failed at Startup
Possible port conflict on port(3872): Retrying the operation........
Failed to start the agent after 6 attempts.  Please check that the port(3872) is available.
Consult emctl.log and emagent.nohup in: /opt/oracle/agentem24ai/agent_inst/sysman/log
[oracle@svl-orap-chz0-cl1n1 ~]$

The log will show the same:

[oracle@svl-orap-chz0-cl1n1 log]$ pwd
/opt/oracle/agentem24ai/agent_inst/sysman/log

[oracle@svl-orap-chz0-cl1n1 log]$ view gcagent.log
...
Caused by: oracle.sysman.gcagent.comm.agent.FatalException: unable to start the HTTP server: Failed to bind to 0.0.0.0/0.0.0.0:3872

I could see that the agent can not start because the port 3872 on the server is already in used:

[oracle@svl-orap-chz0-cl1n1 ~]$ ss -ltnp | grep ':3872'
LISTEN 0      50           0.0.0.0:3872       0.0.0.0:*    users:(("java",pid=27399,fd=122))
[oracle@svl-orap-chz0-cl1n1 ~]$

Checking the PID process, I could see that it is the agent itself, so from a previous installation were the installer did not stop the agent correctly.

[oracle@svl-orap-chz0-cl1n1 ~]$ ps -ef | grep 27399
oracle   27399 27348  0 08:46 ?        00:00:11 /opt/oracle/agentem24ai/agent_24.1.0.0.0/oracle_common/jdk/bin/java -Xmx128M -XX:MaxMetaspaceSize=192M -server -Djava.security.egd=file:///dev/./urandom -Dsun.lang.ClassLoader.allowArraySyntax=true -XX:-UseLargePages -XX:+UseLinuxPosixThreadCPUClocks -XX:+UseConcMarkSweepGC...

I killed the process and ensure the port is free:

[oracle@svl-orap-chz0-cl1n1 ~]$ kill -9 27399
[oracle@svl-orap-chz0-cl1n1 ~]$ ss -ltnp | grep ':3872'
[oracle@svl-orap-chz0-cl1n1 ~]$ 

And could then run both commands (start agent and config agent):

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl start agent
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
Starting agent ...... started.

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl config agent addinternaltargets
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
[oracle@svl-orap-chz0-cl1n1 ~]$

Agent could now successfully start.

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl status agent
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
Agent Version          : 24.1.0.0.0
OMS Version            : 24.1.0.0.0
Protocol Version       : 12.1.0.1.0
Agent Home             : /opt/oracle/agentem24ai/agent_inst
Agent Log Directory    : /opt/oracle/agentem24ai/agent_inst/sysman/log
Agent Binaries         : /opt/oracle/agentem24ai/agent_24.1.0.0.0
Core JAR Location      : /opt/oracle/agentem24ai/agent_24.1.0.0.0/jlib
Agent Process ID       : 81277
Parent Process ID      : 81227
Agent URL              : https://192.168.1.245:3872/emd/main/
Local Agent URL in NAT : https://192.168.1.245:3872/emd/main/
Repository URL         : https://oms1:4900/empbs/upload
Started at             : 2026-07-22 09:32:31
Started by user        : oracle
Operating System       : Linux version 5.15.0-319.201.4.6.el8uek.x86_64 (amd64)
Number of Targets      : (none)
Last Reload            : (none)
Last successful upload                       : 2026-07-22 09:32:44
Last attempted upload                        : 2026-07-22 09:32:44
Total Megabytes of XML files uploaded so far : 0
Number of XML files pending upload           : 0
Size of XML files pending upload(MB)         : 0
Available disk space on upload filesystem    : 79.83%
Collection Status                            : Collections enabled
Heartbeat Status                             : Ok
Last attempted heartbeat to OMS              : 2026-07-22 09:36:33
Last successful heartbeat to OMS             : 2026-07-22 09:36:33
Next scheduled heartbeat to OMS              : 2026-07-22 09:37:33

---------------------------------------------------------------
Agent is Running and Ready
[oracle@svl-orap-chz0-cl1n1 ~]$

I ensure that the port is free before doing a new last installation, by stopping the agent manually and checking the port is free.

I then retry a full installation again, and all went properly. I just had to run root.sh manually. This was expected. The only sad point is that the installer will stop here in failure, when it should just provide a warning.

I run root.sh manually.

[root@svl-orap-chz0-cl1n1 ~]# /opt/oracle/agentem24ai/agent_24.1.0.0.0/root.sh

Finished product-specific root actions.
/etc exist
[root@svl-orap-chz0-cl1n1 ~]#

Check target host in the console

We can see our new target in OEM but having an issue connecting to the agent on the port 3872.

From the OMS server I can ping the DB System:

[oracle@oms1 ~]$ ping 192.168.1.245
PING 192.168.1.245 (192.168.1.245) 56(84) bytes of data.
64 bytes from 192.168.1.245: icmp_seq=1 ttl=64 time=0.356 ms
64 bytes from 192.168.1.245: icmp_seq=2 ttl=64 time=0.234 ms
64 bytes from 192.168.1.245: icmp_seq=3 ttl=64 time=0.239 ms
^C
--- 192.168.1.245 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms
rtt min/avg/max/mdev = 0.234/0.276/0.356/0.056 ms
[oracle@oms1 ~]$

But from the OMS server I can not reach the DB System on the 3872 port:

[oracle@oms1 ~]$ nc -zv 192.168.1.245 3872
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: No route to host.

I confirm that from the OMS server I can reach the DB System on the port 22:

[oracle@oms1 ~]$ nc -vz 192.168.1.245 22
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.1.245:22.
Ncat: 0 bytes sent, 0 bytes received in 0.03 seconds.
[oracle@oms1 ~]$

To understand what is happening I ran a tcpdump.

[opc@svl-orap-chz0-cl1n1 ~]$ sudo tcpdump -nn -i any port 3872
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
13:24:11.765793 IP 192.168.1.142.20016 > 192.168.1.245.3872: Flags [S], seq 3591942206, win 62720, options [mss 8960,sackOK,TS val 1202488162 ecr 0,nop,wscale 7], length 0

We can clearly see that the OMS server is sending a TCP SYN packet to the DB server but we do not see the SYN-ACK packet coming back. So clearly a firewall issue. I checked the OCI policies and all were ok. So let’s check if there is any local firewall configured on the DB System.

We can check nftables configuration using following command:

[opc@svl-orap-chz0-cl1n1 ~]$ sudo nft list ruleset

Doing so, I realized that port 3872 is not in the allowed rules:

chain INPUT {
    type filter hook input priority filter;
    policy accept;

    ...

    meta l4proto tcp ct state new tcp dport 2484 accept
    meta l4proto tcp ct state new tcp dport 22 accept
    meta l4proto tcp ct state new tcp dport 1521 accept
    meta l4proto tcp ct state new tcp dport 1522 accept
    meta l4proto tcp ct state new tcp dport 5000 accept
    meta l4proto tcp ct state new tcp dport 6200 accept

    ...

    counter packets 116 bytes 6604 reject with icmp type host-prohibited
}

I added the rule in iptables:

[opc@svl-orap-chz0-cl1n1 ~]$ sudo iptables -I INPUT 1 -p tcp -s 192.168.1.142 --dport 3872 -m conntrack --ctstate NEW -j ACCEPT

And I could then connect successfully from the OMS server to my DB System on port 3872:

[oracle@oms1 ~]$ nc -vz 192.168.1.245 3872
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 192.168.1.245:3872.
Ncat: 0 bytes sent, 0 bytes received in 0.03 seconds.
[oracle@oms1 ~]$

I made the changes permanent:

[opc@svl-orap-chz0-cl1n1 ~]$ sudo systemctl status iptables
● iptables.service - IPv4 firewall with iptables
   Loaded: loaded (/usr/lib/systemd/system/iptables.service; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2026-07-22 06:35:33 UTC; 7h ago
 Main PID: 1550 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 79998)
   Memory: 0B
   CGroup: /system.slice/iptables.service

Jul 22 06:35:33 svl-orap-chz0-cl1n1 systemd[1]: Starting IPv4 firewall with iptables...
Jul 22 06:35:33 svl-orap-chz0-cl1n1 iptables.init[1550]: iptables: Applying firewall rules: [  OK  ]
Jul 22 06:35:33 svl-orap-chz0-cl1n1 systemd[1]: Started IPv4 firewall with iptables.

[opc@svl-orap-chz0-cl1n1 ~]$ sudo iptables-save | grep 3872
-A INPUT -s 192.168.1.142/32 -p tcp -m tcp --dport 3872 -m conntrack --ctstate NEW -j ACCEPT
[opc@svl-orap-chz0-cl1n1 ~]$

[opc@svl-orap-chz0-cl1n1 ~]$ sudo service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

[opc@svl-orap-chz0-cl1n1 ~]$ sudo grep 3872 /etc/sysconfig/iptables
-A INPUT -s 192.168.1.142/32 -p tcp -m tcp --dport 3872 -m conntrack --ctstate NEW -j ACCEPT
[opc@svl-orap-chz0-cl1n1 ~]$

Now if I checked the status of the agent with emctl status agent, I can see that the upload is now updated.

Before the port was added, the upload from the status was:

Last successful upload : (none)
Last attempted upload : (none)

Now it is:

Last successful upload : 2026-07-22 14:17:11
Last attempted upload : 2026-07-22 14:17:11

If I look into OEM, the agent is now fully green:

Add Non-Host Targets Using Guided Process

Now that the agent is installed and host has been added to OEM 24ai, I can add all components. Please see next pictures for the process and what I have been doing.

I then failed credential issue:

I changed DBSNMP user password:

[oracle@svl-orap-chz0-cl1n1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jul 22 14:31:22 2026
Version 19.31.0.0.0

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


Connected to:
Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
Version 19.31.0.0.0

SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT

SQL> select username from dba_users where username='DBSNMP';

USERNAME
--------------------------------------------------------------------------------
DBSNMP

SQL> alter user DBSNMP identified by "XXXXXXXXXXX";

User altered.

SQL>

I tested a connection with tnsping from the OMS server:

[oracle@oms1 ~]$ $ORACLE_HOME/bin/tnsping svl-orap-chz0-cl1n1.db.jewlab.oraclevcn.com:1521/BITS999P__CHZ0.db.jewlab.oraclevcn.com

TNS Ping Utility for Linux: Version 19.0.0.0.0 - Production on 22-JUL-2026 14:41:00

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

Used parameter files:
/u01/app/oracle/database/product/network/admin/sqlnet.ora

Used EZCONNECT adapter to resolve the alias
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=BITS999P__CHZ0.db.jewlab.oraclevcn.com))(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.1.245)(PORT=1521)))
OK (0 msec)
[oracle@oms1 ~]$

And a sqlplus connection as well:

[oracle@oms1 ~]$ $ORACLE_HOME/bin/sqlplus dbsnmp@svl-orap-chz0-cl1n1.db.jewlab.oraclevcn.com:1521/BITS999P__CHZ0.db.jewlab.oraclevcn.com

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jul 22 14:42:00 2026
Version 19.31.0.0.0

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

Enter password:
ERROR:
ORA-28000: The account is locked.


Enter user-name:

Connection is working, account is locked, I then unlocked it.

[oracle@svl-orap-chz0-cl1n1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jul 22 14:42:42 2026
Version 19.31.0.0.0

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


Connected to:
Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
Version 19.31.0.0.0

SQL> show con_name

CON_NAME
------------------------------
CDB$ROOT

SQL> alter user dbsnmp account unlock;

User altered.

SQL>

And could successfully connect with DBSNMP user from the OMS server to my DB System.

[oracle@oms1 ~]$ $ORACLE_HOME/bin/sqlplus dbsnmp@svl-orap-chz0-cl1n1.db.jewlab.oraclevcn.com:1521/BITS999P__CHZ0.db.jewlab.oraclevcn.com

SQL*Plus: Release 19.0.0.0.0 - Production on Wed Jul 22 14:43:23 2026
Version 19.31.0.0.0

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

Enter password:

Connected to:
Oracle Database 19c EE Extreme Perf Release 19.0.0.0.0 - Production
Version 19.31.0.0.0

SQL>

I then went forward with adding the components by first testing the connection through the OEM console:

And I went forward with adding non-host targets, clicking the “Next” button.

And clicking the “Save” button.

I faced a next Plug-in validation issue:

I troubleshooted the error message:

Failed
BITS999P__CHZ0.db.jewlab.oraclevcn.com : EMS-01075: Plug-in validation failed with unexpected error: ORA-20989: Property does not existOracleHome for Agent https://192.168.1.245:3872/emd/main/

Both pingOMS and upload agent was working from the DB System.

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl pingOMS agent
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
EMD pingOMS completed successfully

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl upload agent
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
EMD upload completed successfully

But checking the listplugins agent we can see that only the Oracle Home plugin is deployed. And no database plugin…

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl listplugins agent
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
oracle.sysman.oh    24.1.0.0.0           /opt/oracle/agentem24ai/agent_24.1.0.0.0/plugins/oracle.sysman.oh.agent.plugin_24.1.0.0.0

[oracle@svl-orap-chz0-cl1n1 ~]$

When for the OMS agent we are having much more:

[oracle@oms1 ~]$ /u01/emagent/agent_24.1.0.0.0/bin/emctl listplugins agent
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
oracle.sysman.emas  24.1.1.0.0           /u01/emagent/agent_24.1.0.0.0/plugins/oracle.sysman.emas.agent.plugin_24.1.1.0.0
oracle.sysman.emrep 24.1.0.0.0           /u01/emagent/agent_24.1.0.0.0/plugins/oracle.sysman.emrep.agent.plugin_24.1.0.0.0
oracle.sysman.beacon 24.1.0.0.0           /u01/emagent/agent_24.1.0.0.0/plugins/oracle.sysman.beacon.agent.plugin_24.1.0.0.0
oracle.sysman.oh    24.1.0.0.0           /u01/emagent/agent_24.1.0.0.0/plugins/oracle.sysman.oh.agent.plugin_24.1.0.0.0
oracle.sysman.si    24.1.1.0.0           /u01/emagent/agent_24.1.0.0.0/plugins/oracle.sysman.si.agent.plugin_24.1.1.0.0
oracle.sysman.db    24.1.1.0.0           /u01/emagent/agent_24.1.0.0.0/plugins/oracle.sysman.db.agent.plugin_24.1.1.0.0
oracle.sysman.xa    24.1.1.0.0           /u01/emagent/agent_24.1.0.0.0/plugins/oracle.sysman.xa.agent.plugin_24.1.1.0.0
oracle.apps.ebs     13.5.1.0.0           /u01/emagent/agent_24.1.0.0.0/plugins/oracle.apps.ebs.agent.plugin_13.5.1.0.0
oracle.fmw.gg       13.5.2.0.0           /u01/emagent/agent_24.1.0.0.0/plugins/oracle.fmw.gg.agent.plugin_13.5.2.0.0
oracle.apps.psft    13.5.1.1.0           /u01/emagent/agent_24.1.0.0.0/plugins/oracle.apps.psft.agent.plugin_13.5.1.1.0

[oracle@oms1 ~]$

From the OMS Server, I can see that all is ok with the OMS Agent target itself but not the DB System agent:

[oracle@oms1 ~]$ /u01/app/oracle/em/middleware_241/oms_home/bin/emcli get_targets \
  -targets="oracle_emd"
Status  Status           Target Type           Target Name
 ID
1       Up               oracle_emd            oms1:3872
2       Metric Collecti  oracle_emd            192.168.1.245:3872
        on Error
[oracle@oms1 ~]$

Even after restarting the OMS server I could still see in the log following error related to port 3872:

[oracle@svl-orap-chz0-cl1n1 ~]$ grep -iE "error|exception|fail|metric|collection|192.168.1.245" /opt/oracle/agentem24ai/agent_inst/sysman/log/gcagent.log | tail -10
2026-07-22 18:36:00,248 [38:74B31929] INFO - >>> Reporting exception: oracle.sysman.emSDK.agent.client.exception.NoSuchTargetException: the oracle_emd target "192.168.1.245:3872" does not exist (request id 1) <<[178474536010002])] INFO - >>> Dispatching request: GetConfigPropertyRequest (properties:[_enableMetricBrowser, UploadInterval, REPOSITORY_URL]) <<[178474570230001])] INFO - >>> Dispatching request: PerformOperationRequest (VERIFY_NMO (targetId=oracle_emd.192.168.1.245:3872) -verify authscheme=AGENT_USER jobId=OMS.console@11737@oms1=>[178474570230001]) <<<
2026-07-22 18:41:42,576 [96:92AD4E27] WARN - target oracle_emd.192.168.1.245:3872 does not exist
 error:) (request id 1) <<<
) error() exitCode(0) statusCode(OK)]
[oracle@svl-orap-chz0-cl1n1 ~]$

See the error:

target oracle_emd.192.168.1.245:3872 does not exist

Checking the targets on the DB System agent and port 3872, I could definitively confirm that oracle_emd target 192.168.1.245:3872 is not existing in OMS repository:

[oracle@oms1 ~]$ /u01/app/oracle/em/middleware_241/oms_home/bin/emcli get_targets \
  -targets="oracle_emd:192.168.1.245:3872"
Status  Status           Target Type           Target Name
 ID
[oracle@oms1 ~]$

Which can also be confirmed throught the OEM console:

The agent on the DB System is healthy and communicating with OMS, but it seems that due to the previous 3872 port issue during the agent installation, OMS does not have a valid/configured Agent target that it can use for management operations.

Resynchronisation was also not working:

So I decided to remove the agent manually.

I stopped the agent on the DB System:

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl stop agent
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
Stopping agent ... stopped.

I deleted the agent installation with following command:

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_24.1.0.0.0/perl/bin/perl \
> /opt/oracle/agentem24ai/agent_24.1.0.0.0/sysman/install/AgentDeinstall.pl \
> -agentHome /opt/oracle/agentem24ai/agent_24.1.0.0.0

I manually removed the DB System agent from the OMS repository:

[oracle@oms1 ~]$ /u01/app/oracle/em/middleware_241/oms_home/bin/emcli delete_target \
> -name="192.168.1.245:3872" -type="oracle_emd" -delete_monitored_targets
Target "192.168.1.245:3872:oracle_emd" deleted successfully
[oracle@oms1 ~]$

And I checked that the DB System agent directory is empty:

[oracle@svl-orap-chz0-cl1n1 agentem24ai]$ pwd
/opt/oracle/agentem24ai

[oracle@svl-orap-chz0-cl1n1 agentem24ai]$ ls -ltrh
total 0
[oracle@svl-orap-chz0-cl1n1 agentem24ai]$ cd ..

[oracle@svl-orap-chz0-cl1n1 oracle]$ ls -ld agentem24ai/
drwxr-xr-x 2 oracle oinstall 4096 Jul 22 19:33 agentem24ai/
[oracle@svl-orap-chz0-cl1n1 oracle]$

Deploying the agent again

And I reinstalled the agent as described at the beginning of the blog. The following pictures describe the process again.

Running manually root.sh:

[root@svl-orap-chz0-cl1n1 ~]# /opt/oracle/agentem24ai/agent_24.1.0.0.0/root.sh

Finished product-specific root actions.
/etc exist
[root@svl-orap-chz0-cl1n1 ~]#

Check target DB System agent status

I confirmed that the agent status on the target DB System is up and running as expected, see below:

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl status agent
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
---------------------------------------------------------------
Agent Version          : 24.1.0.0.0
OMS Version            : 24.1.0.0.0
Protocol Version       : 12.1.0.1.0
Agent Home             : /opt/oracle/agentem24ai/agent_inst
Agent Log Directory    : /opt/oracle/agentem24ai/agent_inst/sysman/log
Agent Binaries         : /opt/oracle/agentem24ai/agent_24.1.0.0.0
Core JAR Location      : /opt/oracle/agentem24ai/agent_24.1.0.0.0/jlib
Agent Process ID       : 5649
Parent Process ID      : 5551
Agent URL              : https://192.168.1.245:3872/emd/main/
Local Agent URL in NAT : https://192.168.1.245:3872/emd/main/
Repository URL         : https://oms1:4900/empbs/upload
Started at             : 2026-07-22 20:16:25
Started by user        : oracle
Operating System       : Linux version 5.15.0-319.201.4.6.el8uek.x86_64 (amd64)
Number of Targets      : 4
Last Reload            : (none)
Last successful upload                       : 2026-07-22 20:17:41
Last attempted upload                        : 2026-07-22 20:17:41
Total Megabytes of XML files uploaded so far : 0.33
Number of XML files pending upload           : 0
Size of XML files pending upload(MB)         : 0
Available disk space on upload filesystem    : 79.66%
Collection Status                            : Collections enabled
Heartbeat Status                             : Ok
Last attempted heartbeat to OMS              : 2026-07-22 20:18:28
Last successful heartbeat to OMS             : 2026-07-22 20:18:28
Next scheduled heartbeat to OMS              : 2026-07-22 20:19:28

---------------------------------------------------------------
Agent is Running and Ready

And agent is also all ok in OMS. See two next pictures.

And now we have OMS repository all good for the target DB System host as well:

[oracle@oms1 ~]$ /u01/app/oracle/em/middleware_241/oms_home/bin/emcli get_targets | grep 192.168.1.245
1       Up               host                  192.168.1.245
1       Up               oracle_emd            192.168.1.245:3872
-9      N/A              oracle_home           agent24c1_2_192.168.1.245_8659
[oracle@oms1 ~]$

Also list target on the DB System agent is much better now:

[oracle@svl-orap-chz0-cl1n1 ~]$ /opt/oracle/agentem24ai/agent_inst/bin/emctl config agent listtargets
Oracle Enterprise Manager 24ai Release 1
Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.
[192.168.1.245, host]
[192.168.1.245:3872, oracle_emd]
[agent24c1_2_192.168.1.245_8659, oracle_home]
[oms1:3872_proxy, oracle_emd_proxy]
[oracle@svl-orap-chz0-cl1n1 ~]$

Add Non-Host Targets Using Guided Process again as per previous guidance

I then could successfully add all host components following previous guidance. Before saving database discovery review, all information could be displayed properly, see following pictures.

Check new database target

And I could finally check that new database target is well recorderd in OMS.

To wrap up…

I could successfully deployed an agent on one of my DB System lab. I’m now ready to activate Ask EM functionality in order to test it.

L’article Oracle GenAI – Ask EM – Install and configure an Oracle Management agent on OEM 24ai est apparu en premier sur dbi Blog.

Pros and Cons for a Marketplace installation

For my current purpose of getting a lab in order to test GenAI Ask EM feature, the advantages of doing an installation from the marketplace are the following:

• Faster and less work to get a working environment ready for Ask Em testing
• Less possible errors and problems
• Oracle prope a full preconfigured image with OS and EM
• Minimalize deployement time
• More time to focus on Ask EM testing

The disadvantage would be to have:

• Less flexibility

But I really do not need any customized installation.

The manual installation complexity would mainly be to install and configure manually:

• Oracle VM with OS (Oracle Linux)
• EM repository database
• EM weblogic
• EM software installation and patching
• OMS
• …

Pre-requirements

Please note following:

• I will be installing a simple deployment sizing lab.
• Enterprise Manager Instance Shape, VM.Standard2.4, will then be suffisient.
• I will use existing VCN and subnet
• I will make a single node installation with Enterprise Manager and database installed in a private subnet. This will have the benefit not to expose the Instance on the public network. I will then need a bastion VM which will be part of the installation

Cost estimation

But what would be the cost? The cost will come mainly from the cost of the components:

• Compute instance will be charged based on the shape, OCPU and memory. It is in general the biggest cost
• Block Volume which is charged per provisioned GB
• Networking. VCN, subnets and security lists are free of charge, and are anyhow already existing.
• Single instance repository database does not require any license
• Use EM features only covered by your existing oracle licenses. Pack such as the Diagnostics Pack, Tuning Pack, Lifecycle Management Pack, etc., require the appropriate licenses.

The EM stack from the Marketplace is with BYOL (Bring Your Own License). In any case, I will strongly recommend to check your license and evaluate the cost on your side before doing any installation, moreover if it is for a production installation. My case is just a lab testing case.

Oracle Enterprise Manager 24ai installation

I will first sign in to OCI and go to Marketplace. From there I will search and click on Oracle Enterprise Manager, see below pictures.

Once you have selected the Oracle Enterprise Manager 24ai stack, review the information to ensure it is accurate and click on Launch State.

Following 3 pictures will show the details.

Configure Compartment, accept the terms and conditions and launch the stack, see:

Provide a name and a desciption, and click next, see:

Configure the installation and sizing details:

• Choose simple as deployment size. One node is suffisient for our lab and test
• Click on advanced deployment to reuse existing infracsture (VCN and subnets)

See following picture:

Provide existing VCN Name:

Provide networking details making sure to chose existing private subnet:

Configure Oracle Management providing Server details.

First we will provide an hostname prefix, choose Operating System version and provide Enterprise Manager password:

We will provide agent registration password and weblogic admin and node manager password, before chosing Enterprise Manager Instance shape and boot volume size. As discussed in the pre-requirement, a VM.Standard2.4 is enough for my need.

And finally also provide the public key to be able to access the VM later on with SSH.

I will also have to provide all the details concerning the repository database, that’s to say database sys and dnsnmp user password. I will keep the database in archive log mode.

As I choose to install Enterprise Manager in the private subnet, I will need a bastion. I could decide to use an existing one where the installation will make needed changes or create a new one specific for EM. I decided to create a new one, but using existing subnet, see following information that needs to be provided, before clicking next button:

Review the whole configuration:

Select run apply and click the create button.

And the we can see the job stack execution. The status will first go to Accepted status and then In progress status, see next pictures:

Checks…

Once completed, we can check the job stack status, the created VM compute instance (OMS server, bastion) and EM access.

Job stack

As we can see in the next picture, the job status is now Succeeded.

In Resource Manager, under Stacks menu, we can see our OEM-Lab stack that is active. All components information will be provided.

Compute VM instances

We can check in our compartment the running EM-OMS VM compute instance and EM-OMS-bastion.

EM Web access

Let’s first check and confirm that I can join the OMS Bastion from my MAC.

maw@DBI-LT-MAW2 ~ % ssh -i /Users/maw/Documents/Current-Dokument/Dokument/pem_ssh_key/yak_beta_workshop/srv/sshkey opc@152.67.XX.XXX
The authenticity of host '152.67.XX.XXX (152.67.XX.XXX)' can't be established.
ED25519 key fingerprint is: SHA256:CVPCXt9EwZ153fUVnZf3AGADYNVqT9fJGaU70TKbX+I
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '152.67.XX.XXX' (ED25519) to the list of known hosts.
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
Last login: Mon Jul 13 08:25:33 2026 from 140.238.169.22
[opc@em-oms-bastion ~]$

AS I choose an installation on private network, I do not have access to EM through a web browser from my MAC. I first need to configure a ssh tunnel.

maw@DBI-LT-MAW2 ~ % ssh -i /Users/maw/Documents/Current-Dokument/Dokument/pem_ssh_key/yak_beta_workshop/srv/sshkey -L 7799:192.168.1.142:7799 opc@152.67.XX.XXX
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
Last login: Mon Jul 13 11:02:53 2026 from 146.4.101.46
[opc@em-oms-bastion ~]$

Check from OMS bastion that EM console is reachable.

[opc@em-oms-bastion ~]$ curl -k https://192.168.1.142:7799/em


This document you requested has moved
temporarily.
It's now at https://192.168.1.142:7799/em/login.jsp.

[opc@em-oms-bastion ~]$

Check that the connection is possible on EM from my MAC directly after I have created the SSH tunnel:

maw@DBI-LT-MAW2 ~ % curl -k https://localhost:7799/em


This document you requested has moved
temporarily.
It's now at https://localhost:7799/em/login.jsp.

maw@DBI-LT-MAW2 ~ %

All is good, I can not test from my MAC using a web browser.

Let’s go in the summary page.

To wrap up…

The easiest way for me to have got a EM lab installation to look into GenAI Ask EM was to install it from the marketplace. Now I’m ready to install some agent on some database host and test Ask EM functionality. I will be sharing this in a next blog.

L’article Oracle GenAI – Ask EM – Deploy Oracle Enterprise Manager 24ai from Marketplace est apparu en premier sur dbi Blog.

Environment and problem description

At our customer environment, client connection run from the HelperVM does not establish database connections directly to the database listener. The connection goes through the Network Load Balancer, so called NLB, and the Oracle Connection Manager, so called CMAN.

The diagram below describes the database connection establishment process.

This is how it works.

• 1 – Client seeks for connection details (ideally, get the connection details from Oracle Directory Service)
• 2 – Client connects to Network Load Balancer
• 3 – Network Load Balancer “forwards” the request to Oracle Connection MANager using Virtual IP
• 4 – Oracle Connection MANager acts as a rule-based firewall and ensure the database target service is running on the “white listed targets (next_hop)
• 5 – Oracle Database establish connectivity upon credential validate (Oracle listener acts in between). The listener hands the connection over to the Oracle CMAN gateway process, which passes data back and forth between the client and the db-server and collects statistics.

We could observed per reverse engineering  technique that the TCP connection established between the Oracle client and Oracle CMAN works upon Network Load Balancer Virtual IP.

The Network Load Balancer needs for Session persistence “statefullnes” to be enabled. This means that once the connection is established, the NLB “remembers” established connections and fails them over in case of planned downtime.

We have been facing some broken connectivity issue. Checking Linux socket connection with linux ss command (# ss -nop) we could see TCP connection hungs between client and NLB virtual IP (CNAME DNS entry). On CMAN and DB-Server side the connection were already cleaned up as per Dead Connection Detection configuration. We can see in the diagram that EXPIRE_TIME is setup with a value of 10 minutes on the CMAN side and the listener configuration from the VM Cluster database.

The connection was still opened on the client side because:

• The client was still waiting on a result which would never come
• TCP connection to the NLB Virtual IP was still existing albeit closed with the CMAN and database listener
• TCP connection to the NLB would remain alive for days

The problem is that by default Oracle client does not enable TCP Keepalive, which is an expected behavior. Oracle expects the keepalive to be set on the server side. The “Dead Connection Detection” will then be enforced for all clients.

TCP Keepalive should then be managed in our case on the client side. And we are currently running Oracle 19c Client.

EXPIRE_TIME handled on Oracle 19c Client

Oracle 19c client does not come with SQLNET.EXPIRE_TIME aka “Oracle dead connection detection”, unless hacked over connection string hidden (unsupported) parameter ENABLE_BROKEN. 

See following blog from a one of my former colleagues:

sqlnet-expire_time and enablebroken

And what about Oracle 26ai Client? Let’s do some test…

Installation of Oracle 26ai Client

On the lab, I will use the VM called bastion to act as the client. The bastion has already an Oracle 19c Client installed. I’m going to installed new Oracle 26ai Client on it.

First we need to download the client version, which can be done from the following website:

https://www.oracle.com/database/technologies/oracle26ai-linux-downloads.html

I will install Oracle 26ai Client version in /opt/oracle.

[root@bastion oracle]# pwd
/opt/oracle

[root@bastion oracle]# ls -ld client*
drwxr-xr-x. 52 oracle oinstall 4096 Jun  6  2024 client19c
drwxr-xr-x. 47 oracle oinstall 4096 Nov 11  2025 client_21c
[root@bastion oracle]#

I will first unzip the downloaded oracle zip file.

[oracle@bastion oracle]$ pwd
/opt/oracle

[oracle@bastion oracle]$ unzip -q LINUX.X64_2326100_client.zip

I will then rename the client installation directory:

[oracle@bastion oracle]$ ls -ld client*
drwxr-xr-x.  5 oracle oinstall   90 Jan 17 13:59 client
drwxr-xr-x. 52 oracle oinstall 4096 Jun  6  2024 client19c
drwxr-xr-x. 47 oracle oinstall 4096 Nov 11  2025 client_21c

[oracle@bastion oracle]$ mv client client26ai
[oracle@bastion oracle]$

[oracle@bastion oracle]$ ls -ld client*
drwxr-xr-x. 52 oracle oinstall 4096 Jun  6  2024 client19c
drwxr-xr-x. 47 oracle oinstall 4096 Nov 11  2025 client_21c
drwxr-xr-x.  5 oracle oinstall   90 Jan 17 13:59 client26ai
[oracle@bastion oracle]$

I will prepare the response file for the command line installation.

[oracle@bastion client26ai]$ cp -p response/client_install.rsp response/client_install_custom.rsp

[oracle@bastion client26ai]$ vi response/client_install_custom.rsp

[oracle@bastion client26ai]$ diff response/client_install.rsp response/client_install_custom.rsp
22c22
 UNIX_GROUP_NAME=oinstall
26c26
 INVENTORY_LOCATION=/opt/oracle/oraInventory
30c30
 ORACLE_HOME=/opt/oracle/client26ai
34c34
 ORACLE_BASE=/opt/oracle
48c48
 oracle.install.client.installType=Administrator
[oracle@bastion client26ai]$

And I will run the Oracle 26ai Client installation.

[oracle@bastion client26ai]$ pwd
/opt/oracle/client26ai

[oracle@bastion client26ai]$ ls -ltrh
total 24K
-rwxrwx---.  1 oracle oinstall  500 Feb  6  2013 welcome.html
-rwxr-xr-x.  1 oracle oinstall 8.7K Jan 17 12:38 runInstaller
drwxr-xr-x.  4 oracle oinstall 4.0K Jan 17 12:38 install
drwxr-xr-x. 15 oracle oinstall 4.0K Jan 17 13:37 stage
drwxr-xr-x.  2 oracle oinstall   82 May 21 16:13 response

[oracle@bastion client26ai]$ ./runInstaller -silent -responseFile /opt/oracle/client26ai/response/client_install_custom.rsp
Starting Oracle Universal Installer...

Checking Temp space: must be greater than 415 MB.   Actual 5025 MB    Passed
Checking swap space: must be greater than 150 MB.   Actual 4095 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2026-05-21_04-16-17PM. Please wait ... [WARNING] [INS-32016] The selected Oracle home contains directories or files.
   ACTION: To start with an empty Oracle home, either remove its contents or specify a different location.
*********************************************
Package: compat-openssl10-1.0.2 (x86_64): This is a prerequisite condition to test whether the package "compat-openssl10-1.0.2 (x86_64)" is available on the system.
Severity: IGNORABLE
Overall status: VERIFICATION_FAILED
Error message: PRVF-7532 : Package "compat-openssl10(x86_64)-1.0.2" is missing on node "bastion"
Cause:  A required package is either not installed or, if the package is a kernel module, is not loaded on the specified node.
Action:  Ensure that the required package is installed and available.
-----------------------------------------------
[WARNING] [INS-13014] Target environment does not meet some optional requirements.
   CAUSE: Some of the optional prerequisites are not met. See logs for details. /opt/oraInventory/logs/installActions2026-05-21_04-16-17PM.log.
   ACTION: Identify the list of failed prerequisite checks from the log: /opt/oraInventory/logs/installActions2026-05-21_04-16-17PM.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:
 /opt/oracle/client26ai/install/response/client_2026-05-21_04-16-17PM.rsp

You can find the log of this install session at:
 /opt/oraInventory/logs/installActions2026-05-21_04-16-17PM.log

The installation of Oracle Client 26ai was successful.
Please check '/opt/oraInventory/logs/silentInstall2026-05-21_04-16-17PM.log' for more details.
Successfully Setup Software with warning(s).
[INS-10115] All configuration tools were previously ran successfully, no further configuration is required.

[oracle@bastion client26ai]$

And the Oracle 26ai Client is now installed.

Prepare target database

I will create a user on the target lab PDB, named TESTZ_TMR_003I, in order to establish sqlplus connection and test the EXPIRE_TIME configuration.

I will create a user test01 and grant the connect permissions.

[oracle@svl-oat ~]$ echo $ORACLE_SID
CDB001I

[oracle@svl-oat ~]$ sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Thu May 21 14:30:39 2026
Version 19.23.0.0.0

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


Connected to:
Oracle Database 19c EE High Perf Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL> show pdbs

    CON_ID CON_NAME           OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
     2 PDB$SEED           READ ONLY  NO
     3 TESTZ_APP_006I         READ WRITE NO
     4 RCLON_TMR_003I         MOUNTED
     5 RCLON_TMR_002I         MOUNTED
     6 RCLON_TMR_001I         MOUNTED
     7 CLONZ_TMR_002I         MOUNTED
     8 TESTZ_TMR_003I         READ WRITE NO
    10 TESTZ_APP_004I         READ WRITE NO
    11 CLONZ_APP_001I         READ WRITE NO
    12 RCLON_APP_003I         READ WRITE NO

SQL> alter session set container=TESTZ_TMR_003I;

Session altered.

SQL> create user test01 identified by "test_expire";

User created.

SQL> grant connect to test01;

Grant succeeded.

SQL>

Test connection with Oracle 26ai Client

I will first set the ORACLE_HOME variable on the appropriate client directory.

[oracle@bastion client26ai]$ echo $ORACLE_HOME
/opt/oracle/client19c

[oracle@bastion client26ai]$ export ORACLE_HOME=/opt/oracle/client26ai

[oracle@bastion client26ai]$ echo $ORACLE_HOME
/opt/oracle/client26ai
[oracle@bastion client26ai]$

I will update the PATH variable to get tnsping and sqlplus binary from the appropriate Oracle 26ai Client.

[oracle@bastion client26ai]$ echo $PATH
/usr/share/Modules/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/oracle/client19c/bin:/opt/oracle/sqlcl-24.1.0.087.0929//bin

[oracle@bastion client26ai]$ export PATH=/opt/oracle/client26ai/bin

[oracle@bastion client26ai]$ echo $PATH
/opt/oracle/client26ai/bin
[oracle@bastion client26ai]$

I will check that the appropriate tnsping and sqlplus is taken.

[oracle@bastion client26ai]$ which sqlplus
/opt/oracle/client26ai/bin/sqlplus

[oracle@bastion client26ai]$ which tnsping
/opt/oracle/client26ai/bin/tnsping

I checked that the connection to target PDB is working.

[oracle@bastion ~]$ tnsping svl-oat:1521/testz_tmr_003i.db.jewlab.oraclevcn.com

TNS Ping Utility for Linux: Version 23.26.1.0.0 - Production on 21-MAY-2026 16:28:56

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

Used parameter files:
/opt/oracle/client19c/network/admin/sqlnet.ora

Used EZCONNECT adapter to resolve the alias
Attempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=testz_tmr_003i.db.jewlab.oraclevcn.com))(ADDRESS=(PROTOCOL=tcp)(HOST=X.X.1.135)(PORT=1521)))
OK (0 msec)
[oracle@bastion ~]$

The TNS_ADMIN used is from the 19c Oracle client directory, which is absolutely not a problem.

[oracle@bastion ~]$ echo $TNS_ADMIN
/opt/oracle/client19c/network/admin
[oracle@bastion ~]$

Test sqlplus connection with Oracle 26ai Client

As I can see on my client side, I do not have any sqlplus connection running right now.

[opc@bastion ~]$ ss -nop | grep 1521
[opc@bastion ~]$

I will generate a sqlplus connection.

[oracle@bastion client26ai]$ sqlplus test01/test_expire@svl-oat:1521/testz_tmr_003i.db.jewlab.oraclevcn.com

SQL*Plus: Release 23.26.1.0.0 - Production on Thu May 21 16:34:23 2026
Version 23.26.1.0.0

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


Connected to:
Oracle Database 19c EE High Perf Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL>

And I can see that I have got a sqlplus connection with no timer/keepalive.

[opc@bastion ~]$ ss -nop | grep 1521
tcp   ESTAB  0      0   X.X.0.89:51404    X.X.1.135:1521
[opc@bastion ~]$

I will now configure Oracle Dead Connection Detection with SQLNET.EXPIRE_TIME parameter set in the client sqlnet.ora with a value of 1 minute.

[oracle@bastion ~]$ cd $TNS_ADMIN

[oracle@bastion admin]$ /usr/bin/grep -i expire sqlnet.ora
[oracle@bastion admin]$ 

[oracle@bastion admin]$ /usr/bin/vi sqlnet.ora

[oracle@bastion admin]$ /usr/bin/grep -i expire sqlnet.ora
SQLNET.EXPIRE_TIME=1
[oracle@bastion admin]$

I will run a new sqlplus connection.

[oracle@bastion admin]$ sqlplus test01/test_expire@svl-oat:1521/testz_tmr_003i.db.jewlab.oraclevcn.com

SQL*Plus: Release 23.26.1.0.0 - Production on Thu May 21 16:41:06 2026
Version 23.26.1.0.0

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

Last Successful login time: Thu May 21 2026 16:34:23 +02:00

Connected to:
Oracle Database 19c EE High Perf Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL>

I can now see that I have got a connection configured with a timer and keep alive remaining of 38s.

[opc@bastion ~]$ ss -nop | grep 1521
tcp   ESTAB  0      0     X.X.0.89:62868    X.X.1.135:1521   timer:(keepalive,38sec,0)
[opc@bastion ~]$

Let’s configure the EXPIRE_TIME with a value of 15 minutes.

[oracle@bastion admin]$ /usr/bin/vi sqlnet.ora

[oracle@bastion admin]$ /usr/bin/grep -i expire sqlnet.ora
SQLNET.EXPIRE_TIME=15

I run a new sqlplus connection.

[oracle@bastion admin]$ sqlplus test01/test_expire@svl-oat:1521/testz_tmr_003i.db.jewlab.oraclevcn.com

SQL*Plus: Release 23.26.1.0.0 - Production on Thu May 21 16:43:25 2026
Version 23.26.1.0.0

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

Last Successful login time: Thu May 21 2026 16:42:29 +02:00

Connected to:
Oracle Database 19c EE High Perf Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL>

And I now have got a connection configured with a timer and keep alive remaining of 14min.

[opc@bastion ~]$ ss -nop | grep 1521
tcp   ESTAB  0      0     X.X.0.89:60630    X.X.1.135:1521   timer:(keepalive,14min,0)
[opc@bastion ~]$

So, all good Oracle 26ai Client is supporting Dead Connection Detection with SQLNET.EXPIRE_TIME parameter.

Let’s test it with Oracle 19c Client

We can easily confirm again that Oracle 19c Client does not support Dead Connection Detection on the client side.

Let’s move back to Oracle 19c Client home.

[oracle@bastion admin]$ export PATH=/opt/oracle/client19c/bin

[oracle@bastion admin]$ which sqlplus
/opt/oracle/client19c/bin/sqlplus

Run a sqlplus connection.

[oracle@bastion admin]$ sqlplus test01/test_expire@svl-oat:1521/testz_tmr_003i.db.jewlab.oraclevcn.com

SQL*Plus: Release 19.0.0.0.0 - Production on Thu May 21 16:48:09 2026
Version 19.3.0.0.0

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

Last Successful login time: Thu May 21 2026 16:46:07 +02:00

Connected to:
Oracle Database 19c EE High Perf Release 19.0.0.0.0 - Production
Version 19.23.0.0.0

SQL>

And check connection configuration.

[opc@bastion ~]$ ss -nop | grep 1521
tcp   ESTAB      0      0    X.X.0.89:64078    X.X.1.135:1521
[opc@bastion ~]$

There is no timer/keepalive handled with Oracle 19c Client.

To wrap up…

Oracle Database 26ai Client is now supporting Dead Connection Detection on the client side. For our customer configuration this will help the client to check every X minutes (EXPIRE_TIME configured value) for Dead Connection. So if the CMAN and listener connections have already died and if for any reason the Network Load Balancer is still keeping the connection with the client, the client will close the connection after X minutes.

L’article Oracle Database 26ai Client and SQLNET.EXPIRE_TIME est apparu en premier sur dbi Blog.

Data Preserving Reprovisioning will allow you reprovisioning an already deployed Oracle Database Appliance system keeping the storage and the databases on the appliance, so without any modifications on the information stored in the ASM (storage). The information of the source system will be saved in a server data archive files. The appliance will then be reimaged with Oracle Database Appliance release iso image and the saved metadata will be used to directly reprovision the system and bring back all the resources such as databases, DB systems, Oracle ASR, and others.

The reimage can only be done using the java remote console, available with the ILOM. Remember that to attach the iso on the java console and use it during the reimage, you need to add it and connect it as described in the next picture.

It is important to see the following red message to ensure that the connection with the iso is made and that it can be used.

The problem is that after a time, during the reimage process, the java remote console lost full control on the node, having as consequence a lost of the iso connection and a failure in the reimage process.

This could be seen in the console with the message (View Only) displayed in the bar and the Red Cross on the top of the Computer (screen)/mouse image.

Here:

When it should be:

Here the whole picture showing the connection problem.

And we can see the message : “Sorry, keyboard and mouse connection has been lost. \nIf storage was being shared it has been lost also”.

When a correct connection would be the following one, having (Full Control) message displayed in the bar, with no lost of keyboard/mouse and storage (iso) connection.

After several tries it was always the same problem. After a few minutes, lost of the connection…

I then decided to check the ILOM sessions, connecting to the ILOM through ssh connection.

login as: root
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server

Oracle(R) Integrated Lights Out Manager

Version 5.1.1.23 r151958

Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Warning: HTTPS certificate is set to factory default.

Hostname: ODA01-ilo

-> show /SP/sessions

 /SP/sessions
    Targets:
        55342
        55346 (current)

    Properties:

    Commands:
        cd
        delete
        show

I found surprising to see so high sessions id. I decided to reset the ILOM. This would of course not restart the node.

-> reset /SP
Are you sure you want to reset /SP (y/n)? y
Performing reset on /SP

And connected again to the ILOM through ssh to checked the sessions:

login as: root
Keyboard-interactive authentication prompts from server:
| Password:
End of keyboard-interactive prompts from server

Oracle(R) Integrated Lights Out Manager

Version 5.1.1.23 r151958

Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Warning: HTTPS certificate is set to factory default.

Hostname: ODA01-ilo

-> show /SP/sessions

 /SP/sessions
    Targets:
        1 (current)

    Properties:

    Commands:
        cd
        delete
        show

The sessions id were back to one, and I did not have any lost connection issue any more. I could successfully reimage the ODA to 19.24 version.

L’article Loosing java remote console full control during ODA Reimage est apparu en premier sur dbi Blog.

Problem description

On an Oracle Database Appliance, the DCS agent is the software providing the full automation to manage the appliance. It will have no impact on the well working of the databases but is mandatory to manage the appliance (patching, create dbhome, create database and any appliance resources). The DCS agent will perform various operations on the appliance, such as provisioning, database lifecycle management, backup and recovery, and storage management. The DCS Agent will use a MySQL database to store the metadata. In order for the DCS Agent to work, the MySQL database needs to be up and running.

On the node 0 of an ODA X9-2-HA, where I was preparing the next database patching operation, I wanted to run some cleanup.

[root@ODA-HA_node0 ~]# odacli cleanup-patchrepo -comp DB,GI -v 19.20.0.0.0
DCS-10009:Failed to create new service job report.

For which I could get a DCS failure.

I checked the job and realised that an ODA cleaning job where still in running status for about 3 months…

[root@ODA-HA_node0 ~]# odacli list-jobs

ID                                       Description                                                                 Created                             Status
---------------------------------------- --------------------------------------------------------------------------- ----------------------------------- ----------------
80f2bfbc-a02e-47bb-b57c-754d3d6d3d3a     Server Patching                                                             2025-11-12 08:00:14 CET             Success
2e36d676-f175-402d-a7e4-735b4eb965de     Patch pre-checks for [STORAGE]                                              2025-11-12 08:58:19 CET             Success
...
c4611880-fdc8-44fd-90a5-c2dd27d12f7c     Auto purge job data                                                         2025-12-09 03:59:48 CET             Success
ed09f270-5eff-4141-9b7b-51a2e5d30e32     Auto purge job data                                                         2025-12-10 03:59:50 CET             Success
aecd8ca5-44fb-4e2c-af2b-0e42e954381a     Auto purge job data                                                         2025-12-11 03:59:52 CET             Running

[root@ODA-HA_node0 ~]#

Troubleshooting

I restarted the DCS agent.

[root@ODA-HA_node0 ~]# systemctl stop initdcsagent

[root@ODA-HA_node0 ~]# systemctl start initdcsagent

[root@ODA-HA_node0 ~]# systemctl status initdcsagent
● initdcsagent.service - Oracle dcs-agent startup
   Loaded: loaded (/etc/systemd/system/initdcsagent.service; enabled; vendor preset: disabled)
   Active: active (running) since Wed 2026-03-18 14:35:41 CET; 2s ago
 Main PID: 92038 (sh)
    Tasks: 96 (limit: 79998)
   Memory: 331.7M
   CGroup: /system.slice/initdcsagent.service
           ├─92038 /bin/sh -c . /opt/oracle/dcs/bin/setupJreAgent.sh;LD_LIBRARY_PATH=/opt/oracle/rhp/lib:$JRE_HOME/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib $JAVA -Xms128m -Xmx256m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:+DisableExplicitGC -XX:ParallelGCThreads=4 -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:/opt/oracle/dcs/log/gc-dcs-agent-%t-%p.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFi>
           └─92039 /opt/oracle/dcs/java/1.8.0_441/bin/java -Xms128m -Xmx256m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:+DisableExplicitGC -XX:ParallelGCThreads=4 -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:/opt/oracle/dcs/log/gc-dcs-agent-%t-%p.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=10M -Doracle.security.jps.config=/opt/oracle/dcs/agent/jps-config.xml -Dio.nett>

Mar 18 14:35:41 ODA-HA_node0 systemd[1]: Started Oracle dcs-agent startup.
[root@ODA-HA_node0 ~]# odacli list-jobs | tail -n3

Which did not help. In the DCS Agent log I could find some errors with HAMI. Oracle HAMI is the Oracle High Availability Metadata Infrastructure service providing distributed services required by DCS including locking and synchronizing configuration details in the cluster.

[root@ODA-HA_node0 log]# view dcs-agent-infra.log
...
...
...
2026-03-18 14:59:37,776 DEBUG [DcsInfraProvisioningThread] [] c.o.d.i.h.c.CommandExecutor: Going to execute command '/opt/oracle/dcs/hami/bin/hamictl.sh ssh-equiv --ensemble ODA_DCS --hosts ODA-HA_node0-priv,ODA-HA_node1-priv --json'
2026-03-18 14:59:38,014 DEBUG [DcsInfraProvisioningThread] [] c.o.d.i.h.c.CommandExecutor: Got result from execution of '/opt/oracle/dcs/hami/bin/hamictl.sh ssh-equiv --ensemble ODA_DCS --hosts ODA-HA_node0-priv,ODA-HA_node1-priv --json':
 - RC:     1
 - OUTPUT: /opt/oracle/dcs/oda-python3/lib/python3.12/getpass.py:91: GetPassWarning: Can not control echo on the terminal.
Warning: Password input may be echoed.
hamictl_oda_dcs's password: *********
{"operation": "ssh-equiv", "result": "FAILED", "message": "Invalid password"}

2026-03-18 14:59:38,015 ERROR [DcsInfraProvisioningThread] [] c.o.d.a.i.DcsInfraProvisioningThread: Could not provision DCS infrastructure
com.oracle.dcs.infra.hams.ctl.HamiCtl$HamiCtlException: Invalid password

I decided to restart MySQL service.

[root@ODA-HA_node0 ~]# systemctl stop oda-mysql

[root@ODA-HA_node0 ~]# systemctl start oda-mysql
Job for oda-mysql.service failed because the control process exited with error code.
See "systemctl status oda-mysql.service" and "journalctl -xe" for details.

Which failed…

Checking the logs:

[root@ODA-HA_node0 ~]# journalctl -xe
...
-- Unit oda-mysql.service has begun starting up.
Mar 31 09:23:10 ODA-HA_node0 systemd[90052]: oda-mysql.service: Failed to execute command: Permission denied
Mar 31 09:23:10 ODA-HA_node0 systemd[90052]: oda-mysql.service: Failed at step EXEC spawning /opt/oracle/dcs/mysql/bin/mysqld: Permission denied

I could see that it was complaining about permissions.

I checked the permissions on the MySQL binary:

[root@ODA-HA_node0 ~]# ls -ltrh /opt/oracle/dcs/mysql/bin/mysqld
-rwxr-x--- 1 odamysql odamysql 338M Mar 26 16:55 /opt/oracle/dcs/mysql/bin/mysqld
[root@ODA-HA_node0 ~]#

And that one was ok. The linux user starting MySQL, odamysql, was having the right permissions.

I then checked all permissions including the directories:

[root@ODA-HA_node0 log]# ls -ld /opt /opt/oracle /opt/oracle/dcs /opt/oracle/dcs/mysql /opt/oracle/dcs/mysql/bin
drwxrwx---  11 root     oinstall 4096 Nov 21 13:58 /opt
drwxr-xr-x.  9 root     root     4096 Nov 14 16:31 /opt/oracle
drwxr-xr-x. 30 root     root     4096 Nov 14 12:40 /opt/oracle/dcs
drwxr-xr-x. 13 root     root     4096 Nov 14 09:10 /opt/oracle/dcs/mysql
drwxr-x---.  2 odamysql odamysql 4096 Mar 26 16:55 /opt/oracle/dcs/mysql/bin
[root@ODA-HA_node0 log]#

And I could see that there were wrong on the /opt directory… The odamysql directory is not able to enter and read in the /opt directory, as it does not belong to the group and there is no permissions on the other users…

I checked on a valid ODA and as expected the permissions should be:

drwxr-xr-x. 11 root     root     4096 Mar 18 10:02 /opt

So this is mainly due to an human mistake…

Resolution

I first checked and could confirm the issue only affect the /opt directory itself.

[root@ODA-HA_node0 opt]# pwd
/opt

[root@ODA-HA_node0 opt]# ls -ltrh
total 48K
drwxr-xr-x.  3 root root     4.0K Sep 17  2024 lsi
drwxr-xr-x   2 root root     4.0K Jan 15  2025 oracle.ahf
drwx------.  2 root root      16K Nov 11 15:42 lost+found
drwxr-xr-x.  4 root root     4.0K Nov 11 16:32 MegaRAID
drwxr-xr-x   3 root root     4.0K Nov 12 10:20 ORCLfmap
drwxr-xr-x   5 root root     4.0K Nov 12 13:36 odabr
drwxr-xr-x.  9 root root     4.0K Nov 14 16:31 oracle
drwxrwx---  16 root oinstall 4.0K Feb 16 11:19 commvault
drwx------  11 root root     4.0K Mar 30 02:08 splunkforwarder
[root@ODA-HA_node0 opt]#

I change the permissions for other users.

[root@ODA-HA_node0 /]# chmod o+rx /opt

[root@ODA-HA_node0 /]# ls -ld /opt /opt/oracle /opt/oracle/dcs /opt/oracle/dcs/mysql /opt/oracle/dcs/mysql/bin
drwxrwxr-x  11 root     oinstall 4096 Nov 21 13:58 /opt
drwxr-xr-x.  9 root     root     4096 Nov 14 16:31 /opt/oracle
drwxr-xr-x. 30 root     root     4096 Nov 14 12:40 /opt/oracle/dcs
drwxr-xr-x. 13 root     root     4096 Nov 14 09:10 /opt/oracle/dcs/mysql
drwxr-x---.  2 odamysql odamysql 4096 Mar 26 16:55 /opt/oracle/dcs/mysql/bin
[root@ODA-HA_node0 /]#

And I could successfully start the MySQL service.

[root@ODA-HA_node0 /]# systemctl start oda-mysql

[root@ODA-HA_node0 /]# systemctl status oda-mysql
● oda-mysql.service - MySQL Server for ODA
   Loaded: loaded (/etc/systemd/system/oda-mysql.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2026-03-31 09:55:48 CEST; 6s ago
     Docs: man:mysqld(8)
           http://dev.mysql.com/doc/refman/en/using-systemd.html
 Main PID: 55837 (mysqld)
   Status: "Server is operational"
    Tasks: 33 (limit: 79998)
   Memory: 423.5M
   CGroup: /system.slice/oda-mysql.service
           └─55837 /opt/oracle/dcs/mysql/bin/mysqld --defaults-file=/opt/oracle/dcs/mysql/etc/mysqldb.cnf --skip-mysqlx

Mar 31 09:55:48 ODA-HA_node0 systemd[1]: Starting MySQL Server for ODA...
Mar 31 09:55:48 ODA-HA_node0 systemd[1]: Started MySQL Server for ODA.
[root@ODA-HA_node0 /]#

And I could successfully start the DCS Agent.

[root@ODA-HA_node0 /]# systemctl status initdcsagent
● initdcsagent.service - Oracle dcs-agent startup
   Loaded: loaded (/etc/systemd/system/initdcsagent.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Wed 2026-03-18 15:22:48 CET; 1 weeks 5 days ago
 Main PID: 84546 (code=killed, signal=TERM)

Mar 19 16:18:04 ODA-HA_node0 systemd[1]: Dependency failed for Oracle dcs-agent startup.
Mar 19 16:18:04 ODA-HA_node0 systemd[1]: initdcsagent.service: Job initdcsagent.service/start failed with result 'dependency'.
Mar 24 13:38:38 ODA-HA_node0 systemd[1]: Dependency failed for Oracle dcs-agent startup.
Mar 24 13:38:38 ODA-HA_node0 systemd[1]: initdcsagent.service: Job initdcsagent.service/start failed with result 'dependency'.
Mar 25 09:46:35 ODA-HA_node0 systemd[1]: Dependency failed for Oracle dcs-agent startup.
Mar 25 09:46:35 ODA-HA_node0 systemd[1]: initdcsagent.service: Job initdcsagent.service/start failed with result 'dependency'.
Mar 26 11:06:50 ODA-HA_node0 systemd[1]: Dependency failed for Oracle dcs-agent startup.
Mar 26 11:06:50 ODA-HA_node0 systemd[1]: initdcsagent.service: Job initdcsagent.service/start failed with result 'dependency'.
Mar 30 16:07:15 ODA-HA_node0 systemd[1]: Dependency failed for Oracle dcs-agent startup.
Mar 30 16:07:15 ODA-HA_node0 systemd[1]: initdcsagent.service: Job initdcsagent.service/start failed with result 'dependency'.

[root@ODA-HA_node0 /]# systemctl start initdcsagent

[root@ODA-HA_node0 /]# systemctl status initdcsagent
● initdcsagent.service - Oracle dcs-agent startup
   Loaded: loaded (/etc/systemd/system/initdcsagent.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2026-03-31 09:57:34 CEST; 1s ago
 Main PID: 59253 (sh)
    Tasks: 96 (limit: 79998)
   Memory: 270.0M
   CGroup: /system.slice/initdcsagent.service
           ├─59253 /bin/sh -c . /opt/oracle/dcs/bin/setupJreAgent.sh;LD_LIBRARY_PATH=/opt/oracle/rhp/lib:$JRE_HOME/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib $JAVA -Xms128m -Xmx256m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:+DisableExplicitGC -XX:ParallelGCThreads=4 -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:/opt/oracle/dcs/log/gc-dcs-agent-%t-%p.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFi>
           └─59254 /opt/oracle/dcs/java/1.8.0_441/bin/java -Xms128m -Xmx256m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m -XX:+DisableExplicitGC -XX:ParallelGCThreads=4 -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCTimeStamps -XX:+PrintGCDateStamps -Xloggc:/opt/oracle/dcs/log/gc-dcs-agent-%t-%p.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=10M -Doracle.security.jps.config=/opt/oracle/dcs/agent/jps-config.xml -Dio.nett>

Mar 31 09:57:34 ODA-HA_node0 systemd[1]: Started Oracle dcs-agent startup.
[root@ODA-HA_node0 /]#

And I could successfully run the cleanup:

[root@ODA-HA_node0 ~]# odacli cleanup-patchrepo -comp DB,GI -v 19.20.0.0.0
{
  "jobId" : "08b395be-ae5a-4d6f-8e5d-1c0fa232f672",
  "status" : "Created",
  "message" : "",
  "reports" : [ ],
  "createTimestamp" : "March 31, 2026 11:21:58 CEST",
  "resourceList" : [ ],
  "description" : "Cleanup patchrepos",
  "updatedTime" : "March 31, 2026 11:21:58 CEST",
  "jobType" : null,
  "cpsMetadata" : null
}

[root@ODA-HA_node0 ~]# odacli describe-job -i 08b395be-ae5a-4d6f-8e5d-1c0fa232f672

Job details
----------------------------------------------------------------
                     ID:  08b395be-ae5a-4d6f-8e5d-1c0fa232f672
            Description:  Cleanup patchrepos
                 Status:  Success
                Created:  March 31, 2026 11:21:58 CEST
                Message:

Task Name                                Node Name                 Start Time                               End Time                                 Status
---------------------------------------- ------------------------- ---------------------------------------- ---------------------------------------- ----------------
Cleanup Repository                       ODA-HA_node1                 March 31, 2026 11:21:58 CEST             March 31, 2026 11:21:59 CEST             Success
Cleanup old ASR rpm                      ODA-HA_node0                 March 31, 2026 11:21:59 CEST             March 31, 2026 11:21:59 CEST             Success

[root@ODA-HA_node0 ~]#

Finally, I have also changed the group for /opt accordingly to root group.

[root@ODA-HA_node0 /]# chgrp root /opt

[root@ODA-HA_node0 /]# ls -ld /opt /opt/oracle /opt/oracle/dcs /opt/oracle/dcs/mysql /opt/oracle/dcs/mysql/bin
drwxrwxr-x  11 root     root     4096 Nov 21 13:58 /opt
drwxr-xr-x.  9 root     root     4096 Nov 14 16:31 /opt/oracle
drwxr-xr-x. 30 root     root     4096 Nov 14 12:40 /opt/oracle/dcs
drwxr-xr-x. 13 root     root     4096 Nov 14 09:10 /opt/oracle/dcs/mysql
drwxr-x---.  2 odamysql odamysql 4096 Mar 26 16:55 /opt/oracle/dcs/mysql/bin
[root@ODA-HA_node0 /]#

To wrap up…

DCS Agent and MySQL database will have no effect on the well working of your databases, but if they are not working you are not able to manage your appliance any more. Here, wrong permissions (for sure a human mistake) had sad effects on appliance software. Solving the permissions issue resolved my problem.

L’article MySQL Metadata Store service not able to start on an ODA est apparu en premier sur dbi Blog.