404 error trying to install EPEL
I've provisioned a RHEL 8 VM in Microsoft Azure IaaS and am trying to install EPEL. I've successfully configured the repo with the command:
$ sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
$ rpm -qa | grep -i epel
epel-release-8-8.el8.noarch
And I can see the multiple EPEL-related files added to the /etc/yum.repos.d folder:
$ ls -l /etc/yum.repos.d/
total 32
-rw-r--r--. 1 root root 1167 Dec 18 2019 epel-modular.repo
-rw-r--r--. 1 root root 1249 Dec 18 2019 epel-playground.repo
-rw-r--r--. 1 root root 1104 Dec 18 2019 epel.repo
-rw-r--r--. 1 root root 1266 Dec 18 2019 epel-testing-modular.repo
-rw-r--r--. 1 root root 1203 Dec 18 2019 epel-testing.repo
-rw-r--r--. 1 root root 358 Aug 4 07:39 redhat.repo
-rw-r--r--. 1 root root 4371 Jul 1 06:53 rh-cloud-rhel8-eus.repo
However, it appears that none of the mirrors hosting EPEL can be reached:
$ sudo yum upgrade *
Extra Packages for Enterprise Linux Modular 8.2 - x86_64 162 kB/s | 67 kB 00:00
Errors during downloading metadata for repository 'epel-modular':
- Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 38.145.60.21)
- Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 8.43.85.67)
- Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 38.145.60.20)
Error: Failed to download metadata for repo 'epel-modular': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 38.145.60.21)
Extra Packages for Enterprise Linux 8.2 - x86_64 93 kB/s | 67 kB 00:00
Errors during downloading metadata for repository 'epel':
- Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 67.219.144.68)
- Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 38.145.60.21)
Error: Failed to download metadata for repo 'epel': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 67.219.144.68)
Red Hat Enterprise Linux 8 for x86_64 - BaseOS - Extended Update Support from RHUI (RP 17 MB/s | 21 MB 00:01
Red Hat Enterprise Linux 8 for x86_64 - AppStream - Extended Update Support from RHUI 15 MB/s | 19 MB 00:01
Microsoft Azure RPMs for RHEL8 Extended Update Support 6.8 kB/s | 1.5 kB 00:00
Ignoring repositories: epel-modular, epel
Dependencies resolved.
Nothing to do.
Complete!
$ dnf --disablerepo="*" --enablerepo="epel" list available
Extra Packages for Enterprise Linux 8.2 - x86_64 190 kB/s | 67 kB 00:00
Errors during downloading metadata for repository 'epel':
- Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 38.145.60.20)
- Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 38.145.60.21)
- Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 8.43.85.73)
Error: Failed to download metadata for repo 'epel': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 38.145.60.21)
This VM has direct access to the internet so it is unlikely any sort of proxy or other network issue. And I've successfully done this recently, so is this an indication of a temporary issue with the EPEL mirrors? If so, typically how long does this condition typically persist?
Responses
Hi Shawn,
You where able to install the EPEL release rpm or did you copy the repo files manually?
In case of the the rpm install over the internet than you can exclude a mirror issue at the time of install, because the rpm you download from one of the mirrors.
So it could be one mirror being down.
Regards,
Jan Gerrit
Hello Shawn,
Adding to the statements above:
The "epel" would have dependency on "codeready-builder", hence, make sure to enable this as well https://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
All the best!
Shawn,
When generating a RHEL8 instance in azure from the Marketplace images you will get access to the following repos, but the non-debug and non-source will be disabled by default.
/etc/yum.repos.d/rh-cloud-rhel8-eus.repo:
[rhel-8-for-x86_64-baseos-eus-rhui-debug-rpms]
[rhel-8-for-x86_64-baseos-eus-rhui-rpms]
[rhel-8-for-x86_64-baseos-eus-rhui-source-rpms]
[rhel-8-for-x86_64-appstream-eus-rhui-debug-rpms]
[rhel-8-for-x86_64-appstream-eus-rhui-rpms]
[rhel-8-for-x86_64-appstream-eus-rhui-source-rpms]
From yum output (default enabled):
Red Hat Enterprise Linux 8 for x86_64 - BaseOS - Extended Update Support from RHUI (RPMs)
Red Hat Enterprise Linux 8 for x86_64 - AppStream - Extended Update Support from RHUI (RPMS)
Microsoft Azure RPMs for RHEL8 Extended Update Support
The good news is that some of the CodeReady packages have been moved into AppStream on RHEL8. (ant for instance)
# yum provides ant
...
ant-1.10.5-1.module+el8+2438+c99a8a1e.noarch : Java build tool
Repo : rhel-8-for-x86_64-appstream-eus-rhui-rpms
Matched from:
Provide : ant = 1.10.5-1.module+el8+2438+c99a8a1e
The bad news is that the CodeReady repository for RHEL8-x86_64 is about 2G in size currently (2995 rpms). If you are missing a package that wasn't moved into AppStream, you will need to obtain it from a Red Hat CodeReady repository.
The best option for enabling repositories outside of what Microsoft provides is to start a demo with Red Hat and register the VM to the Red Hat channels. Request a RHEL Evaluation
Best of luck!
I can confirm epel isnt working for my 8.2 marketplace image, as well.
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/dnf/repo.py", line 573, in load
ret = self._repo.load()
File "/usr/lib64/python3.6/site-packages/libdnf/repo.py", line 394, in load
return _repo.Repo_load(self)
RuntimeError: Failed to download metadata for repo 'epel-modular': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 152.19.134.142)
Hi ,sorry for delay. I've my REHL 8 on east us 2 where the EPEL still dont work at today returing 404 .... I have another RHEL 8 on east us and it works Now im getting back and checking everything also this forum :)
Ok this what i got again : [root@osmae2awe001 yum.repos.d]# dnf update Updating Subscription Management repositories. Unable to read consumer identity This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Extra Packages for Enterprise Linux Modular 8.2 67 kB/s | 67 kB 00:00 Errors during downloading metadata for repository 'epel-modular': - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 8.43.85.67) - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 140.211.169.196) - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 8.43.85.73) Error: Failed to download metadata for repo 'epel-modular': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 8.43.85.67)
This is my repo conf : [root@osmae2awe001 yum.repos.d]# ls -lrt total 32 -rw-r--r--. 1 root root 1203 Dec 18 2019 epel-testing.repo -rw-r--r--. 1 root root 1266 Dec 18 2019 epel-testing-modular.repo -rw-r--r--. 1 root root 1249 Dec 18 2019 epel-playground.repo -rw-r--r--. 1 root root 4371 Jul 1 06:53 rh-cloud-rhel8-eus.repo -rw-r--r--. 1 root root 358 Aug 4 07:39 redhat.repo -rw-r--r--. 1 root root 1104 Oct 28 20:57 epel.repo -rw-r--r--. 1 root root 1167 Oct 28 20:57 epel-modular.repo [root@osmae2awe001 yum.repos.d]#
[epel] name=Extra Packages for Enterprise Linux $releasever - $basearch
baseurl=https://download.fedoraproject.org/pub/epel/$releasever/Everything/$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever&arch=$ basearch&infra=$infra&content=$contentdir enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
epel-modular] name=Extra Packages for Enterprise Linux Modular $releasever - $basearch
baseurl=https://download.fedoraproject.org/pub/epel/$releasever/Modular/$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-modular-$releaseve r&arch=$basearch&infra=$infra&content=$contentdir enabled=1 gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
It looks to still be an issue using the RHEL 8.2 w/ LVM Gen 1 image in Azure, at the very least.
[root@rhel82 ~]# dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
Red Hat Enterprise Linux 8 for x86_64 - BaseOS - Extended Update Support from RHUI (RPMs) 39 MB/s | 21 MB 00:00
Red Hat Enterprise Linux 8 for x86_64 - AppStream - Extended Update Support from RHUI (RPMs) 42 MB/s | 19 MB 00:00
Microsoft Azure RPMs for RHEL8 Extended Update Support 3.6 kB/s | 1.5 kB 00:00
epel-release-latest-8.noarch.rpm 140 kB/s | 22 kB 00:00
Dependencies resolved.
===============================================================================================================================================================================================================================================================================
Package Architecture Version Repository Size
===============================================================================================================================================================================================================================================================================
Installing:
epel-release noarch 8-8.el8 @commandline 22 k
Transaction Summary
===============================================================================================================================================================================================================================================================================
Install 1 Package
Total size: 22 k
Installed size: 32 k
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : epel-release-8-8.el8.noarch 1/1
Running scriptlet: epel-release-8-8.el8.noarch 1/1
Verifying : epel-release-8-8.el8.noarch 1/1
Installed products updated.
Installed:
epel-release-8-8.el8.noarch
Complete!
[root@rhel82 ~]# yum upgrade
Extra Packages for Enterprise Linux Modular 8.2 - x86_64 42 kB/s | 67 kB 00:01
Errors during downloading metadata for repository 'epel-modular':
- Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 140.211.169.206)
- Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 152.19.134.142)
Error: Failed to download metadata for repo 'epel-modular': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 140.211.169.206)
Repos work fine once you remove the Epel repos.
[root@rhel82 ~]# rpm -e epel-release
[root@rhel82 ~]# yum upgrade
Last metadata expiration check: 0:04:02 ago on Tue 13 Oct 2020 08:03:03 PM UTC.
Dependencies resolved.
=========================================================================================================
Package Arch Version Repository Size
=========================================================================================================
Installing:
kernel x86_64 4.18.0-193.19.1.el8_2 rhel-8-for-x86_64-baseos-eus-rhui-rpms 2.8 M
kernel-core x86_64 4.18.0-193.19.1.el8_2 rhel-8-for-x86_64-baseos-eus-rhui-rpms 28 M
kernel-modules x86_64 4.18.0-193.19.1.el8_2 rhel-8-for-x86_64-baseos-eus-rhui-rpms 24 M
...
Seems like something is wonky.
Error: Failed to download metadata for repo 'epel-modular': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 152.19.134.198)
[root@rhel82 ~]# ping 152.19.134.198
PING 152.19.134.198 (152.19.134.198) 56(84) bytes of data.
64 bytes from 152.19.134.198: icmp_seq=1 ttl=46 time=24.1 ms
64 bytes from 152.19.134.198: icmp_seq=2 ttl=46 time=24.3 ms
^C
Hi John T. Mills.
What do you suspect is your next step in this? From what I can tell, this seems to be Azure-related? however, I see "EUS' in the repo. That generally means "Red Hat Extended Update Service". Are there repositories you can pick that are not EUS for baseos?
Regards,
RJ
RJ - it may not be Azure related, it looks like there are two variables ($infra, $contentdir) that are not getting properly substituted when yum/dnf update is getting run. I wonder if that's a problem in the .repo file.
If I curl the link, I get this little tidbit from the metalink script:
# repo = epel-modular-8.2 arch = x86_64 error: invalid repo or arch
But going through the list, the following is interesting:
# repo=epel-modular-8&arch=x86_64
So I think this probably is an issue with the .repo file.... I'm going to try and stand up a VM and duplicate this evening.
After a LOT of searching I have found this thread. I am having similar issues, and this is the closest thread I found to my issue. In particular Stephen's comment regarding the vars not being substituted correctly. I am using a fresh install of RHEL 8.3 with our own local repos. These repos are using user defined variables that are in /etc/dnf/vars. YUM is correctly using these variables until it is time to download metadata. As an example I can install am RPM that we will have in our local repo, "yum -y install filebeat" it installs, you get a message "Installed products updated" followed by a message "Error during downloading metadata for repository " "Status code: 404 for http:///artifactory//release/$releasemajor/repodata/repomd.xml" in this case releasemajor is our local variable that is "el8". The variable is obviously substituted correctly during the install as it is installed, it is just lost during the metadata download phase. I will get the same error if I "yum erase filebeat" as well. If I edit our repo file remove the variable and hard code "el8" no errors occur. This is a easy work around, however we do have some other variable for a username and password for private repos we can not hard code to the repo file. We do not have this issue with the same repo on RHEL7, this however is using Python 2.7. Apologies that I can not upload screen output as I am on a closed "air gapped" network.
Microsoft and Red Hat have an interesting agreement in place. Microsoft hosts a RHUI service with many repos. If you buy a pay-as-you-go (PAYG) licensed virtual machine from MS Azure, then it automatically has *.repo definitions to the RHUI repositories that you are paying for. This RHEL8.2 w/ LVM, Gen 1 image is hard-coded to EUS repositories. Another image will be E4S and another still will be standard. I've raised some concerns in the past, as many Red Hat experts will agree, a RHEL license is entitled to more repositories than BaseOS and AppStream. This virtual machine OS sku does not provide them. It's challenging as you may discover that RHEL8.3 w/ LVM Gen 1 or RHEL 8.2 w/ LVM Gen 2 provide different repositories. I am not saying that is the case, but it is always a possibility. It's the first thing I look at when evaluating a RHEL PAYG image in the marketplace.
John T. Mills,
Something I do for disconnected satellites where we need EPEL - I gather EPEL for my systems and present on disconnected networks. Perhaps this may be a work-around (very temporary). Also, examine the repo you have that from your output happens to be named "epel-modular".
Regards,
RJ
John T Mills, please see the response by Stephen Sadowski above. Also, examine your repositories in /etc/yum.repos.d/ directory for sanity. Also, I'm curious about what I wrote in a previous post where I mentioned "EUS" and evaluating your repositories as needed, just in case.
Regards,
RJ
Ok this what i got again :
[root@osmae2awe001 yum.repos.d]# dnf update Updating Subscription Management repositories. Unable to read consumer identity This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Extra Packages for Enterprise Linux Modular 8.2 67 kB/s | 67 kB 00:00 Errors during downloading metadata for repository 'epel-modular': - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 8.43.85.67) - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 140.211.169.196) - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 8.43.85.73) Error: Failed to download metadata for repo 'epel-modular': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-modular-8.2&arch=x86_64&infra=$infra&content=$contentdir (IP: 8.43.85.67)
This is my repo conf : [root@osmae2awe001 yum.repos.d]# ls -lrt total 32 -rw-r--r--. 1 root root 1203 Dec 18 2019 epel-testing.repo -rw-r--r--. 1 root root 1266 Dec 18 2019 epel-testing-modular.repo -rw-r--r--. 1 root root 1249 Dec 18 2019 epel-playground.repo -rw-r--r--. 1 root root 4371 Jul 1 06:53 rh-cloud-rhel8-eus.repo -rw-r--r--. 1 root root 358 Aug 4 07:39 redhat.repo -rw-r--r--. 1 root root 1104 Oct 28 20:57 epel.repo -rw-r--r--. 1 root root 1167 Oct 28 20:57 epel-modular.repo [root@osmae2awe001 yum.repos.d]#
[epel] name=Extra Packages for Enterprise Linux $releasever - $basearch
baseurl=https://download.fedoraproject.org/pub/epel/$releasever/Everything/$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-$releasever&arch=$ basearch&infra=$infra&content=$contentdir enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
epel-modular] name=Extra Packages for Enterprise Linux Modular $releasever - $basearch
baseurl=https://download.fedoraproject.org/pub/epel/$releasever/Modular/$basearch metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-modular-$releaseve r&arch=$basearch&infra=$infra&content=$contentdir enabled=1 gpgcheck=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-8
The epel.conf file is still wrong.
epel-modular-8.2 doesn't exist, it's epel-modular-8, I am not sure why 8.2 is getting substituted for $releasever here.
can you run this:
/usr/bin/python3 -c 'import dnf, json; dnf_db = dnf.dnf.Base(); print(dnf_db.conf.substitutions)'
and paste the output here? On my rhel8.2 box I get:
{'arch': 'x86_64', 'basearch': 'x86_64', 'releasever': '8'}
I have the same issue, using the RHEL 8 LVM gen1 image.
I can confirm that the issue is with the parameter substitution in yum. Replacing "$releasever" by "8" in the URL does the trick but is merely a workaround. Has this bug been reported?
Okay, so I've done a bit of digging on this one, and I think I know what's happened. Can I safely assume that you created this image from the azure web portal and chose the "Red Hat Enterprise Linux 8.2 (LVM)" image listed there?
If that's the case, then you used an image which is incompatible with EPEL. Instead of using that, you'd want to use one of the images from the gallery titled "Red Hat Enterprise Linux 8 (latest minor version)". If you use one of these images, then EPEL works just fine with no modifications.
I have run into this issue as well. $releasever is being used in the epel repo configuration (/etc/yum.repos.d/epel*.repo) which SHOULD be returning 8 but is instead returning 8.1. This seems to be part of the Microsoft modifications to their Azure images. I modified those files to just use "-8" instead of "-$releasever" and the problem is resolved.
Same problem, RHEL 8.2 on Azure.
Fixed executing:
sed -i.bak 's/\$releasever/8/g' /etc/yum.repos.d/epel*.repo
EPEL 8 contains the $releasever
variable. The default value is 8, but with systems that have release locked via /etc/yum/vars/releasever
to anything other than 8, you will encounter a 404 error.
We can workaround this by replacing the $releasever variable with 8.
# sed -i 's/$releasever/8/g' /etc/yum.repos.d/epel*.repo