404 error trying to install EPEL

Latest response

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?

SC
Log in to join the conversation

Responses

Stephen Sadowski's picture Expert 955 points
8 October 2020 12:41 AM

what happens with a ping or traceroute?

You have 3 separate IPv4 addresses that it's trying; testing from US and EU, all 3 are reachable.

SC Community Member 57 points
8 October 2020 12:10 PM

Thanks for your response ... I'm not able to use ping nor traceroute for any of those IPs, but I don't think that's impacting any ability to reach them with other protocols. I was able to use dl.fedoraproject.org to install the EPEL repo (see my reply to Jan below), and I cannot ping nor traceroute to that host either.

Stephen Sadowski's picture Expert 955 points
8 October 2020 1:32 PM

That's fine, use curl:

$ curl "https://mirrors.fedoraproject.org/metalink?repo=epel-8.2&arch=x86_64&infra=$infra&content=$contentdir"

and see what happens. I'd bet it fails.

Stephen Sadowski's picture Expert 955 points
8 October 2020 1:51 PM

Scratch this - I didn't look close enough. 404's mean that it's at least reaching the hosts.

ir. Jan Gerrit Kootstra's picture Guru 11963 points
8 October 2020 7:25 AM

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

SC Community Member 57 points
8 October 2020 12:07 PM

Thanks for your response ... I used this command to, what I believe, set up the EPEL repo files:

$ sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
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.
Last metadata expiration check: 16:26:28 ago on Wed 07 Oct 2020 07:37:59 PM UTC.
epel-release-latest-8.noarch.rpm                                                       327 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!

So I am able to reach out to this fedoraproject.org site.

SM Guru 7011 points
8 October 2020 8:17 AM

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!

SC Community Member 57 points
8 October 2020 12:19 PM

Thanks for your response ... when I use the command referenced in your link:

$ sudo subscription-manager repos --enable "codeready-builder-for-rhel-8-x86_64-rpms"
This system has no repositories available through subscriptions.

I have to admit that I'm not sure what sort of subscription is associated with these Azure VMs ... I guess I assumed that if you're not using a BYOL model, the hourly rate paid to Microsoft includes the amount going back to Red Hat for the RHEL licensing.

Stephen Sadowski's picture Expert 955 points
8 October 2020 1:33 PM

in your epel install it says this:

This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.

so your system has no active subscriptions.

ir. Jan Gerrit Kootstra's picture Guru 11963 points
8 October 2020 12:48 PM

Hi Shawn,

I asked a fellow Red Hat user with very much Azure experience. He will tune in soon to answer your question about the RHEL subscriptions for Azure.

I have none at all.

Regards,

Jan Gerrit

SC Community Member 57 points
8 October 2020 12:57 PM

Thanks for that! :-)

SC Community Member 57 points
8 October 2020 1:05 PM

Not sure if this adds another dimension to the subscription question, but this Azure Marketplace image is provided by CIS (link), which provides images of many operating systems preconfigured to their security benchmarks. I believe a small amount of the hourly rate goes to CIS but the remainder to Microsoft, and they in turn pay Red Hat for the RHEL license. But still not sure to what that entitles you as far as RH subscriptions go.

All that aside, still getting the errors trying to reach EPEL mirror servers. :-\

Stephen Sadowski's picture Expert 955 points
8 October 2020 1:35 PM

CIS only provides the image, not the subscription - you'll need to link it to your subscription separately.

John T Mills's picture Active Contributor 115 points
8 October 2020 1:15 PM

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!

SC Community Member 57 points
8 October 2020 1:38 PM

Thanks for all the responses. I'm trying to connect with the group in my company that handles our use of Azure to confirm what our Microsoft and Red Hat licensing says about using these VMs. But I suspect that's not going to resolve the inability to reach an EPEL mirror server ... given this worked just two weeks ago with the same type of Marketplace Image, I assume something else is going on.

John T Mills's picture Active Contributor 115 points
8 October 2020 1:43 PM

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)
SC Community Member 57 points
8 October 2020 1:50 PM

Ah, OK. That's very helpful as it should indicate that it's not something that's changed with my company's IaaS networking.

I've found old posts on other discussion sites where people have covered this same issue, including this one (from 2015, I believe):

So there is a window in time when new updates have been published to the mirrors but the mirrormanager crawler has not gotten that information yet. We are working on getting that window smaller, but at the moment it is causing problems with EPEL. [EPEL consumers are the largest customer of mirrormanager so it shows up the most here.]

So it seems like it's an issue that does crop up occasionally which eventually sorts itself out. But it's been more than 48 hours since I first experienced the error and it's still going on. No idea if that's to be expected or not.

SL Community Member 30 points
13 October 2020 11:59 AM

Hi,

I'm facing the same issue right now , 10-13-2020.

Some suggestions?

SC Community Member 57 points
13 October 2020 1:57 PM

I'm not sure what is the issue. As a test, we deployed an Azure Centos VM and installing EPEL worked fine, but unfortunately, I don't have any other means of deploying an internet-facing RHEL VM (e.g., AWS) to test whether it really is Azure-specific or not.

