Archives des Oracle - dbi Blog

Removing rpm with dnf implies removing systemd

Marc Wagner — Fri, 31 Jul 2026 20:40:04 +0000

On an Oracle Linux 8, I installed a new package and did not pay attention that dnf used an old Oracle Linux 7 repository. Trying to remove it again, I was getting following error:

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.

Oracle Linux – Unfinished DB8actions remaining

Marc Wagner — Fri, 31 Jul 2026 19:21:46 +0000

I have been recently facing following error when using yum/dnf:

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.

Oracle database linux service not working properly after Oracle Linux upgrade

Marc Wagner — Fri, 31 Jul 2026 17:11:47 +0000

After performing an in-place Oracle linux upgrade I could realize that the oracle service was unusable.

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.

Upgrading Oracle Linux when running Oracle databases

Marc Wagner — Fri, 31 Jul 2026 16:33:10 +0000

I recently had to upgrade an Oracle Linux production server running 19.30 Oracle databases for one of our customer. In this post, I will share with you the full set of steps that need to be carried out to run an in-place Oracle Linux upgrade when running Oracle databases. The method will be the same to upgrade from Oracle Linux 7 to 8, or 8 to 9 or 9 to 10 version. In my case, customer was running Oracle Linux 7, and I had to perform an in-place upgrade to version 8.

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.

Oracle: Failed to create Cloud Base DB Service DB-System with RU 19.32.

Clemens Bleile — Thu, 30 Jul 2026 10:14:55 +0000

Issue

I recently had to create a 19c Oracle Database on the Base Database Service on Oracle@Azure. Creating the DB-System failed with the following error:

