Cannot install both iptables

I

inomi13

Verified User
Joined
Jan 7, 2022
Messages
140
Today I wanted update System packagesbut I can't do this because I receive below information. I have AlmaLinux release 9.3, directadmin 1.661, csf

Error:
Problem: cannot install both iptables-libs-1.8.10-2.el9.x86_64 from baseos and iptables-libs-1.8.8-6.el9_1.x86_64 from @System
- package iptables-legacy-1.8.8-6.el9.2.x86_64 from @System requires (iptables-libs(x86-64) = 1.8.8-6.el9 or iptables-libs(x86-64) = 1.8.8-6.el9_1), but none of the providers can be installed
- cannot install the best update candidate for package iptables-libs-1.8.8-6.el9_1.x86_64
- cannot install the best update candidate for package iptables-legacy-1.8.8-6.el9.2.x86_64
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
Click to expand...
 
This is not a DA error but an OS error. DA does not install iptables, the OS does.

I've just checked my system and that has 1.8.8-6.el9_1 and has update for
iptables-libs 1.8.10-2.el9
iptables-nft 1.8.10-2.el9

both updates went without any isues from baseos repo.

Howevever in your case I see:
iptables-libs-1.8.8-6.el9_1.x86_64 from @System
Click to expand...
Seems you have some conflicting @System repo enabled. I would suggest disabling that @System repo and use baseos repo as should.

What is that @System repo by the way? Did you add some custom repo? Because none of my Almalinux 9 servers have any system repo.
 
cat /etc/yum.conf

