Updating GCC on CentOS 6.2 - linux

today I was trying to update my gcc and after a search on internet I've found this article but I got stuck. I did what it says but got an error just like my other attempts. On my other attempts I was thinking the links must be broken but in this case this is a new article and I thought something is wrong on my computer. In that article I was just using the update part since I've already have GCC 4.4.6 . And my problem is at the first step :D . I typed sudo yum install svn texinfo-tex flex zip libgcc.i686 glibc-devel.i686 but here the terminal gives me the Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again I don't know what does that mean . Please don't make the question duplicate because I searched a lot but there is nothing about the error that I am getting. Thanks in advance.
Here is the /etc/yum.repos.d/epel.repo file as requested in the comments.
[epel]
name=Extra Packages for Enterprise Linux 6 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
[epel-debuginfo]
name=Extra Packages for Enterprise Linux 6 - $basearch - Debug
#baseurl=http://download.fedoraproject.org/pub/epel/6/$basearch/debug
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-debug- 6&arch=$basearch
failovermethod=priority
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
gpgcheck=1
[epel-source]
name=Extra Packages for Enterprise Linux 6 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/6/SRPMS
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=epel-source-6&arch=$basearch
failovermethod=priority
enabled=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-6
gpgcheck=1

Developer Toolset 2.0 http://linux.web.cern.ch/linux/devtoolset/
wget -O /etc/yum.repos.d/slc6-devtoolset.repo http://linuxsoft.cern.ch/cern/devtoolset/slc6-devtoolset.repo
You get gcc-4.8.1 : # yum install devtoolset-2-gcc-c++
64bits http://linuxsoft.cern.ch/cern/devtoolset/slc6X/x86_64/RPMS/
32bits http://linuxsoft.cern.ch/cern/devtoolset/slc6X/i386/RPMS/

Not 100% sure what you asking, but:
EPEL
There is RPM that installs EPEL repo. Here is the link:
rpm -i http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
Prior install, you need to remove the EPEL conf files you already applied.
Once installed, you need to do
yum update
and it will update whole system, including the gcc.
Note this update will not update CentOS to version 7 or something. It will only make all packages to last version - for example you will have last supported version of Apache webserver.
GCC
Second part of the question is about gcc - even in EPEL, gcc is bit old. My own C++11 code, never compiles.
You need to install something called redhat developer toolset 1.1:
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Developer_Toolset/1/html/1.1_Release_Notes/ch-Features.html
To install it you need to create file as follows:
cd /etc/yum.repos.d
wget http://people.centos.org/tru/devtools-1.1/devtools-1.1.repo
yum --enablerepo=testing-1.1-devtools-6 install devtoolset-1.1-gcc devtoolset-1.1-gcc-c++
This will install it most likely into /opt/centos/devtoolset-1.1/root/usr/bin/.
This repo will not update anything outside /opt/.
to use the compiler, you need to export following variables:
export CC=/opt/centos/devtoolset-1.1/root/usr/bin/gcc
export CPP=/opt/centos/devtoolset-1.1/root/usr/bin/cpp
export CXX=/opt/centos/devtoolset-1.1/root/usr/bin/c++
Sadly, even in this way, you can not get gcc 4.8, but gcc version is quite Ok. We were able to compile latest node.js with patching just one file, but we failed to compile latest TokuDB.
CLANG
Did you ever tried clang? Because CentOS not depends of clang, it is quite new version, even may supports C++14.
Hope this helps.
Source for gcc repo:
https://superuser.com/questions/381160/how-to-install-gcc-4-7-x-4-8-x-on-centos

Related

openSUSE 15.4 zypper error installing postgreSQL

