[SOLVED] One of the configured repositories failed (Unknown)

[dalepres]

I just installed a new Centos 7 on VirtualBox - minimal install. The first thing I did was yum update kernel which worked fine. I rebooted and tried to yum repolist and get this error. Even yum update kernel or any other yum command gets the same result. I've done clean all, rebooted, clean all again, etc., etc.

[root@dphdp851 yum.repos.d]# yum repolist
Loaded plugins: fastestmirror
base | 3.6 kB 00:00:00

epel/x86_64/metalink | 5.7 kB 00:00:00
extras | 3.4 kB 00:00:00
updates | 3.4 kB 00:00:00
Loading mirror speeds from cached hostfile
* base: centos.unixheads.org
* epel: ewr.edge.kernel.org
* extras: mirror.oss.ou.edu
* updates: ftpmirror.your.org


One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:

1. Contact the upstream for the repository and get them to fix the problem.

2. Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).

3. Disable the repository, so yum won't use it by default. Yum will then
just ignore the repository until you permanently enable it again or use
--enablerepo for temporary usage:

yum-config-manager --disable <repoid>

4. Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:

yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

file is encrypted or is not a database

Any suggestions?

[avij]

This seems to be a problem with the EPEL repository. Try yum with --disablerepo=epel\* until they get this fixed.

[avij]

There was a broken primary.sqlite.bz2 at some point, but it has been fixed now. The fixed file is being synced to mirrors. If you don't have an immediate need to get packages from EPEL, use yum with --disablerepo=epel until your local mirror syncs. yum clean all may or may not help, depending on which mirror you hit.

[dalepres]

Thanks. It's working this morning. This is an interesting problem I hadn't considered. I have a few questions; please understand that it is just in the interest of understanding and learning what to do.

So I was unable to do anything with yum because one, more, or all mirrors for a repo get corrupted. Does this mean that an upstream repo error can effectively shutdown anything yum related, even on other repos, globally?

What are the standard workarounds?

You answered that this was likely the epel repo. How did you determine that from the error message? I couldn't figure it out to know which repo to try to disable.

