The 'Could not retrieve mirrorlist' error on CentOS 7 typically indicates that the Yum package manager cannot resolve the DNS names for the configured repository mirrors or cannot establish a network connection to them. This issue often arises during Zabbix agent installation when the system's network configuration is incorrect, the firewall blocks outbound traffic, or the repository metadata files are corrupted or outdated.
Understanding the Root Cause
When you run
yum install zabbix-agent, Yum reads the configuration files located in
/etc/yum.repos.d/. These files contain URLs pointing to various mirror sites. The error occurs because the underlying operating system fails to translate these domain names into IP addresses via DNS, or the network stack drops the packets before they reach the destination. This is distinct from HTTP errors like
404 Not Found; it is a lower-level connectivity or resolution failure. If you recently changed your network interface or moved the server to a different subnet, this error becomes highly probable.
Verifying Network Connectivity and DNS Resolution
The first step in troubleshooting is to ensure that the CentOS 7 host can actually reach the internet and resolve domain names. Open a terminal and test basic connectivity using the
ping command against a reliable public DNS server, such as Google's
8.8.8.8. If
ping returns packets successfully, your basic IP routing is functional. Next, test DNS resolution by pinging a hostname, such as
google.com. If the ping fails with "unknown host," your DNS settings are misconfigured. Check the
/etc/resolv.conf file to ensure it contains valid
nameserver entries. If the file is empty or contains invalid IPs, update it with your provider's DNS servers or use
8.8.8.8 and
1.1.1.1 as temporary fixes.
If DNS resolution works but
ping to external hosts fails, check your default gateway using
ip route show default. Ensure the gateway IP matches your network infrastructure. Additionally, verify that your network interface is active and has an IP address assigned using
ip addr show. A common oversight in virtualized environments is having the interface set to
down state. Bring it up with
ifup eth0 (replacing
eth0 with your actual interface name).
Checking Firewall and Proxy Settings
Even if DNS and routing are correct, local firewalls or corporate proxies can block Yum's access to repository mirrors. CentOS 7 uses
firewalld by default. Run
systemctl status firewalld to see if it is active. If enabled, ensure that the
http and
https services are allowed through the firewall. You can add these rules using
firewall-cmd --permanent --add-service=http followed by
firewall-cmd --reload.
If your environment requires a proxy to access the internet, Yum must be configured to use it. Edit the
/etc/yum.conf file and add lines for
proxy=http://your-proxy-server:port, along with
proxy_username and
proxy_password if authentication is required. Without these settings, Yum attempts a direct connection which will time out, resulting in the mirrorlist error. Note that if you are behind a strict corporate firewall, you may need to whitelist specific repository domains or allow all outbound HTTPS traffic.
Clearing Yum Cache and Verifying Repository Files
Sometimes the issue lies within Yum's local cache rather than network connectivity. Corrupted cache files can cause Yum to fail when retrieving metadata. Clear the cache by running
yum clean all. This command removes all cached data, including headers and packages, forcing Yum to download fresh metadata from the mirrors next time you run an install command. After cleaning, try installing the Zabbix agent again.
Inspect the repository files in
/etc/yum.repos.d/ to ensure they are correctly formatted and point to valid URLs. For Zabbix, look for
zabbix.repo. Verify that the
baseurl or
mirrorlist directives are not commented out and reference working endpoints. If you are using a custom internal mirror, ensure that the URL is accessible from the host. You can test the URL manually using
wget or
curl to see if it returns content. If the URL is invalid, update the repository file with the correct path provided by your Zabbix administrator.
For broader context on managing package issues, see our guide on
Centos 7 yum update issue - Troubleshooting Guide.
Frequently Asked Questions
Why does the error persist after fixing DNS?
If DNS resolution is confirmed working, the issue may be related to SSL certificate validation or proxy configurations. Ensure that your system clock is synchronized, as incorrect dates can cause SSL handshake failures with secure repositories. Additionally, verify that no intermediate proxy is intercepting and blocking the connection without proper credentials.
How do I disable SELinux temporarily to test?
SELinux policies can sometimes interfere with network applications, though rarely causing mirrorlist errors directly. To test if SELinux is the culprit, run
setenforce 0 to switch to permissive mode. If Yum starts working, check the audit logs with
ausearch -m avc for denials related to httpd or yum processes, then adjust your SELinux contexts accordingly.
Can I use a specific mirror instead of the mirrorlist?
Yes, you can bypass the mirrorlist mechanism by editing the
.repo file and replacing the
mirrorlist=... line with a static
baseurl=... pointing to a known good mirror. This eliminates the overhead of querying the list service and can resolve issues caused by unstable mirrorlist servers.
What should I do if I have multiple repo files conflicting?
Conflicting repository definitions can cause Yum to behave unpredictably. Identify duplicate or obsolete repo files in
/etc/yum.repos.d/ and rename them with a
.bak extension to disable them. Keep only the necessary repositories, such as the base OS repos and the specific Zabbix repo, to minimize potential conflicts during dependency resolution.
Is there a way to get more verbose output from Yum?
To gain deeper insight into why Yum is failing, run the command with the debug level flag:
yum --debuglevel=9 install zabbix-agent. This generates extensive logs showing every network request and DNS lookup attempt. Reviewing this output helps pinpoint whether the failure occurs at the DNS resolution stage, the TCP handshake, or the HTTP response phase.