Symptoms
The nightly cPanel updates or attempts to run package updates manually report conflicts for the GD packages with libavif. This error can also prevent the EasyApache 4 profile deployment during a cPanel installation. This behavior is seen on AlmaLinux or CloudLinux 9 environments.
CONFIG_TEXT: [/usr/local/cpanel/scripts/update-packages] Error:
[/usr/local/cpanel/scripts/update-packages] Problem 1: package ea-php84-php-gd-8.4.25-2.2.1.cpanel.x86_64 from @System requires libavif.so.15()(64bit), but none of the providers can be installed
[/usr/local/cpanel/scripts/update-packages] - cannot install both libavif-1.1.1-3.el9.x86_64 from epel and libavif-0.11.1-5.el9.x86_64 from @System
[/usr/local/cpanel/scripts/update-packages] - cannot install both libavif-1.1.1-3.el9.x86_64 from epel and libavif-0.11.1-4.el9.x86_64 from alt-common
[/usr/local/cpanel/scripts/update-packages] - cannot install both libavif-1.1.1-3.el9.x86_64 from epel and libavif-0.11.1-5.el9.x86_64 from alt-common
[/usr/local/cpanel/scripts/update-packages] - cannot install both libavif-0.11.1-4.el9.x86_64 from imunify360 and libavif-1.1.1-3.el9.x86_64 from epel
[/usr/local/cpanel/scripts/update-packages] - cannot install the best update candidate for package libavif-0.11.1-5.el9.x86_64
[/usr/local/cpanel/scripts/update-packages] - cannot install the best update candidate for package ea-php84-php-gd-8.4.25-2.2.1.cpanel.x86_64
During a new installation, the EasyApache 4 profile deployment may instead fail with:
CONFIG_TEXT: [ea_install_profile] Problem 1: cannot install the best candidate for the job
[ea_install_profile] - nothing provides libavif.so.15()(64bit) needed by ea-php83-php-gd-8.3.35-1.1.1.cpanel.x86_64 from EA4-c9
Cause
The EPEL repository recently added libavif-1.1.1-3.el9.x86_64 with libavif.so.16. This causes conflicts with the GD package requirement of libavif.so.15, as both versions cannot be installed.
Resolution
This issue has been reported to our developers, and they are reviewing it further in an internal case EA4-334. Once a fix for this issue is released, it will be documented in our changelogs.
Update:
The packages have been rebuilt to resolve the conflict.
2026 October 1
ea-php81
- EA4-334: Update the
ea-php81-php-gdlibavif dependencies to resolve a conflict with the EPEL libavif 1.1.1 update on AlmaLinux 9 and CloudLinux 9.ea-php82
- EA4-334: Update the
ea-php82-php-gdlibavif dependencies to resolve a conflict with the EPEL libavif 1.1.1 update on AlmaLinux 9 and CloudLinux 9.ea-php83
- EA4-334: Update the
ea-php83-php-gdlibavif dependencies to resolve a conflict with the EPEL libavif 1.1.1 update on AlmaLinux 9 and CloudLinux 9.ea-php84
- EA4-334: Update the
ea-php84-php-gdlibavif dependencies to resolve a conflict with the EPEL libavif 1.1.1 update on AlmaLinux 9 and CloudLinux 9.ea-php85
- EA4-334: Update the
ea-php85-php-gdlibavif dependencies to resolve a conflict with the EPEL libavif 1.1.1 update on AlmaLinux 9 and CloudLinux 9.
If you are seeing this issue still and are using another provider for EasyApache 4 packages, you can you the following workaround.
You can version-lock these packages to prevent the updates from introducing this conflict.
# dnf install python3-dnf-plugin-versionlock
# dnf versionlock add libavif-0.11.1-5.el9.x86_64
# dnf versionlock add svt-av1-libs-0.9.0-1.el9.x86_64
We also advise setting an expiration for this lock, as it should be removed when a fix for this case is published. This will help ensure the lock does not cause conflicts later if it is not removed.
# echo "dnf versionlock delete libavif" | at now + 30 days
# echo "dnf versionlock delete svt-av1-libs" | at now + 30 days
Note: The at command requires the atd service to be running. If it is not, the scheduled removal will not run, and the version locks must be removed manually once the fix is published.
If this error occurred during a cPanel installation, you will also need to manually install the correct package version and rerun the EasyApache 4 profile deployment.
Important: If the wrong versions of libavif or svt-av1-libs from the EPEL repository are already installed, the commands below will fail with conflicts. Check the installed versions first:
# rpm -qa | grep -E 'libavif|svt-av1'
If libavif-1.1.1 (libavif.so.16), libavif0.10, or svt-av1-libs-2.3.0 (from EPEL) are installed, remove them before continuing. If you previously added version locks for these packages, remove those first:
# dnf versionlock delete libavif0.10
# dnf versionlock delete svt-av1-libs
# dnf remove libavif svt-av1-libs
Then install the correct version, lock the packages, and rerun the EasyApache 4 profile deployment:
# dnf install libavif-0.11.1-5.el9.x86_64
# dnf versionlock add libavif-0.11.1-5.el9.x86_64
# dnf versionlock add svt-av1-libs-0.9.0-1.el9.x86_64
# /usr/local/bin/ea_install_profile --install /etc/cpanel/ea4/profiles/cpanel/default.json
# dnf install cpanel-letsencrypt-v2
# /scripts/check_cpanel_pkgs
# /usr/local/cpanel/scripts/upcp
Note: After a failed cPanel installation, the alt-common repository may not be set up, so libavif-0.11.1-5.el9 will be unavailable ("No match for argument"). If this occurs, you must perform the following before the steps above.
If the alt-common repository is not installed, it can be set up by installing ImunifyAV first.
# wget https://repo.imunify360.cloudlinux.com/defence360/imav-deploy.sh -O imav-deploy.sh
# bash imav-deploy.sh
CloudLinux is also tracking this incident via the following status page:
Comments
0 comments
Article is closed for comments.