Launch DbSystem failed. 
Reason : 
DCS-10001:Internal error encountered: 
Failed to download the fast clone.DcsException{errorHttpCode=InternalError,
msg=Failed to verify the checksum of file /opt/oracle/oak/pkgrepos/orapkgs/clones/oci_nid_19300_EE_AL32UTF8.tar.gz ,
msgId=11031,
causedB. Refer to WorkRequestId 5e4...c4d when opening a Service Request at My Oracle Support.

We didn’t see that issue before Database Release Update 19.32. A first test on native Oracle Cloud Infrastructure (OCI) to create a Base DB Service DB-system was successful. However further tests showed that shape “VM.StandardDB.x86” or “VM.BaseDB.x86” resulted in the same error whereas shape “AMD” resulted in a successful deployment of the DB-system on OCI. Trying to deploy on Oracle@Azure always failed, because the only shapes to chose from are “VM.StandardDB.x86” and “VM.BaseDB.x86”.

I opened a Service Request (SR) with the Oracle Multicloud team and requested escalation as we were stuck. After it was clear that the issue could be reproduced on native OCI, a 2nd SR was opened with the OCI team. I wanted the severity 2 SR to be escalated and requested that in a “manager engagement request”. The next update in the SR was this:

“Duty Manager update: escalating SR, will increase severity to sev1”

So with Cloud SRs either there’s no possibility anymore to “escalate” a sev2 SR, or the manager concluded that my issue has an impact on all customers trying to deploy a Base DB Service and decided to raise the issue to sev1.

The Support engineer involved an internal OPS-team which responded that they applied an internal fix and I should re-deploy my DB-system. It still failed and after another cycle the OPS-team responded that I should try again as they had to reload the zip-files. Afterwards we were able to deploy the DB-system successfully with a 19.32-database.

When looking into the documentation about the difference between the shapes VM.BaseDB.x86, VM.Standard.x86, Ampere VM.Standard.A1.Flex, AMD VM.Standard.E5.Flex, AMD VM.Standard.E4.Flex and Intel X9 VM.Standard3.Flex it can be seen that the shapes VM.BaseDB.x86 and VM.Standard.x86 are more independent of the features of a processor generation (generation-agnostic) whereas the AMD, Ampere and Intel shapes enable features of its processor generation. In addition the VM.BaseDB.x86 and VM.Standard.x86 let you customize the ECPUs (Elastic Compute Processing Unit = approx 25% of a CPU Core) allocated to a system whereas the other shapes are customizable on OCPUs (Oracle Compute Processing Unit = CPU Core) only. I.e. with ECPUs Oracle tries to provide a hardware independent CPU resource so that Oracle can replace the underlying hardware by e.g. going to the next Exadata generation without asking a customer to chose a different shape.

Summary

The case was interesting, because

a new Database Release Update may cause the deployment of a Cloud DB-system to fail.
Oracle is going in the direction of processor generation independent CPU resources on the Cloud. I.e. I could think of having ECPUs based on an AMD-processor today for my DB-system or Autonomous DB, an Intel processor tomorrow and in the future run my Database-system on a next x86-64 compatible processor architecture. Oracle may just replace the underlying Exadata with the next generation.
doing a “manager engagement request” can give the Cloud SR a real push.
trying to escalate a severity 2 Cloud SR may cause it to be raised to severity 1.
the engineer working on the SR and a manager called me and asked if I can provide feedback and fill in the survey about the case. I haven’t experienced in the past that the engineer and a manager request to get the survey filled in.

L’article Oracle: Failed to create Cloud Base DB Service DB-System with RU 19.32. est apparu en premier sur dbi Blog.

Oracle GenAI – Ask EM – Install and configure an Oracle Management agent on OEM 24ai

Marc Wagner — Tue, 28 Jul 2026 20:17:55 +0000

In order to be able to test the GenAI Ask EM functionality of OEM 24ai, and after I have first installed an OEM platform from OCI MarketPlace, I have been installing and configuring an Oracle Management agent on one of my DB System that I have in my lab. When the process is still quite the same I still found interesting to share it here in a blog, moreover I faced some issue that I could resolve.

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.

Oracle GenAI – Ask EM – Deploy Oracle Enterprise Manager 24ai from Marketplace

Marc Wagner — Mon, 13 Jul 2026 21:57:46 +0000

I have been looking to study and test what Oracle GenAI Ask EM assistant, also called now Oracle AI database assistant, can offer. This generative AI assistant is directly integrated into Oracle Enterprise Manager 24ai. Before being able to look into Ask EM, I first had to install an Oracle EM platform. I had the choice between doing all the installation myself manually or installing it from Oracle Marketplace. Knowing my current need, I decided to install it from the Oracle Marketplace. I would like to share in this first Ask EM series blogs this installation.

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
302 Moved Temporarily

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 302 Moved Temporarily

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.

GoldenGate Trail Purge Task Fails with “OGG-12111: JSON element ‘/csn’ does not match any schemas”

Julien Delattre — Wed, 24 Jun 2026 06:44:45 +0000

Since the beginning of the year, I had the opportunity to upgrade many GoldenGate setups to 26ai. On two of them, I was facing an issue regarding purge tasks that I could not solve. Since it took quite some time to finally find a solution, I figured it was worth documenting.

The client had two GoldenGate 26ai installations running on the same server.

One extracting data from DB2, with GoldenGate for DB2/zOS.
One replicating into an Oracle 19c database, reading from the same trail files.

Both setups were using the initial release of GoldenGate 26ai.

On both, I tried to set up trail purge tasks from the Administration Service web UI, and both GoldenGate trail purge failed with the same error.

Purge task creation from the web UI

To add a purge task, go to the Administration Service web UI, and on the left navigation panel, click on Tasks > Purge Trail.

From there, create a new task. You will be asked to provide a task name, one or multiple trail paths, retention rules, and whether to use checkpoints when purging trail files.

In my case, right after the creation, the purge task was failing with the OGG-12111 error. This happened no matter how I configured the task. The task was correctly configured, but it would fail every time it was scheduled to run

`OGG-12111` in the web UI

The full error displayed was the following:

JSON element '/csn' does not match any schemas
Code: OGG-12111
Cause: The JSON item does not validate against the provided JSON schema.
Action: Correct the JSON so that it conforms to the JSON schema.

I first thought that it was a configuration issue on my side, but there is no such csn field when configuring the task. I quickly realized that if something was wrong, it was internal to GoldenGate. And unfortunately, all trail files were affected in this setup, so there was no working example to investigate further. On all other setups that I worked on, I never faced the OGG-12111 error.

Analysis of `adminsrvr.log`

Digging into the Administration Service log, I found the real error underneath:

2026-04-20T14:18:41.377+0200 ERROR| ERROR   OGG-01072  Oracle GoldenGate Administration Service for Oracle:  NUMCNV_getUnsignedNumFromStr: Buffer overflow, needed: 21, allocated: 20. (Purge)

OGG-01072 is a buffer overflow in an internal GoldenGate method. It looked like a corrupted value gets embedded into the purge task JSON, and the JSON fails schema validation. And in the end, you get the OGG-12111 error in the web UI.

OGG-12111 was just the symptom, while OGG-01072 was the actual bug.

Unfortunately, I couldn’t find any MOS bug filed for this. However, by trial and error, I discovered that the fix appears to have been introduced silently in a later patch, maybe through another bug resolution (that I could not identify).

How to solve `OGG-12111` errors in GoldenGate 26ai ?

The only solution I found was patching GoldenGate to 23.26.2.0.1. I didn’t test the intermediate patch levels between 23.26.1.0.0 and 23.26.2.0.1, so I can’t say exactly which patch introduced the fix, but upgrading to 23.26.2.0.1 resolved the issue.

After patching, I went back to the Purge Trail section of the web UI, and the existing purge tasks were already working. I did not even have to recreate them.

So if you face this bug and your GoldenGate trail purge fails, don’t spend time reviewing the purge task parameters. Your tasks are most probably fine. The bug is inside the Administration Service’s numeric conversion method, and patching is the only way out.

L’article GoldenGate Trail Purge Task Fails with “OGG-12111: JSON element ‘/csn’ does not match any schemas” est apparu en premier sur dbi Blog.

LOB Replication With GoldenGate and Importance of Primary Keys

Julien Delattre — Tue, 16 Jun 2026 15:13:07 +0000

Every time I work on database migrations with GoldenGate, I have the same talks with application teams about missing primary keys. Especially when it comes to LOB replication with GoldenGate. In a previous blog, I wrote about how to interpret the DBA_GOLDENGATE_NOT_UNIQUE view, which lists tables with no primary key or non-null unique indexes. There are two main groups of tables listed here:

Tables where all columns can be used to identify uniqueness (bad_column='N')
Tables where not all columns can be used (bad_column='Y')

To show what happens when primary keys are missing in GoldenGate replication, let’s see a few examples. In all the examples, I will extract data from APP_SOURCE schema and replicate it into an APP_TARGET schema.

The parameters of the replication do not really matter here, but to be precise, here is the extract parameter file:

EXTRACT EXT1
USERIDALIAS source_cdb DOMAIN OracleGoldenGate
EXTTRAIL pdb1/aa
SOURCECATALOG PDB1
DDL INCLUDE MAPPED
TABLE APP_SOURCE.*;

And here is the replicat parameter file:

REPLICAT REP2
USERIDALIAS target_pdb DOMAIN OracleGoldenGate
DDL INCLUDE MAPPED
MAP PDB1.APP_SOURCE.*, TARGET PDB2.APP_TARGET.*;

First test : simple table with primary key

First, let’s try the most common example, with a table APP_SOURCE.TEST_PK created with a primary key. You can skip this part if you know how GoldenGate works, but I just wanted to include this for comparison.

CREATE TABLE APP_SOURCE.TEST_PK
(
    id   NUMBER PRIMARY KEY,
    data VARCHAR2(100)
);

Let’s insert a few rows in this table and look at the content of the table in both the source and the target.

INSERT INTO APP_SOURCE.TEST_PK VALUES (1,'A');
INSERT INTO APP_SOURCE.TEST_PK VALUES (2,'B');
COMMIT;

-- Verify source/target
SELECT * FROM APP_SOURCE.TEST_PK ORDER BY id;
SELECT * FROM APP_TARGET.TEST_PK ORDER BY id;

You will see the same content in both tables.

SQL> SELECT * FROM APP_SOURCE.TEST_PK ORDER BY id;

        ID DATA
---------- --------------------
         1 A
         2 B

Now, if you update the row with id=1, it will be updated in both tables as well.

UPDATE APP_SOURCE.TEST_PK SET data='A_UPDATED' WHERE id=1;
COMMIT;

-- Verify
SELECT * FROM APP_SOURCE.TEST_PK ORDER BY id;
SELECT * FROM APP_TARGET.TEST_PK ORDER BY id;

Checking the tables will give you the updated data.

SQL> SELECT * FROM APP_TARGET.TEST_PK ORDER BY id;

        ID DATA
---------- --------------------
         1 A_UPDATED
         2 B

Until then, nothing really interesting, but let’s look at the report file of the extract on the source. You will see the following information:

2026-06-06 07:00:52  INFO    OGG-06509  Using the following key columns for source table PDB1.APP_SOURCE.TEST_PK: ID.

Because the table has a primary key, GoldenGate knows that it should only use this column to identify unique rows.

Second test : table with no primary key and no LOB columns

In this second test, I will create a table without a primary key, but using only types that GoldenGate can use to identify uniqueness.

CREATE TABLE APP_SOURCE.TEST_NOPK
(
    id   NUMBER,
    data VARCHAR2(100)
);

We can already query the DBA_GOLDENGATE_NOT_UNIQUE view to find this new table listed with bad_column='N' :

SELECT *
FROM dba_goldengate_not_unique
WHERE owner='APP_SOURCE'
ORDER BY owner, table_name;

OWNER                          TABLE_NAME                     BAD_COLUMN
------------------------------ ------------------------------ ----------
APP_SOURCE                     TEST_NOPK                      N

Let’s do the same steps as before, inserting data and updating the content.

INSERT INTO APP_SOURCE.TEST_NOPK VALUES (1,'A');
INSERT INTO APP_SOURCE.TEST_NOPK VALUES (2,'B');
COMMIT;

SELECT * FROM APP_SOURCE.TEST_NOPK ORDER BY id;
SELECT * FROM APP_TARGET.TEST_NOPK ORDER BY id;

UPDATE APP_SOURCE.TEST_NOPK SET data='A_UPDATED' WHERE id=1;
COMMIT;

The content of the table is the same on source and target, as expected.

SQL> SELECT * FROM APP_TARGET.TEST_NOPK ORDER BY id;

        ID DATA
---------- --------------------
         1 A_UPDATED
         2 B

And looking at the extract report file, we can see that all viable columns were used. In that case, it meant taking ID and DATA.

2026-06-06 07:08:13  INFO    OGG-06508  Wildcard MAP (TABLE) resolved (entry PDB1.APP_SOURCE.*): TABLE "PDB1"."APP_SOURCE"."TEST_NOPK".

2026-06-06 07:08:13  WARNING OGG-06439  No unique key is defined for table TEST_NOPK. All viable columns will be used to represent the key, but may not guarantee uniqueness. KEYCOLS may be used to define the key. If using KEYCOLS, make sure that you create an INDEX in the target database for those column(s) as well.

2026-06-06 07:08:13  INFO    OGG-06509  Using the following key columns for source table PDB1.APP_SOURCE.TEST_NOPK: ID, DATA.

As mentioned in the other blog about primary keys in GoldenGate, this will work, but you will of course have performance issues when replicating data.

Third test : Table with no PK and a `CLOB` column

Now, let me show you the bad use case, where you don’t have a primary key and the table contains a non-viable column for uniqueness identification. In this example, I will use a CLOB column, but it could be another unbounded data type.

CREATE TABLE APP_SOURCE.TEST_CLOB
(
    id   NUMBER,
    code VARCHAR2(10),
    txt  CLOB
);

If we check the DBA_GOLDENGATE_NOT_UNIQUE view, we see the new table listed with bad_column='Y'.

SELECT *
FROM dba_goldengate_not_unique
WHERE owner='APP_SOURCE'
ORDER BY owner, table_name;

OWNER                          TABLE_NAME                     BAD_COLUMN
------------------------------ ------------------------------ ----------
APP_SOURCE                     TEST_CLOB                      Y
APP_SOURCE                     TEST_NOPK                      N

Let’s insert some data. But this time, I will add two more rows that are unique, but for which only the TXT content differs.

INSERT INTO app_source.test_clob VALUES (1,'A',TO_CLOB('LOB_1'));
INSERT INTO app_source.test_clob VALUES (2,'B',TO_CLOB('LOB_2'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_1'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_2'));
COMMIT;

The data was correctly inserted, and the content is the same on the source and target.

SQL> SELECT id,code,DBMS_LOB.SUBSTR(txt,40,1) txt FROM app_target.test_clob ORDER BY id;

        ID CODE       TXT
---------- ---------- ----------------------------------------
         1 A	      LOB_1
         2 B	      LOB_2
       100 DUP	      LOB_1
       100 DUP	      LOB_2

In the report file, we do not see any difference between this example and the one before. GoldenGate mentions using two columns for uniqueness identification : ID and CODE. GoldenGate never mentions that a third column existed and was not used. The warning displayed is the same as before.

2026-06-06 07:10:13  INFO    OGG-06508  Wildcard MAP (TABLE) resolved (entry PDB1.APP_SOURCE.*): TABLE "PDB1"."APP_SOURCE"."TEST_CLOB".

2026-06-06 07:10:13  WARNING OGG-06439  No unique key is defined for table TEST_CLOB. All viable columns will be used to represent the key, but may not guarantee uniqueness. KEYCOLS may be used to define the key. If using KEYCOLS, make sure that you create an INDEX in the target database for those column(s) as well.

2026-06-06 07:10:13  INFO    OGG-06509  Using the following key columns for source table PDB1.APP_SOURCE.TEST_CLOB: ID, CODE.

And now, the main problem I wanted to discuss regarding LOB replication with GoldenGate. If you try to delete one row by specifying all three columns, it will not always work.

DELETE FROM app_source.test_clob
WHERE id = 100
AND code = 'DUP'
AND DBMS_LOB.COMPARE(txt,TO_CLOB('LOB_1')) = 0;

Sometimes, the line with LOB_1 will be deleted:

        ID CODE       TXT
---------- ---------- ----------------------------------------
         1 A	      LOB_1
         2 B	      LOB_2
       100 DUP	      LOB_2

But sometimes, the line with LOB_2 will be deleted:

        ID CODE       TXT
---------- ---------- ----------------------------------------
         1 A	      LOB_1
         2 B	      LOB_2
       100 DUP	      LOB_1

More precisely, it will just delete the first line that was inserted. You then have two cases. If you insert LOB_1 first, it will be deleted correctly:

DROP TABLE app_source.test_clob PURGE;

CREATE TABLE app_source.test_clob (id NUMBER, code VARCHAR2(10), txt CLOB);

INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_1'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_2'));
COMMIT;

