Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
N/A
-
None
Description
We received a few reports of MariaDB upgrades failing, for example:
|
Show all |
# /usr/bin/yum update
|
Loaded plugins: fastestmirror, universal-hooks
|
Loading mirror speeds from cached hostfile
|
epel/x86_64/metalink | 22 kB 00:00:00
|
* EA4: 63.247.64.58
|
* cpanel-addons-production-feed: 63.247.64.58
|
* cpanel-plugins: 63.247.64.58
|
* base: centos.mirror.vexxhost.com
|
* epel: mirror.dst.ca
|
* extras: centos.mirror.vexxhost.com
|
* updates: centos.mirror.vexxhost.com
|
EA4 | 2.9 kB 00:00:00
|
cpanel-addons-production-feed | 2.9 kB 00:00:00
|
cpanel-plugins | 2.9 kB 00:00:00
|
https://archive.mariadb.org/mariadb-10.3/yum/centos/7/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found
|
Trying other mirror.
|
To address this issue please refer to the below wiki article
|
|
|
https://wiki.centos.org/yum-errors
|
|
|
If above article doesn't help to resolve this issue please use https://bugs.centos.org/.
|
|
|
|
|
|
One of the configured repositories failed (MariaDB103),
|
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=MariaDB103 ...
|
|
|
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 MariaDB103
|
or
|
subscription-manager repos --disable=MariaDB103
|
|
|
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=MariaDB103.skip_if_unavailable=true
|
|
|
failure: repodata/repomd.xml from MariaDB103: [Errno 256] No more mirrors to try.
|
https://archive.mariadb.org/mariadb-10.3/yum/centos/7/x86_64/repodata/repomd.xml: [Errno 14] HTTPS Error 404 - Not Found
|
We also saw the issue was with archive.mariadb.org specifically as well (it was showing as empty):
# curl https://archive.mariadb.org/
|
<html>
|
<head><title>404 Not Found</title></head>
|
<body>
|
<center><h1>404 Not Found</h1></center>
|
<hr><center>nginx</center>
|
</body>
|
</html>
|
/</h1>
|
<table id="list"><thead><tr><th style="width:55%"><a href="?C=N&O=A">File Name</a> <a href="?C=N&O=D"> ↓ </a></th><th style="width:20%"><a href="?C=S&O=A">File Size</a> <a href="?C=S&O=D"> ↓ </a></th><th style="width:25%"><a href="?C=M&O=A">Date</a> <a href="?C=M&O=D"> ↓ </a></th></tr></thead>
|
<tbody></tbody></table></body></html>%
|
\
|
This can cause unintended database outages and we received about 4 reports in a small time frame. Is there any way to know what may have occurred with the archive.mariadb.org repo (around 12 PM CST Dec 11 2022)?