If I did need epel (and I did but I was just doing some home lab stuff - no money was lost, no businesses were shut down and no VMs were harmed) what do experts (I'm not one) do?

This happened abruptly and was fixed fairly quick so is the answer, if you need epel, to just wait? Or maybe have a local copy of the epel repo but keep it behind by a couple of versions?

Thanks for taking the time to help.

[dalepres]

One more question, is there a bug to be reported here that yum was unable to report which repo failed? It seems that there would have been some context at the point of failure for knowing which repo it was.

[stevemowbray]

You can put

Code: Select all

skip_if_unavailable=1

in the repo file. I do this for all third party repos.

[skoltogyan]

CentOS7 at this morning i see:

Code: Select all

# yum check-update --verbose
Loading "fastestmirror" plugin
Config time: 0.014
Yum version: 3.4.3
rpmdb time: 0.000
Building updates object
Setting up Package Sacks
base                                                                                                   | 3.6 kB  00:00:00     
epel/x86_64/metalink                                                                                   |  17 kB  00:00:00     
Using older repomd.xml
  Latest: Fri May 11 08:41:21 2018
  Using: Fri May 11 03:14:59 2018
epel                                                                                                   | 4.7 kB  00:00:00     
extras                                                                                                 | 3.4 kB  00:00:00     
influxdb                                                                                               | 2.5 kB  00:00:00     
nginx                                                                                                  | 2.9 kB  00:00:00     
updates                                                                                                | 3.4 kB  00:00:00     
Loading mirror speeds from cached hostfile
 * base: centos.colocall.net
 * epel: epel.besthosting.ua
 * extras: mirror.besthosting.ua
 * updates: centos.colocall.net


 [b]One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. [/b]There are a few ways to work "fix" this:

About current version:

Code: Select all

# cat /etc/*elease
CentOS Linux release 7.4.1708 (Core) 
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"

CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

CentOS Linux release 7.4.1708 (Core) 
CentOS Linux release 7.4.1708 (Core) 

Please, help me.

Serg

[edit/avij: merged these two topics]

[toracat]

I know EPEL had a problem earlier but it's been corrected. Run "yum clean all" and try it again.

[TimL]

Some mirrors still have issues.
what worked for me was commenting the "metalink", and un-commenting the "baseurl" in /etc/yum.repos.d/epel.repo

specifically

Code: Select all

> date
Fri May 11 10:01:49 EDT 2018

> yum clean all
Loaded plugins: fastestmirror, langpacks
Cleaning repos: base epel extras nux-dextop updates
Cleaning up everything
Maybe you want: rm -rf /var/cache/yum, to also free up space taken by orphaned data from disabled or removed repos
Cleaning up list of fastest mirrors

> yum -y upgrade
Loaded plugins: fastestmirror, langpacks
base                                                                                                              | 3.6 kB  00:00:00     
epel/x86_64/metalink                                                                                              | 7.6 kB  00:00:00     
epel                                                                                                              | 4.7 kB  00:00:00     
extras                                                                                                            | 3.4 kB  00:00:00     
nux-dextop                                                                                                        | 2.9 kB  00:00:00     
updates                                                                                                           | 3.4 kB  00:00:00     
(1/8): base/7/x86_64/group_gz                                                                                     | 166 kB  00:00:00     
(2/8): base/7/x86_64/primary_db                                                                                   | 5.9 MB  00:00:00     
(3/8): epel/x86_64/group_gz                                                                                       |  84 kB  00:00:00     
(4/8): epel/x86_64/updateinfo                                                                                     | 921 kB  00:00:00     
(5/8): extras/7/x86_64/primary_db                                                                                 | 104 kB  00:00:00     
(6/8): epel/x86_64/primary_db                                                                                     | 1.6 MB  00:00:00     
(7/8): nux-dextop/x86_64/primary_db                                                                               | 1.7 MB  00:00:01     
(8/8): updates/7/x86_64/primary_db                                                                                | 1.0 MB  00:00:15     
Determining fastest mirrors
 * base: ftpmirror.your.org
 * epel: mirror.steadfast.net
 * extras: ftpmirror.your.org
 * nux-dextop: li.nux.ro
 * updates: ftpmirror.your.org


 One of the configured repositories failed (Unknown),
 and yum doesn't have enough cached data to continue. At this point the only
 safe thing yum can do is fail. There are a few ways to work "fix" this:

     1. Contact the upstream for the repository and get them to fix the problem.

     2. Reconfigure the baseurl/etc. for the repository, to point to a working
        upstream. This is most often useful if you are using a newer
        distribution release than is supported by the repository (and the
        packages for the previous distribution release still work).

     3. Run the command with the repository temporarily disabled
            yum --disablerepo=<repoid> ...

     4. Disable the repository permanently, so yum won't use it by default. Yum
        will then just ignore the repository until you permanently enable it
        again or use --enablerepo for temporary usage:

            yum-config-manager --disable <repoid>
        or
            subscription-manager repos --disable=<repoid>

     5. Configure the failing repository to be skipped, if it is unavailable.
        Note that yum will try to contact the repo. when it runs most commands,
        so will have to try and fail each time (and thus. yum will be be much
        slower). If it is a very temporary problem though, this is often a nice
        compromise:

            yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true

file is encrypted or is not a database

> find /var/cache/yum/x86_64/7/ -iname '*.sqlite' | xargs file
/var/cache/yum/x86_64/7/base/gen/primary_db.sqlite:       SQLite 3.x database
/var/cache/yum/x86_64/7/nux-dextop/gen/primary_db.sqlite: SQLite 3.x database
/var/cache/yum/x86_64/7/updates/gen/primary_db.sqlite:    SQLite 3.x database
/var/cache/yum/x86_64/7/epel/gen/primary_db.sqlite:       data
/var/cache/yum/x86_64/7/extras/gen/primary_db.sqlite:     SQLite 3.x database

> grep epel /var/cache/yum/x86_64/7/timedhosts* 
fedora-epel.mirrors.tds.net 5280347 0 1507522651
epel.mirror.constant.com 0.0208718776703

And on an identical working server that happened to get different ping times;

Code: Select all

> grep epel /var/cache/yum/x86_64/7/timedhosts*
fedora-epel.mirror.lstn.net 8886731 0 1514869786
fedora-epel.mirror.lstn.net 0.0246088504791
fedora-epel.mirrors.tds.net 0.0198471546173

[avij]

It's true that yum's output could have been clearer in this case. Perhaps there is already a related bug entry at bugzilla.redhat.com, I haven't looked. This would need to be fixed in RHEL first.

I happened to be on Freenode channel #epel when someone complained about this issue, but if this had happened to me, I could have enabled one repository at a time (with --disablerepo=\* and --enablerepo=somerepo) to find which repo caused the trouble.

skip_if_unavailable=1 for non-critical repos sounds like a good idea.

Many people need only a few packages from EPEL. One option would be to import the EPEL packages you need to some locally controlled repository and use that instead. createrepo is related to this.