DELETE FROM app_source.test_clob
WHERE id = 100
AND code = 'DUP'
AND DBMS_LOB.COMPARE(txt,TO_CLOB('LOB_1')) = 0;
COMMIT;

SQL> SELECT id,code,DBMS_LOB.SUBSTR(txt,40,1) txt
FROM app_target.test_clob
WHERE code='DUP';

        ID CODE       TXT
---------- ---------- ----------------------------------------
       100 DUP	      LOB_2

And if you insert LOB_2 first, the incorrect line will be deleted:

DROP TABLE app_source.test_clob PURGE;

CREATE TABLE app_source.test_clob (id NUMBER, code VARCHAR2(10), txt CLOB);

INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_2'));
INSERT INTO app_source.test_clob VALUES (100,'DUP',TO_CLOB('LOB_1'));
COMMIT;

DELETE FROM app_source.test_clob
WHERE id = 100
AND code = 'DUP'
AND DBMS_LOB.COMPARE(txt,TO_CLOB('LOB_1')) = 0;
COMMIT;

SQL> SELECT id,code,DBMS_LOB.SUBSTR(txt,40,1) txt
FROM app_target.test_clob
WHERE code='DUP';

        ID CODE       TXT
---------- ---------- ----------------------------------------
       100 DUP	      LOB_1