[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False
exclude=apache* nginx* httpd* mod_* mysql* MySQL* mariadb* da_* *ftpd exim* sendmail* php* bind-chroot* dovecot*
Click to expand...

cat etc/yum.repos.d

-rw-r--r--. 1 root root 951 Apr 15 21:33 almalinux-crb.repo
-rw-r--r-- 1 root root 579 Jan 8 13:27 ookla_speedtest-cli.repo
-rw-r--r--. 1 root root 1023 Nov 7 20:59 almalinux-appstream.repo
-rw-r--r--. 1 root root 987 Nov 7 20:59 almalinux-baseos.repo
-rw-r--r--. 1 root root 987 Nov 7 20:59 almalinux-extras.repo
-rw-r--r--. 1 root root 1107 Nov 7 20:59 almalinux-highavailability.repo
-rw-r--r--. 1 root root 951 Nov 7 20:59 almalinux-nfv.repo
-rw-r--r--. 1 root root 963 Nov 7 20:59 almalinux-plus.repo
-rw-r--r--. 1 root root 1107 Nov 7 20:59 almalinux-resilientstorage.repo
-rw-r--r--. 1 root root 939 Nov 7 20:59 almalinux-rt.repo
-rw-r--r--. 1 root root 951 Nov 7 20:59 almalinux-sap.repo
-rw-r--r--. 1 root root 999 Nov 7 20:59 almalinux-saphana.repo
-rw-r--r-- 1 root root 1142 Aug 17 2023 epel-cisco-openh264.repo
-rw-r--r-- 1 root root 1552 Aug 17 2023 epel-testing.repo
-rw-r--r-- 1 root root 1453 Aug 17 2023 epel.repo
Click to expand...
 
Code: 
yum clean all
yum update
if still can't update, do this around 5-6 times or more than this
 
Active8 said:
Had it self yesterday with AL9 update, fix :
Code: 
sudo dnf remove iptables
sudo dnf remove iptables-libs
sudo dnf install iptables
sudo dnf install iptables-libs
dnf update -y
Click to expand...
I did what you wrote and iptables was updated. So if csf demon after update iptables works and I see iptables rules in ConfigServer Firewall, that everything works correct?
 
Last edited:
Seems the issue is that yum is seeing some @System packages which isn't there. Seems also other packages than iptables have this issue.

Maybe repo not the same? This is how the content of the baseos repo should look for Alma 9.
Code: 
[baseos]
name=AlmaLinux $releasever - BaseOS
mirrorlist=https://mirrors.almalinux.org/mirrorlist/$releasever/baseos
# baseurl=https://repo.almalinux.org/almalinux/$releasever/BaseOS/$basearch/os/
enabled=1
gpgcheck=1
countme=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9
metadata_expire=86400
enabled_metadata=1

[baseos-debuginfo]
name=AlmaLinux $releasever - BaseOS - Debug
mirrorlist=https://mirrors.almalinux.org/mirrorlist/$releasever/baseos-debug
# baseurl=https://repo.almalinux.org/vault/$releasever/BaseOS/debug/$basearch/
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9
metadata_expire=86400
enabled_metadata=0

[baseos-source]
name=AlmaLinux $releasever - BaseOS - Source
mirrorlist=https://mirrors.almalinux.org/mirrorlist/$releasever/baseos-source
# baseurl=https://repo.almalinux.org/vault/$releasever/BaseOS/Source/
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9
metadata_expire=86400
enabled_metadata=0

You can check and verify and see if there are differences in yours.
 
Richard G said:
Seems the issue is that yum is seeing some @System packages which isn't there. Seems also other packages than iptables have this issue.

Maybe repo not the same? This is how the content of the baseos repo should look for Alma 9.
Code: 
[baseos]
name=AlmaLinux $releasever - BaseOS
mirrorlist=https://mirrors.almalinux.org/mirrorlist/$releasever/baseos
# baseurl=https://repo.almalinux.org/almalinux/$releasever/BaseOS/$basearch/os/
enabled=1
gpgcheck=1
countme=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9
metadata_expire=86400
enabled_metadata=1

[baseos-debuginfo]
name=AlmaLinux $releasever - BaseOS - Debug
mirrorlist=https://mirrors.almalinux.org/mirrorlist/$releasever/baseos-debug
# baseurl=https://repo.almalinux.org/vault/$releasever/BaseOS/debug/$basearch/
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9
metadata_expire=86400
enabled_metadata=0

[baseos-source]
name=AlmaLinux $releasever - BaseOS - Source
mirrorlist=https://mirrors.almalinux.org/mirrorlist/$releasever/baseos-source
# baseurl=https://repo.almalinux.org/vault/$releasever/BaseOS/Source/
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-AlmaLinux-9
metadata_expire=86400
enabled_metadata=0

You can check and verify and see if there are differences in yours.
Click to expand...
My almalinux-baseos.repo looks exactly the same as yours.
 
Hmmz... interesting. Then I don't know why the OS is looking for @System. I've seen this in the past when searching via Google, not only with iptables but also with others.
Would be indeed better if we could find the cause of this. Because non of my systems gave any issue. And I have the same yum.conf file as you.
So it must be some other cause then the yum.conf or the baseos repo.

Maybe another repo?
When I do a dnf repolist only these show up:
Code: 
repo id                                            repo name
appstream                                          AlmaLinux 9 - AppStream
baseos                                             AlmaLinux 9 - BaseOS
crb                                                AlmaLinux 9 - CRB
epel                                               Extra Packages for Enterprise Linux 9 - x86_64
epel-cisco-openh264                                Extra Packages for Enterprise Linux 9 openh264 (From Cisco) - x86_64
extras                                             AlmaLinux 9 - Extras

Hmmz... repostlist doesn't show them all... so this is index.
Code: 
-rw-r--r--.   1 root root 1023 2023-11-07 20:59 almalinux-appstream.repo
-rw-r--r--.   1 root root  987 2023-11-07 20:59 almalinux-baseos.repo
-rw-r--r--.   1 root root  951 2024-04-26 18:38 almalinux-crb.repo
-rw-r--r--.   1 root root  987 2023-11-07 20:59 almalinux-extras.repo
-rw-r--r--.   1 root root 1.1K 2023-11-07 20:59 almalinux-highavailability.repo
-rw-r--r--.   1 root root  951 2023-11-07 20:59 almalinux-nfv.repo
-rw-r--r--.   1 root root  963 2023-11-07 20:59 almalinux-plus.repo
-rw-r--r--.   1 root root 1.1K 2023-11-07 20:59 almalinux-resilientstorage.repo
-rw-r--r--.   1 root root  939 2023-11-07 20:59 almalinux-rt.repo
-rw-r--r--.   1 root root  999 2023-11-07 20:59 almalinux-saphana.repo
-rw-r--r--.   1 root root  951 2023-11-07 20:59 almalinux-sap.repo
-rw-r--r--    1 root root 1.2K 2023-08-17 11:50 epel-cisco-openh264.repo
-rw-r--r--    1 root root 1.5K 2023-08-17 11:50 epel.repo
-rw-r--r--    1 root root 1.6K 2023-08-17 11:50 epel-testing.repo

Maybe you and @Active8 can compare which repo's you have the same.
Could be something is the same causing the issue. Could be something else.

I presume you did not do an inline upgrade from Alma 8 to Alma 9? Just looking for possible causes.
 
zEitEr said:
knows the solution.
Click to expand...
Yes but we are curious as to the cause. As we both have that epel release and none of my servers have the issue.

Or maybe the ones having issues might need to do a "yum update yum" first, and then try again to see if that would fix the cause too?
 
Richard G said:
Or maybe the ones having issues might need to do a "yum update yum" first, and then try again to see if that would fix the cause too?
Click to expand...

That's the only thing that I found to be interesting when googled. I did not go deeper in an investigation.
 
Today I ran in to the exact same problem. The fixes described here and in the other thread did not solve it for me.
After some more searching I found this solution, source: How-can-I-fix-the-error-Problem-cannot-install-both-iptables-libs-1.8.10-2.el9.x86_64-from-baseos-and-iptables-libs-1.8.8-6.el9_1.x86_64-from-atSystem-when-upgrading-to-AlmaLinux-9.4

I double-checked that CSF/LFD is working correctly.

To fix this error remove the old iptables-legacy package and install the iptables-nft package:


Code: 
dnf remove iptables-legacy
dnf install iptables-nft
 
Good tip. Still wondering about the cause of this as many of us don't run into this issue and some do.
 
One additional remark. I always update system packages through the CLI as root. When confronted with this error I tried updating the system packages through custom build hoping this would be known at DA and they fixed it all ready. The CB log shows no output at all, leaving me in the dark. A simple error message would suffice. Hint! ;)