I am new to Linux,
I installed openSUSE Leap 15.4, and made the root directory ext4, I then followed these steps to install postgreSQL 13 on my system
1.sudo zypper ref && sudo zypper update
sudo zypper addrepo https://download.postgresql.org/pub/repos/zypp/repo/pgdg-sles-15-pg13.repo
But after this, I sudo zypper ref again and it shows an error saying:
Retrieving repository 'PostgreSQL 13 SLES 15.4 - x86_64' metadata .....................................[error]
Repository 'PostgreSQL 13 SLES 15.4 - x86_64' is invalid.
[pgdg-13|https://download.postgresql.org/pub/repos/zypp/13/suse/sles-15.4-x86_64] Valid metadata not found at specified URL
History:
- [pgdg-13|https://download.postgresql.org/pub/repos/zypp/13/suse/sles-15.4-x86_64] Repository type can't be determined.
what can I do to install postgreSQL
I can't say precisely why your zypper command failed, but it might have to do with the fact that the repositories from your link are intended for SUSE Linux Enterprise 15 SP4, not for openSUSE Leap 15.4, which is what you're using. So even if you did get these repositories to work, you might run into other compatibility problems later.
To install postgresql, there is always the option to search for your package on software.opensuse.org. (I strongly recommend you bookmark this page – it's the place to look for openSUSE packages.) For postgresql13, there is indeed an official experimental package available for openSUSE 15.4, namely here, which you can install via 1-Click-Install. However, the newer version postgresql14 is already out for quite a while, so I would only advise for using the older postgresql13 if you have a very strong reason to do so. The newer postgresql14 also has an official experimental package available for openSUSE 15.4, namely here; this is the one I would recommend currently.
first check if repo is enabled zypper repos -d
check /etc/zypp/repos.d/pgdg-13.repo file
If you open the added repo file all set sles. but i think the main problem is the type=rpm-md. In any case you dont need add third part repo to install postgress. the package is already in the main repos and is called postgresql-server.
So remove the https://download.postgresql.org/pub/repos/zypp/repo/pgdg-sles-15-pg13.repo to prevent any other issues and package conflicts
zypper lr # to list the repos and find the number for the `https://download.postgresql.org/pub/repos/zypp/repo/pgdg-sles-15-pg13.repo`
zypper rr <number>
Then just install postgresql-server
Btw when you refresh the packages you dont need to run update

Linux Installation libX11-devel

I am trying to build QT4 (porting from Redhat 5 to 7 with an upgraded gcc compiler) in RedHat 7 and I was getting an error saying X11/Xlib.h can't be found. Anyways, after doing some research most people said to install libX11-devel to get those x11 libraries. Since I am using an offline machine I can't do "apt-get" type commands and have to manually install RPMs. So, I went to my RH-7 installation DVD and got "libX11-devel-1.6.3-3.el7.x86-64" (I have 64 bit OS) and tried to install using "yum install libX11-devel-1.6.3-3.el7.x86_64" and I am getting dependencies errors. It's saying
...Requires: pkgconfig(kbproto)
...Required: pkgconfig(xcb)
...Requires: pkgconfig(xproto)
...Requires: pkgconfig(xcb) >= 1.1.92
So, here are my questions.
1) when it says "pkgconfig(kbproto)", is it saying find the "kbproto....RPM" and do a "yum install". In my dvd I only have "xorg-x11-proto-devel-7.7.13.el7.noarch.rpm". Do I have to somehow find "xorg-x11-proto......x86_64.rpm" since it's a 64 bit machine?
2) Is there a difference between "yum install" and pkgconfig "install"? Are there any other installation variants in Linux?
3)For an offline machine, Is there anyway I can get all the dependencies and install everything at once ?
4) Why is it saying "xcb" requires twice. If I just get a xcb...rpm version above 1.1.92 can I just install it once?
Before actually answering the questions, I am going to suggest to see if you can get the latest version of the packages. The packages on the installation DVD may be really out of date and contain known vulernabilities, and other bugs. Can you use yumdownloader - in an online environment - to download the latest version onto a separate DVD and use that as the installation source? See https://access.redhat.com/solutions/10154 for more information.
To answer the questions themselves:
Requires: foo can refer to a package foo or a "feature" foo. pkgconfig(kbproto) is a "feature" (or virtual requires). You can use yum/rpm to see what provides this. On my Fedora box, for example, rpm -q --provides xorg-x11-proto-devel shows that this package indeed provides pkgconfig(kbproto).
As for x86_64 vs noarch, it doesn't matter. noarch packages work everywhere. Other packages are restricted to the platform. So x86_64 only works on intel/amd x86 64-bit machines. Installing noarch should be fine in your case. If you only had a i686 package, though, that wouldn't be sufficient. You would have to find a x86_64 or noarch package.
Yes, there's a big difference between yum and pkg-config. They do completely different things. One is a system tool for installing RPM packages. The other is a tool for developers for using the right headers and compiler flags. If your concern is finding/installing RPMs, do not use pkg-config directly.
Do you have access to an online machine that can access the RHEL 7 yum repositories? On that machine, do something like this:
mkdir rhel7-packages
cd rhel7-packages
yum provides '*/X11/Xlib.h' # make a note of the package that provides this file. it's libX11-devel on Fedora here
yumdownloader --resolve libX11-devel # download libX11-devel and all dependencies not installed on the system
Then copy/install the RPMs on the machine without internet access.
It's probably printing out xcb twice because it's two different requirements. The unversioned requirement will be satisfied if you install any verison of xcb. The versioned requirement will only be satisfied if you install 1.1.92. If you install 1.1.92, it will satisified both the requirements.
1.
You have to resolve the dependency on the system where you are building your package. This means you need to have those dependencies installed, inclusing libX11-devel. To do that, download the RPMs manually from EL7 repos to local disk and run this:
$ mkdir -p /tmp/libX11_dep_rpms && cd /tmp/libX11_dep_rpms
# Download all dependencies from here. All your packages should be available here:
# http://mirror.centos.org/centos-7/7/os/x86_64/Packages/
# Then install
$ yum localinstall *.rpm
# After this you should be able to build your qt4 package, provided all dependencies are resolved. Otherwise, repeat the procedure for all dependencies
# If you can't download packages, then you need to create a FULL DVD ISO that will contain all packages.
2.
pkgconfig ensures that a requirement is coming from a particular build that provides a particular version of the library. Here are some detail.
3.
Get the Everything ISO from EL7.
4.
This has to do with the pkgconfig and library versions.

