> ## Content Index
> Fetch the complete content index at: https://georgetasioulis.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Fixing the AlmaLinux 9 dnf upgrade conflict on OpenVZ 7 containers (initscripts vs network-scripts)
- URL: https://georgetasioulis.com/fixing-the-almalinux-9-dnf-upgrade-conflict-on-openvz-7-containers-initscripts-vs-network-scripts/
- Published: 2026-08-10T16:23:00.000Z
- Updated: 2026-09-10T10:50:11.000Z
- Description: An AlmaLinux 9 upgrade hits a dependency conflict on OpenVZ 7—and the suggested fix can break networking. Here's how to update the matching packages together and keep your container connected.
- Author: George Tasioulis
- Tags: AlmaLinux, OpenVZ, Linux, Package Management, Networking

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](https://forum.openvz.org/index.php?t=msg&th=13698&goto=53858&&ref=georgetasioulis.com#msg%5F53858).

**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:**

```bash
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](https://repo.almalinux.org/almalinux/9/devel/x86%5F64/os/Packages/?ref=georgetasioulis.com) and grab whatever `network-scripts` version is current; it will match the `initscripts` candidate in the error.

**Step 3: upgrade the pair together:**

```bash
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:**

```bash
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.