In our case, the issue has become moot because we confirmed with our software vendor that EPEL really is not required. But if you are also trying to do this on Azure, I'd suggest opening up a support ticket with Microsoft, especially if you do have the means of trying this in a non-Azure deployment and it works there.

RJ Hinton's picture Guru 17936 points
13 October 2020 4:44 PM

John T Mills, and Stefano Leandro,

Are you facing EPEL access issues from an Azure instance, or just in general? I believe from your posts above John T Mills that you're facing this from Azure.

Please let us know so we can tailor our responses to your specific need,

Regards,
RJ

Christian Labisch's picture Guru 29025 points
13 October 2020 4:54 PM

Hi RJ,

John is talking about a specific Azure related issue, I believe ... generally EPEL works right as expected. :)
One of the main problems seems to be that the codeready-builder repository is missing in Azure images.

Regards,
Christian

SL Community Member 30 points
28 October 2020 8:54 PM

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

SL Community Member 30 points
28 October 2020 9:00 PM

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/$bas

earch 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/$basear

ch 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

RJ Hinton's picture Guru 17936 points
13 October 2020 7:53 PM

Thanks, Christian. I mentioned I suspected that was John's angle. I'm curious about Stefano's scenario.

Regards,
RJ

John T Mills's picture Active Contributor 115 points
13 October 2020 8:09 PM

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
RJ Hinton's picture Guru 17936 points
13 October 2020 8:38 PM

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

Stephen Sadowski's picture Expert 955 points
13 October 2020 8:44 PM

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.

AC Newbie 14 points
7 July 2021 2:58 AM

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.

John T Mills's picture Active Contributor 115 points
13 October 2020 10:31 PM

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.

RJ Hinton's picture Guru 17936 points
13 October 2020 8:42 PM

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

SC Community Member 57 points
13 October 2020 8:54 PM

Though (as I mentioned above) I started this thread, I no longer have a "horse in this race" as our vendor confirmed we really don't need EPEL after all. But if we did still need this, I would have thought the next step would be to open a ticket to Microsoft (specifically to the Azure compute team), but in retrospect, it looks like the image in the Marketplace was published by Red Hat. We're actually using the RHEL images provided by CIS, but I assume they start with Red Hat's image when creating theirs (and as pointed out, Red Hat's own image is doing the same thing).

RJ Hinton's picture Guru 17936 points
13 October 2020 9:24 PM

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

SL Community Member 30 points
28 October 2020 9:05 PM

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/$bas

earch 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/$basear

ch 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

Stephen Sadowski's picture Expert 955 points
28 October 2020 9:56 PM

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'}
SL Community Member 30 points
28 October 2020 9:58 PM

There we go : {'arch': 'x86_64', 'basearch': 'x86_64', 'releasever': '8'}

It looks identical

So i have to remove in the repo conf .2?

Stephen Sadowski's picture Expert 955 points
28 October 2020 10:04 PM

Yes, but what's happening should not happen at all. For some reason dnf is substituting '8.2' in the $releasever variable where it should be just substituting '8'

SL Community Member 30 points
28 October 2020 10:24 PM

Super tnx ... you know what : http://mirrors.ucr.ac.cr/epel/8/Everything/

I'm using this one for the moment and i installed htop ;) ty

RV Newbie 10 points
29 October 2020 7:25 PM

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?

Stephen Sadowski's picture Expert 955 points
29 October 2020 7:38 PM

I do not believe it has. Who is responsible for RHEL support for an azure image? Azure?

I know on AWS, they are responsible for the RHEL images/instances that are not BYOL. I'm pretty sure it's the same for azure, but not 100%.

Akemi Yagi's picture Guru 3698 points
29 October 2020 8:54 PM

I ping'ed someone, who then ping'ed a person who is responsible for RHEL support for azure.

Jim Perrin's picture Community Member 42 points
30 October 2020 9:49 PM

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.

RV Newbie 10 points
9 November 2020 1:51 PM

It seems you're right, thanks!

Documentation in Azure marketplace could've been better though.

SC Community Member 57 points
9 November 2020 2:44 PM

We were using an image I believe was "derived" from a RH one; in our case, those provided by CIS. So we'd be dependent on them starting with the correct one to build their own. :-\

AM Newbie 5 points
3 December 2020 6:52 PM

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.

LM Newbie 5 points
6 May 2021 12:02 PM

Same problem, RHEL 8.2 on Azure.

Fixed executing:

sed -i.bak 's/\$releasever/8/g' /etc/yum.repos.d/epel*.repo
FD Newbie 5 points
10 May 2021 9:25 PM

Worked for me as well. Tks!

CB Newbie 10 points
24 May 2021 6:06 PM

This also worked for me on Red Hat 8.3 running in Azure. Thanks!

CB Newbie 10 points
24 May 2021 6:05 PM

This also worked for me on Red Hat 8.3 running in Azure. Thanks!

JC Red Hat Pro 482 points
8 June 2021 2:02 PM

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
RJ Hinton's picture Guru 17936 points
8 June 2021 2:56 PM

Thanks much John!

Regards,
RJ