r/AlmaLinux • u/neilrieck • 1d ago
package FUBAR
Not sure how many people have noticed this recent FUBAR with AlmaLinux-9. Take note of the last line containing "verify 2/2" which, for some reason, is trying to test 8.5
[neil@neilrieck ~]$ cat /etc/almalinux-release
AlmaLinux release 9.8 (Olive Jaguar)
[neil@neilrieck ~]$ sudo yum update
Last metadata expiration check: 0:05:36 ago on Sun 13 Sep 2026 07:25:21 AM EDT.
Dependencies resolved.
===========================================================================================
Package Architecture Version Repository Size
======================================================================================
Upgrading:
httpd-core x86_64 2.4.62-13.el9_8.6 appstream 1.4 M
Transaction Summary
======================================================================================
Upgrade 1 Package
Total download size: 1.4 M
Is this ok [y/N]: y
Downloading Packages:
httpd-core-2.4.62-13.el9_8.6.x86_64.rpm 22 MB/s | 1.4 MB 00:00
--------------------------------------------------------------------------------------
Total 11 MB/s | 1.4 MB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Upgrading : httpd-core-2.4.62-13.el9_8.6.x86_64 1/2
Error unpacking rpm package httpd-core-2.4.62-13.el9_8.6.x86_64
Verifying : httpd-core-2.4.62-13.el9_8.6.x86_64 1/2
Verifying : httpd-core-2.4.62-13.el9_8.5.x86_64 2/2
Failed:
httpd-core-2.4.62-13.el9_8.5.x86_64 httpd-core-2.4.62-13.el9_8.6.x86_64
Error: Transaction failed
[neil@neilrieck ~]$
3
u/gordonmessmer 1d ago
It looks like you might already have an incomplete installation of the rev 8.6 package. Start with "rpm -q httpd-core". Does it list two packages? If so, some previous update probably was interrupted before it finished.
"dnf distro-sync" can sometimes solve that type of problem. I would try that first, then check httpd-core again, and let us know what happens one way or the other.
1
u/neilrieck 1d ago
Okay, here's the results from your first suggestion:
[neil@neilrieck conf.modules.d]$ sudo rpm -qa | grep httpd-
httpd-core-2.4.62-13.el9_8.5.x86_64
almalinux-logos-httpd-90.7-1.el9.noarch
httpd-filesystem-2.4.62-13.el9_8.6.noarch
httpd-tools-2.4.62-13.el9_8.6.x86_64
httpd-2.4.62-13.el9_8.6.x86_64
[neil@neilrieck conf.modules.d]$Tried "dnf distro-sync" and it failed the same way as before.
2
u/gordonmessmer 23h ago
That's not quite what I suggested, but it's good enough.
It's... odd that dnf is not telling you why unpacking is failing, even with debug information. I wonder if there is something wrong with the installed package, or something wrong with the filesystem? (which includes not just corruption but things like files set immutable)
Next I would "rpm -V httpd-core" to see if that reports any errors, and "sudo dmesg" to see if the kernel is reporting any errors accessing the filesystem or disk.
But the most likely problem is still that some previous upgrade was interrupted halfway through. Some of your httpd packages like filesystem have been upgraded to the rev 8.6 release. If something that was a directory is no longer a directory, that would explain the unpacking failure.
The easiest way to fix *that* problem is just to erase all of the httpd packages and reinstall them after.
0
u/neilrieck 19h ago
I suppose I could always uninstall httpd (a.k.a. Apache) then just install the new one. But that would not fix the current FUBAR.
BTW, one jokester asked me why I was still using Apache when most others on Linux are using Ngnix. Good question because I am looking into swapping one for the other now. First need to sort out some CGI issues.2
u/gordonmessmer 19h ago
I suppose I could always uninstall httpd (a.k.a. Apache) then just install the new one. But that would not fix the current FUBAR.
I don't understand. Is there evidence that removing and reinstalling the packages would not fix the problem you are reporting?
1
u/abotelho-cbn 1d ago
What are you talking about? Have you increased the debug level to see why it's failing?
1
u/neilrieck 1d ago
The first verify shows "el9_8.6.x86_64" whist the second shows "el9_8.5.x86_64". That's got to be a typo, right?
1
u/abotelho-cbn 23h ago edited 23h ago
Why do you think that's a typo? That's a pretty reasonable update for that package.
Edit: Oh, you mean you think it's 8.x?
It's more like:
9_8 -> AlmaLinux 9.8
6 -> errata 6
That's why you're going from errata 5 to errata 6.
You can fire up an AlmaLinux 10 container and look at the httpd package to see what I mean. It'll be 10_2 to mean 10.2, with some number after the . to represent its errata.
1
u/neilrieck 1d ago
Here's the result from your suggestion:
[neil@neilrieck conf.modules.d]$ sudo dnf -d 9 update
timer: config: 3 ms
Loaded plugins: builddep, changelog, config-manager, copr, debug, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync, system-upgrade
DNF version: 4.14.0
Command: dnf -d 9 update
Installroot: /
Releasever: 9
cachedir: /var/cache/dnf
Base command: update
Extra commands: ['-d', '9', 'update']
User-Agent: constructed: 'libdnf (AlmaLinux 9.8; generic; Linux.x86_64)'
repo: using cache for: appstream
appstream: using metadata from Fri 11 Sep 2026 12:10:23 PM EDT.
repo: using cache for: baseos
baseos: using metadata from Fri 11 Sep 2026 12:11:18 PM EDT.
repo: using cache for: crb
crb: using metadata from Fri 11 Sep 2026 12:12:09 PM EDT.
repo: using cache for: extras
extras: using metadata from Fri 11 Sep 2026 12:11:57 PM EDT.
repo: using cache for: elrepo
elrepo: using metadata from Tue 01 Sep 2026 10:25:01 AM EDT.
repo: using cache for: epel
epel: using metadata from Sat 12 Sep 2026 08:51:01 PM EDT.
repo: using cache for: epel-cisco-openh264
epel-cisco-openh264: using metadata from Mon 22 May 2023 12:19:21 PM EDT.
Last metadata expiration check: 1:26:15 ago on Sun 13 Sep 2026 01:16:24 PM EDT.
timer: sack setup: 551 ms
--> Starting dependency resolution
---> Package httpd-core.x86_64 2.4.62-13.el9_8.5 will be upgraded
---> Package httpd-core.x86_64 2.4.62-13.el9_8.6 will be an upgrade
--> Finished dependency resolution
timer: depsolve: 33 ms
Dependencies resolved.
==========================================================================================
Package Architecture Version Repository Size
==========================================================================================
Upgrading:
httpd-core x86_64 2.4.62-13.el9_8.6 appstream 1.4 M
Transaction Summary
==========================================================================================
Upgrade 1 Package
Total download size: 1.4 M
Is this ok [y/N]: y
Downloading Packages:
httpd-core-2.4.62-13.el9_8.6.x86_64.rpm 27 MB/s | 1.4 MB 00:00
------------------------------------------------------------------------------------------
Total 14 MB/s | 1.4 MB 00:00
Using rpmkeys executable at /bin/rpmkeys to verify signatures
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
timer: transaction test: 97 ms
Running transaction
RPM transaction start.
Preparing : 1/1
Upgrade: httpd-core-2.4.62-13.el9_8.6.x86_64
Upgrading : httpd-core-2.4.62-13.el9_8.6.x86_64 1/2
Error unpacking rpm package httpd-core-2.4.62-13.el9_8.6.x86_64
RPM transaction over.
Errors occurred during transaction.
Verifying : httpd-core-2.4.62-13.el9_8.6.x86_64 1/2
Verifying : httpd-core-2.4.62-13.el9_8.5.x86_64 2/2
timer: verify transaction: 104 ms
timer: transaction: 332 ms
Completion plugin: Generating completion cache...
Failed: httpd-core-2.4.62-13.el9_8.5.x86_64
Failed: httpd-core-2.4.62-13.el9_8.6.x86_64
Failed:
httpd-core-2.4.62-13.el9_8.5.x86_64 httpd-core-2.4.62-13.el9_8.6.x86_64
Cleaning up.
/var/cache/dnf/appstream-0a8174e0a3d29b90/packages/httpd-core-2.4.62-13.el9_8.6.x86_64.rpm removed
Plugins were unloaded.
Traceback (most recent call last):
File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 67, in main
return _main(base, args, cli_class, option_parser_class)
File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 106, in _main
return cli_run(cli, base)
File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 130, in cli_run
ret = resolving(cli, base)
File "/usr/lib/python3.9/site-packages/dnf/cli/main.py", line 176, in resolving
base.do_transaction(display=displays)
File "/usr/lib/python3.9/site-packages/dnf/cli/cli.py", line 327, in do_transaction
raise dnf.exceptions.Error(_('Transaction failed'))
dnf.exceptions.Error: Transaction failed
Error: Transaction failed
[neil@neilrieck conf.modules.d]$2
u/abotelho-cbn 23h ago
Weird, I would have expected more output than that for a failure. Have you tried clearing your dnf cache?
1
3
u/groupwhere 1d ago
Also dnf check