Installing EPEL repository on Centos 7 breaks yum functionality? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
so I am trying to setup up a ssh bastion server, but I have problem setting up EPEL in order to install Python3.6.
I am using CentOS Linux release 7.4.1708 (Core)
So I am trying to install EPEL first by using
sudo yum -y install epel-release (I did of course sudo yum -y update before and it worked fine), but it told me Package 'epel-release' not found
Therefore I tried different approach using RedHat Package Manager:
sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
This installs package succesfully and I can see both epel.repo and epel-testing.repo in etc/yum.repos.d (I copy their contains at the end of post)
However, now, whenever I try to do something with yum, whether it is update or install of some package it gives me the following error (for example I used yum -y install Python3.6 or I have also tried installing tsclient or python-pip):
[root#scw-39016b yum.repos.d]# yum install -y Python3.6
Loaded plugins: fastestmirror
base | 3.6 kB 00:00
centos-kernel | 2.9 kB 00:00
epel/armhfp/metalink | 42 kB 00:00
Could not parse metalink https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=armhfp error was
No repomd file
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 /var/cache/yum/armhfp/7/epel/metalink.xml does not exist
I have tried million ways going around this already and nothing seems to help :(
I reinstalled it like 5 times, I have done sudo yum clean all, I have tried uncommenting baseurl and commenting metalink in repo files and other way too, etc..., but nothing helps :(
Can someone let me know, please, what is causing this error?
I read somewhere that it might do with enabling / disabling certain repositories, but I don't understand how to cope with it..
Many thanks !!!
epel.repo
[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel-debuginfo]
name=Extra Packages for Enterprise Linux 7 - $basearch - Debug
baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
epel-testing.repo
[epel-testing]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch
baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel7&arch=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel-testing-debuginfo]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch - Debug
baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch/debug
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-debug-epel7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel-testing-source]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch - Source
baseurl=http://download.fedoraproject.org/pub/epel/testing/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
We fixed this by updating curl. I believe yum uses libcurl under the hood, and it seems that older versions of curl cannot negotiate the TLS connection to the epel repo.
yum update curl --disablerepo=epel
You are using armhfp as your arch and there is no repo for it in the epel metalink you are looking at.
If you download the link below, you would get a file named, metalink. You will see that there is no repo that matches repo=epel-7&arch=armhfp. This is the source of your problem.
https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=armhfp
You need to use some other mirror that provides CentOS-7 support for armhfp arch.
e.g., http://mirror.centos.org/altarch/7/os/armhfp/
In order to use it, you need to remove epel-release RPM and install the following:
rpm -ivh http://mirror.centos.org/altarch/7/os/armhfp/Packages/centos-userland-release-7-4.1708.el7.centos.0.1.armv7hl.rpm
Then do a yum install for your package.
I had this issue on a VM. I just changed the metalink https access and set it at standard http like this :
metalink=http://mirrors.fedoraproject.org....
I came across your question when I was trying to install Python3 on my Raspberry Pi 3 (which is newly running CentOS 7). After some google-fu, I came across this site, which helped me get EPEL installed on armhfp.
This is what it says:
How can I enable EPEL 7 on armhfp ?
The answer is easy in a sense that there is no official EPEL
repository for armfhp. But because lot of users were asking for this,
we decided to use the centos armhfp builders to (re)build Source
packages from EPEL 7 (and try to track those automatically) when
they're idle. Please note that it's just an automatic rebuild without
any QA/test, and also resulting pkgs aren't signed either. To use that
repository, proceed like this :
cat > /etc/yum.repos.d/epel.repo << EOF
[epel]
name=Epel rebuild for armhfp
baseurl=https://armv7.dev.centos.org/repodir/epel-pass-1/
enabled=1
gpgcheck=0
EOF
After following these steps I was able to run sudo yum install epel-release successfully, and then install python3 on my raspberry pi.
Before you do this, however, you need to get yum working. I'm not sure I am the best help for that, but I would recommend removing (or at least disabling) the current versions of epel repos that you have.
yum remove epel
yum remove epel-release
yum remove epel-testing
It seems that you have a 3rd party repo enabled that is broken. This is causing your issues with yum and it's why you need to remove or disable the repos.
We have a very similar problem and I've seen several pleas for help with the most common response being "don't use 'https' but that exposes you to MITM attacks". There has to be a better answer.
We just did a fresh install of CentOS Linux release 7.7.1908 (Core) on a server and like the OP whenever we attempt sudo yum install epel-release, we break yum.
Here is the install:
-bash-4.2$ sudo yum install epel-release
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirrors.sonic.net
* extras: mirror.fileplanet.com
* updates: mirror.fileplanet.com
Resolving Dependencies
--> Running transaction check
---> Package epel-release.noarch 0:7-11 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
===================================================================================================================================================================================================================================
Package Arch Version Repository Size
===================================================================================================================================================================================================================================
Installing:
epel-release noarch 7-11 extras 15 k
Transaction Summary
===================================================================================================================================================================================================================================
Install 1 Package
Total download size: 15 k
Installed size: 24 k
Is this ok [y/d/N]: y
Downloading packages:
epel-release-7-11.noarch.rpm | 15 kB 00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Installing : epel-release-7-11.noarch 1/1
Verifying : epel-release-7-11.noarch 1/1
Installed:
epel-release.noarch 0:7-11
Complete!
Now if we even just try to run yum list it fails:
-bash-4.2$ yum list
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
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
Cannot retrieve metalink for repository: epel/x86_64. Please verify its path and try again
And here is /etc/yum.repos.d/epel.repo:
-bash-4.2$ cat epel.repo
[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
[epel-debuginfo]
name=Extra Packages for Enterprise Linux 7 - $basearch - Debug
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
So is the problem with the repository we're trying access or the fact that we are trying to access using the "https" protocol? If the former, how do I find the right repository? If the latter, how do we go about diagnosing the underlying problem? This is a pretty fresh install -- all we've really done is installed autos and mounted the home directory, installed rvm and created some users and groups.
FWIW, yum check-update doesn't report anything and yum update curl (with or without "--disablerepo=epel") didn't do anything either.
I've been banging my head against this for a day now and need professional help. ;-/
There is another piece to this puzzle, which is why I suspect the underlying problem has to do with "https". We ran into this problem why trying to install MongoDB using these instructions: https://docs.mongodb.com/v4.0/tutorial/install-mongodb-on-red-hat/#using-rpm-packages-recommended
We created /etc/yum.repos.d/mongodb-org-4.0.repo with the contents:
[mongodb-org-4.0]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/4.0/x86_64/
gpgcheck=1
enabled=1
gpgkey=https://www.mongodb.org/static/pgp/server-4.0.asc
and then tried to install MongoDB and got a somewhat different error:
-bash-4.2$ sudo vi /etc/yum.repos.d/mongodb-org-4.0.repo
-bash-4.2$ sudo yum install -y mongodb-org
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.keystealth.org
* extras: mirror.fileplanet.com
* updates: mirrors.sonic.net
https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.0/x86_64/repodata/repomd.xml: [Errno 14] curl#60 - "Peer's Certificate issuer is not recognized."
Trying other mirror.
It was impossible to connect to the CentOS servers.
This could mean a connectivity issue in your environment, such as the requirement to configure a proxy,
or a transparent proxy that tampers with TLS security, or an incorrect system clock.
You can try to solve this issue by using the instructions on 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 (MongoDB Repository),
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=mongodb-org-4.0 ...
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 mongodb-org-4.0
or
subscription-manager repos --disable=mongodb-org-4.0
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=mongodb-org-4.0.skip_if_unavailable=true
failure: repodata/repomd.xml from mongodb-org-4.0: [Errno 256] No more mirrors to try.
https://repo.mongodb.org/yum/redhat/7/mongodb-org/4.0/x86_64/repodata/repomd.xml: [Errno 14] curl#60 - "Peer's Certificate issuer is not recognized.”
However, now if I try this I get the "(Unknown)" error.
It's very confusing.
I had the same problem and in order to fix it I did the following:
$ yum install epel-release
$ cd /etc/yum.repos.d
$ rm epel-testing.repo
$ yum clean all
$ yum update -
It worked for me!
The problem is, even if we are installing epel via rpm, the path of baseurl configured in epel.repo and epel-testing.repo files are not valid because https://download.fedoraproject.org/ doesn’t exist.
Valid path is : https://dl.fedoraproject.org/pub/
So amend the base url in /etc/yum.repos.d/epel.repo from this : baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
to this :
baseurl=http://dl.fedoraproject.org/pub/epel/7/$basearch
Here's what I did
sudo nano /etc/yum.repos.d/epel.repo
Comment out the metalink and leave the existing baseurl commented out.
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
CAN BE REMOVED
{
[epel-debuginfo]
name=Extra Packages for Enterprise Linux 7 - $basearch - Debug
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug
#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
[epel-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS
#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1
}
Add a new baseurl
baseurl=https://armv7.dev.centos.org/repodir/epel-pass-1/
save the file
sudo yum update
I was able to get the epel repos to update and download and in checking if epel-release was installed with yum install epel-release I got an already installed package message. UPDATE:change gpgcheck=1 to 0 and should be fine. I also removed the gpgkey= line.
Let me know if it helps!
[cont]
When I installed htop.armv7h1 I had to do the --nogpgcheck with yum and it installed fine.

Dart throwing errors on linux: GLIBC_2.14 GLIBC_2.15 not found

I'm running Debian 7.2 on Google Compute Engine (Though I suspect Centos, Red Hat, and Amazon Linux AMI all have the same problem). After downloading the 64-bit Linux version of the Dart SDK from this page, any dart command I run, for example, dart --version, will output the following error:
./editor/dart/dart-sdk/bin/dart: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by ./editor/dart/dart-sdk/bin/dart)
./editor/dart/dart-sdk/bin/dart: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./editor/dart/dart-sdk/bin/dart)
Update: October 2014: Dart can now be installed on Debian with apt-get:
Instructions summarized from the dart website:
# Enable HTTPS for apt.
sudo apt-get update
sudo apt-get install apt-transport-https
# Get the Google Linux package signing key.
sudo sh -c 'curl https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -'
# Set up the location of the stable repository.
sudo sh -c 'curl https://storage.googleapis.com/download.dartlang.org/linux/debian/dart_stable.list > /etc/apt/sources.list.d/dart_stable.list'
sudo apt-get update
# Finally, install the dart package!
sudo apt-get install dart
Instructions for building the binary yourself:
This problem appears to be caused by Google compiling against an edge version of GLIBC (>= 2.15) which is not generally supported on Linux outside of Ubuntu 12 (Precise Pangolin).
First of all, do not attempt to download an experimental version of GLIBC or EGLIBC. I was able to get dart to work using that method, but the rest of my machine fell apart. Updating GLIBC is a recipe for madness.
Instead, the best solution is building dart from source. Despite the GLIBC version requirements of the binary, the source itself has no such requirements. There are wiki pages for installing from source on debian, centos/fedora/red hat/amazon, ubuntu, and other linux versions.
Here is an overview of those steps, which I can confirm works on Debian 7.2. The centos/fedora/redhat steps appear to be the same except they use yum instead of apt-get.
Install subversion and the required build tools:
sudo apt-get -y update
sudo apt-get -y install subversion
sudo apt-get -y install make
sudo apt-get -y install g++
sudo apt-get -y install openjdk-6-jdk
Check out google's depot tools and add gclient to your path
svn co http://src.chromium.org/svn/trunk/tools/depot_tools
export PATH=$PATH:`pwd`/depot_tools
Download the dart source at the desired branch.
Replace 1.2 with whatever branch you wish to build. You can see a list of available versions here. In general, the latest numbered branch is best.
gclient config http://dart.googlecode.com/svn/branches/1.2/deps/all.deps
gclient sync
gclient runhooks
Move into the new dart directory
cd dart
Do only A or B below:
Note: For 32bit, use the --arch=ia32 flag instead.
A. Build the entire Dart SDK including pub, dart2js, dart, etc.:
tools/build.py --mode=release --arch=x64 create_sdk
B. Build just the dart executable:
tools/build.py --mode=release --arch=x64 runtime
The dart executable is now at either out/ReleaseX64/dart or out/ReleaseX64/dart-sdk/bin/dart you can do a smoke test by printing the version
dart/out/ReleaseX64/dart --version
The output should be something like Dart VM version: 1.2.0 (Mon Mar 3 03:06:20 2014) on "linux_x64".
How to help fix this issue
This was much more painful than it needed to be, since the binary clearly doesn't need to be built using GLIBC >= 2.15. If you wish to draw attention to this issue, please star this dart bug.

Why won't my package upgrade with yum?

I'm trying to upgrade a package using yum on Fedora 8. The package is elfutils. Here's what I have installed locally:
$ yum info elfutils
Installed Packages
Name : elfutils
Arch : x86_64
Version: 0.130
Release: 3.fc8
Size : 436 k
Repo : installed
Summary: A collection of utilities and DSOs to handle compiled objects
There's a bug in this version, and according to the bug report, a newer version has been pushed to the Fedora 8 stable repository. But, if I try to update:
$ yum update elfutils
Setting up Update Process
Could not find update match for elfutils
No Packages marked for Update
Here are my repositories:
$ yum repolist enabled
repo id repo name status
InstallMedia Fedora 8 enabled
fedora Fedora 8 - x86_64 enabled
updates Fedora 8 - x86_64 - Updates enabled
What am I missing?
OK, I figured it out. I needed to upgrade the fedora-release package. That allowed me to see all of the updated packages. Thanks to ethyreal for pointing me to the Yum upgrade FAQ.
i know this seems silly but did you try removing it and reinstalling?
yum remove elfutils
then
yum install elfutils
alternatively you could try updating everything:
yum update
...if their is no update marked in the repository you might try:
yum upgrade
If you look at the listing of the repository packages directory at
Link to Fedora Repository
You will see that you have the latest version in that directory, which is why yum is not upgrading your package. This is the same in both the i386 and x86_64 package directories. So the reason that you are not seeing an update is that there is not a more current version in the repository yet. The notification in the bug report that a new version is in the repository is incorrect.

Resources