Cannot undo dnf transaction - AL 9.4

Hi, I updated the system but would like to undo, but “dnf history undo 31” complains with:

[root@idm01 ~]# dnf history undo 31
Last metadata expiration check: 2:10:49 ago on Fri Jun 14 10:41:24 2024.
Error: The following problems occurred while running a transaction:
  Cannot find rpm nevra "kernel-5.14.0-362.18.1.el9_3.x86_64".
  Cannot find rpm nevra "kernel-core-5.14.0-362.18.1.el9_3.x86_64".
  Cannot find rpm nevra "kernel-modules-5.14.0-362.18.1.el9_3.x86_64".
  Cannot find rpm nevra "kernel-modules-core-5.14.0-362.18.1.el9_3.x86_64".

Now I do read somewhere that this is due to the older packages not retained in the package repository. Is there a solution for this?

dnf history:

[root@idm01 ~]# dnf history list
ID     | Command line                                                                                                                               | Date and time    | Action(s)      | Altered
    31 | update                                                                                                                                     | 2024-06-14 09:49 | C, E, I, U     |   23 EE

First of all, packages of each point release are in separate trees. A mirror has thus directories: 9.0, 9.1, 9.2, 9.3, and 9.4. However, disk-space continues to be limited, so the older directories on mirrors are empty. The 9.3 tree was cleared soon after 9.4 was released. There is one server, “vault”, that keeps the old trees – as historical record of what once was.

The definition of baseos repo does fetch the URL of the repo (nearest mirrors) from$releasever/baseos
The $releasever expands to 9. The server returns URLs that have ‘9.4’ in them.
If you do ask for, you will get same URLs.
This way it was possible centrally to switch every Alma 9 to use the 9.4 repos when 9.4 was released.

You did run dnf update when repo was already 9.4. The old el9_3 versions packages that were removed as part of installation have never been in the 9.4 repos. If you want to re-install the old kernel, you have to make the dnf to see the repos of 9.3.

As it happens, the mirrorlist server does now return URL to vault, where the 9.3 repos have been moved to, if one asks for

Hence, with releasever=9.3 one can see the old repos. For example:
dnf --releasever=9.3 list kernel --showduplicates

However, why do you want to undo an update?
If kernel was the only thing that was removed, then you could install it, rather than undo.

Hi jlehtone, thanks for clarifying the issue. I have resolved it by restoring a backup.
The reason why is because of a suspicion the update broke a freeipa setup.
Does this mean dnf cannot rollback/undo a transaction once the tx contains packages of an earlier release?

Transaction “update X” does essentially perform “remove X-old && install X-new”.
The rollback does the reverse: “remove X-new && install X-old”.
In order to do “install X-old” the package X-old must be in one of the enabled repositories.

If all the packages to install are in 9.3’s repos, then:

dnf --releasever=9.3 history undo 31

I.e. the new kernel has an issue?

You were not running the 5.14.0-362.18.1.el9_3 when you did the update – one cannot remove the kernel that is in use.
Presumably you were running a “good” kernel, which you still have.
You don’t have to undo – to get back a kernel that you were not using. Just boot with that good kernel.

I was running “5.14.0-427.18.1.el9_4”. There was nothing wrong with the kernel or booting.
Only issue I had was with an application after updating it and wanted to revert a dnf update transaction which I thought caused.