If you’re running an AlmaLinux 9 container at an OpenVZ 7 VPS provider, there’s a good chance the very first dnf upgrade you run greets you with this:
Error:
Problem: cannot install both initscripts-10.11.8-4.el9.x86_64 and initscripts-10.11.4-1.el9.x86_64
- package network-scripts-10.11.4-1.el9.x86_64 requires initscripts(x86-64) = 10.11.4-1.el9, but none of the providers can be installed
- cannot install the best update candidate for package initscripts-10.11.4-1.el9.x86_64
- problem with installed package network-scripts-10.11.4-1.el9.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)
You’ll typically run into this AlmaLinux 9 template at providers still running legacy SolusVM 1 with OpenVZ 7. I recently hit it on a freshly reinstalled container and, to make things more interesting, the template was still at 9.0, so the fix below also took the container through a full 9.0 to 9.8 jump in one go.
Here’s what’s going on, why dnf’s own suggestions are a trap in this environment, and the clean way out.
Why this happens
Red Hat removed the legacy network-scripts package from EL9. NetworkManager is the only supported way to configure networking. But OpenVZ containers use venet interfaces, and the vzctl distribution scripts that provision container IPs still write ifcfg files and drive the old network.service. NetworkManager doesn’t manage venet, so the container templates ship network-scripts anyway, pinned to the exact initscripts version they were built with. (SolusVM 1’s “Reconfigure Network” tool has the same limitation on KVM, which is why some providers carry the package on their KVM templates too.)
The moment the distro publishes a newer initscripts, the solver hits a wall: it wants to upgrade initscripts, but the installed network-scripts hard-requires the old version, and there’s no newer network-scripts in BaseOS to pair with it. Dead end.
Virtuozzo is aware of this. It’s tracked internally as PSBM-156563 and should be fixed in a future VHS release. Until then, you need a workaround.
Why you should NOT use --allowerasing
dnf helpfully suggests --allowerasing, and various knowledgebase articles echo it. On a KVM VPS with real NICs, erasing network-scripts and switching to NetworkManager is a valid path. On an OpenVZ venet container it will break your networking. There’s nothing for NetworkManager to take over: venet configuration comes from the host through the legacy scripts you just deleted. The container will come up on its next restart with no network config at all.
--skip-broken and --nobest “work” in the sense that they hold initscripts back and upgrade everything else, but you’ll trip over the same error on every future update, and you’re relying on the solver quietly skipping things rather than an explicit decision.
The fix: pull the matching network-scripts from the AlmaLinux devel repo
Here’s the part that makes a clean solution possible: AlmaLinux still builds network-scripts for EL9, it just lives in the devel repository instead of BaseOS. So instead of holding packages back, you upgrade the pair in lockstep. This workaround was shared by Virtuozzo support on the OpenVZ forum.
Step 1: find the version dnf wants for initscripts. It’s right there in the error message. In my case: 10.11.8-4.el9.
Step 2: download the matching network-scripts build:
cd /tmp
curl -O https://repo.almalinux.org/almalinux/9/devel/x86_64/os/Packages/network-scripts-10.11.8-4.el9.x86_64.rpm
If the exact filename 404s, browse the Packages directory and grab whatever network-scripts version is current; it will match the initscripts candidate in the error.
Step 3: upgrade the pair together:
dnf update ./network-scripts-10.11.8-4.el9.x86_64.rpm
dnf pulls the matching initscripts from BaseOS in the same transaction. The version pin is satisfied, nothing is erased, and your ifcfg files are untouched, so there’s zero network downtime.
Step 4: run the actual upgrade:
dnf upgrade
It now resolves cleanly, with nothing held back.
The catch: it recurs
This isn’t a one-time fix. The next time BaseOS ships a newer initscripts, the same conflict comes back, and you repeat the devel-repo dance with the then-current version. It’s a two-minute job once you know the pattern, but if you manage a fleet of these containers it’s worth documenting internally. The proper fix is coming from Virtuozzo under PSBM-156563.
Until then: never --allowerasing on venet, and let the devel repo keep your pair in sync.
That’s such a common problem when migrating from SolusVM. It’s interesting how the initscripts still cause issues even now.