You now know why you should always pay attention to tables in the DBA_GOLDENGATE_NOT_UNIQUE view with bad_column='Y'. If you have such tables, there are several scenarios that I presented in the last blog on the topic. But ignoring them is not one of them. This way, you will avoid issues regarding LOB replication with GoldenGate.

L’article LOB Replication With GoldenGate and Importance of Primary Keys est apparu en premier sur dbi Blog.

GoldenGate Row Identification: Misconceptions and Solutions

Julien Delattre — Fri, 12 Jun 2026 15:27:49 +0000

GoldenGate is a powerful replication tool, but it is so versatile that you should always check whether what you intend to do is supported or not. Oracle provides a few interesting scripts and views to check your environments before attempting a replication with GoldenGate, and I wanted to write about the DBA_GOLDENGATE_NOT_UNIQUE view.

Before explaining what this view contains and how to interpret it, you should remember that GoldenGate replicates data by replaying changes that occurred on the source database. One of the most important problems GoldenGate must solve is to identify the exact row that must be updated or deleted on the target database. This means that GoldenGate needs a way to uniquely identify every row in a table.

The simplest solution is a primary key, but GoldenGate row identification can also be done through a non-null unique index. When neither exists, GoldenGate must fall back to less efficient mechanisms. This means using all available columns to identify a row.