I know CSF does not work with firewalld. It removes firewalld and install iptables. Perhaps here lies the source of the culprit.
 
Wanabo said:
Perhaps here lies the source of the culprit.
Click to expand...
Might be possible. I also always update all packages (DA and OS) as root in console. When installing a server I always check if something is already running like firewalld or ipfw. If yes, I uninstall that before even starting to install DA.

So maybe this might be the difference. Or maybe in the installation template of the datacenter if they install iptables-legacy instead of iptables-NFT.
I checked and in my systems the iptables-nft is installed. As far as I'm aware of this is installed (by my datacenter) by default on Alma 9.
But I was just checking my Almalinux 8 server and there I only have "iptables" in yum, no -legacy or -nft.

So it might have to do then with default OS installation on Alma 9, because that's where both options are available in yum. Or maybe DA installs it if not installed. Just did a doublecheck in Alma 9 and it's the Epel release which provides the iptables-legacy packages.
We also have epel in Alma 8 but there it does not have a iptables-legacypackage.
 
Moin,
In my case for RHEL9, the solution was - without uninstall podman again:
Code: 
dnf install iptables-nft --allowerasing

Updated:
  iptables-libs-1.8.10-4.el9_4.x86_64
Installed:
  iptables-nft-1.8.10-4.el9_4.x86_64
Removed:
  iptables-legacy-1.8.10-2.2.el9.x86_64
 
You must log in or register to reply here.
Back
Top