The DBA_GOLDENGATE_NOT_UNIQUE view contains tables that have no primary key and no non-null unique index. It is there to help you identify potential issues in your database schema and prepare in the best possible way a migration with GoldenGate or any replication work.

Here is an example of the content of the view:

OWNER			       TABLE_NAME		      BAD_COLUMN
------------------------------ ------------------------------ ----------
APP_PDB1		       TEST_NOPK		      N
APP_PDB1		       TEST_CLOB		      Y

The view is very simple, yet very often misunderstood. The owner and table_name column names are self-explanatory, but let’s talk about bad_column. This column has two possible values: Y and N.

First case – `bad_column = 'N'`

N is what you will most often see in this view. You should treat these as warnings. If you intend to replicate a table from this list, you can choose to ignore the warning if you don’t care about replication performance.

Tables in this list will be replicated using all columns as a substitute key. GoldenGate can usually handle these tables without any functional issue. However, UPDATE and DELETE operations become more expensive because every column must be used to identify the target row.

From my experience, you should still always discuss with the application owner or someone who knows the underlying database schema to try to avoid performance issues. A list of solutions is given at the end of the blog.

Second case – `bad_column = 'Y'`

If there is one point to remember from this blog, it’s this: you should never replicate data from tables with bad_column='Y' without thorough investigation.

Tables listed here contain one or more columns that GoldenGate cannot safely use as part of a substitute key, such as LONG or CLOB.

Since GoldenGate cannot build a complete substitute key from all columns, row identification becomes problematic. Depending on the table structure and replication configuration, GoldenGate may be unable to correctly locate rows for UPDATE or DELETE operations.

In practice, a table with bad_column='Y' should be considered a candidate for schema remediation before replication (see the list of options below).

Will there be an error if GoldenGate cannot identify uniqueness ?

This is a very common misconception when talking about these primary key issues. GoldenGate does not verify that the columns used for row identification are truly unique. If duplicate rows exist, a replicat may update or delete an unintended row. In many cases no explicit GoldenGate error will be generated because, from GoldenGate’s perspective, a matching row was found. It could silently delete the wrong row, and you will never hear a word about it. In the logs, you won’t see the difference.

What can be done to solve these issues ?

Essentially, there are four possible approaches:

If you have the ability to create a primary key or a non-null unique index on the source database, go for it before the initial load of your target database. This is the safest approach because uniqueness is enforced by the database itself.
If you cannot alter the source schema but are 100% sure that a subset of columns that already exists in the table can uniquely identify every row, you can use the KEYCOLS keyword in your parameter files.
Sometimes, the application design prevents duplicates from being generated. Again, you need to be sure about this. But sometimes, it means that you could rely on the application design.
When bad_column is N, you could decide to not do anything. For tables with a lot of activity, it could slow down your replication. During a migration, it could even completely block it in production. This should only be done in last resort.

A common misconception is that every table listed in DBA_GOLDENGATE_NOT_UNIQUE is unsupported by GoldenGate. This is not the case. At the other end of the spectrum, I’ve heard countless times that these warnings can be ignored. Do that, and you will have nightmares solving issues once you hit production. The view merely highlights tables for which GoldenGate cannot rely on a primary key or a non-null unique index for row identification. The real concern is the bad_column flag: N is a performance warning, while Y deserves immediate investigation before any replication project.

L’article GoldenGate Row Identification: Misconceptions and Solutions est apparu en premier sur dbi Blog.