[root#8b473cb5f656 sysconfig]# yum update
Loaded plugins: fastestmirror, ovl
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container error was
12: Timeout on http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container: (28, 'Resolving timed out after 30543 milliseconds')
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
Are you connected to the internet from within the docker container?
Can you share the output of the following command from within the container?
cat /etc/resolv.conf
Are you using the default yum repo or anything specific?
Restart the network driver on the host and the container for once.
Related
My Jenkins is running on CentOS 7 and I was looking to upgrade my Jenkins version 2.277.4 to 2.375.1. I tried using sudo yum update jenkins to update jenkins. I received this message: “Public key for jenkins-2.375.1-1.1.noarch.rpm is not installed”. I read an article telling me to pull the key from online, so I performed these commands:
sudo wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo --no-check-certificate
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
sudo yum update jenkins
Afterwards, I haven’t been able to correctly start Jenkins. Obviously, I should have just uploaded the new war file instead of using yum update.
Any time I try Sudo systemctl start jenkins I get this warning.
Warning: jenkins.service changed on disk. Run ‘systemctl daemon-reload’ to reload units.
Any suggestions on fixing this issue? Any way to revert back to the old version?
Thank you ahead of time!
**Edit: I tried reloading the daemon and restarting the service. However, my Jenkins start/restart is timing out even though I’ve set the timer to 10 mins.
Additionally, I installed java-11-openjdk during the upgrade, would that cause issues?
[root####~]# yum install jenkins
Loaded plugins: fastestmirror, product-id, search-disabled-repos, subscription-manager
This system is not registered with an entitlement server. You can use subscription-manager to register.
Loading mirror speeds from cached hostfile
base: mirror.myfahim.com
extras: centos-hcm.viettelidc.com.vn
updates: mirror.tino.org
base | 3.6 kB 00:00:00
extras | 2.9 kB 00:00:00
http://pkg.jenkins.io/redhat-stable/repodata/repomd.xml: [Errno 14] HTTPS Error 301 - Moved Permanently
Trying other mirror.
One of the configured repositories failed (Jenkins-stable),
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=jenkins ...
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 jenkins
or
subscription-manager repos --disable=jenkins
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=jenkins.skip_if_unavailable=true
failure: repodata/repomd.xml from jenkins: [Errno 256] No more mirrors to try.
http://pkg.jenkins.io/redhat-stable/repodata/repomd.xml: [Errno 14] HTTPS Error 301 - Moved Permanently
Please help me out
It looks like the jenkins.repo file currently distributed by jenkins.io, is configured to use http, not https. (C'mon, people, seriously? This is 2021.) Fortunately it's very easy for you to edit /etc/yum.repos.d/jenkins.repo to change it to https. Unfortunately, that's not where the problems stop, at least on RHEL 7.9, the root issuer (Let's Encrypt R3) is not in the trusted cert store by default. You can verify that the jenkins.io cert is actually valid by using a service such as https://www.ssllabs.com/ssltest/analyze.html?d=pkg.jenkins.io. The cert and chain is actually valid, but the issuer is R3, which is trusted by everyone else (Mozilla, Apple, Android, Java, Microsoft), but is not trusted by yum. To resolve this issue (after Sep 24, 2021) you need to update ca-certificates
yum upgrade ca-certificates
I have found a solution for this error.
edit your /etc/yum.repos.d/jenkins.repo file from
[jenkins]
name=Jenkins
baseurl=http://pkg.jenkins.io/redhat
gpgcheck=1
to
[jenkins]
name=Jenkins
baseurl=https://pkg.jenkins.io/redhat
gpgcheck=1
Try to yum update.
It will probably return an SSL error.
If so, edit your /etc/yum.conf , add this line:
sslverify=false
Now it should work.
Remember to set sslverify to true again if you don't want self-signed certificates to work on your yum.
I have found a solution for this error.
ALL REPOS URL MUST HTTPS.
HTTP -> HTTPS
edit all your /etc/yum.repos.d/REPONAMES.repo file from
[repo]
name=Jenkins
baseurl=http://pkg.jenkins.io/redhat
gpgcheck=1
to
[repo]
name=Jenkins
baseurl=https://pkg.jenkins.io/redhat
gpgcheck=1
Try to yum update. It will probably return an SSL error. If so, edit your /etc/yum.conf , add this line:
sslverify=false
Now it should work.
Remember to set sslverify to true again if you don't want self-signed certificates to work on your yum.
I'm currently working out a Dockerfile. So I am trying to build out a Centos 7.6 base image and I get a failure when I try to use any yum packages. I'm not sure what the cause of this is.
I've already attempted to make the user root to see if that makes a difference but it doesn't help the situation. I've also done a docker pull centos to recieve the latest version of centos.
I simplified the code and still the same error.
FROM centos
ARG MONGO-RAILS-VERSION="0.0"
RUN yum install vim
# curl -L get.rvm.io | bash -s stable \
# rvm install 2.3.1 \
# rvm use 2.3.1 --default \
# gem install rails
I get an error that looks something like this
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 find a valid baseurl for repo: base/7/x86_64
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=container error was
14: curl#7 - "Failed to connect to 2001:1b48:203::4:10: Network is unreachable"
The command '/bin/sh -c yum install vim' returned a non-zero code: 1
You may want to have a look for Set build-time variables (--build-arg):
$ docker build --build-arg HTTP_PROXY=http://10.20.30.2:1234 --build-arg FTP_PROXY=http://40.50.60.5:4567 .
I used docker for a while, but i don't need it anmyore. So i removed it from my Ubuntu 16.04. When i try "sudo apt-get remove docker" it says that there is nothing, but when i run "sudo apt-get update" i get many lines like this:
Ign:45 https://download.docker.com/linux/ubuntu §(lsb_release/stable amd64 DEP-11 Metadata
So it's still updating docker.
Does anyone know how to remove docker completely from Ubuntu 16.04?
As sanath already stated you still have entries in /etc/apt/source.list for the docker package repository. You need to remove these (look for lines containing docker in that file and remove them).
To explain what these entries are:
/etc/apt/sorce.list lists all sources for packages which you can install/upgrade using apt. When you followed the steps in the installation of docker you added a line with the address of the docker package repository there. Now apt update always polls that repo to check if it contains any upgrades of a package you have installed.
Now because that address contains docker you falsely asume that you still have docker installed, which is not the case. Docker is simply part of the url of one of the repositories that is queried for updates.
It's because some of the entries are still present in.
nano /etc/apt/source.list
Remove lines which is having docker repository.
Then do apt-get update
I want to use apt to install some packages for the test, however, it fails due to that the sudo is disabled. I found the following in the test output:
Sudo, the FireFox addon, setuid and setgid have been disabled.
It seems that the output comes from this line in travic-ci, but setting paranoid_mode to false in .travis.yml does not work.
How to enable sudo access?
PS: I am using private repo.
EDIT: The following .travis.yml will fail due to sudo: must be setuid root when running sudo apt-get update -qq
language: python
python:
- "3.4"
before_install:
- sudo apt-get update -qq
script:
- nosetests
Setting sudo: true and/or paranoid_mode: false does not work.
Sudo access is turned off on our Docker based architecture, which will be used in two contexts:
repositories opt in using sudo: false in their .travis.yml file (it additionally needs to be turned on on our side)
on our educational program (see http://education.travis-ci.com)
Builds running on our Docker based architecture currently cannot be allowed sudo access due to certain security concerns in the LXC/Docker layer. We hope this will be fixed in the near future, but unfortunately the issue is out of our own hands.
We are also working on improving the Firefox addon, which currently uses sudo itself, but shouldn't. We'll post on our blog once this has happened.
To extend the existing answer, if you put in .travis.yml:
sudo: required
Travis should switch your build to use their "standard infrastructure" (rather than their "container based infrastructure") and then you can use sudo.
References:
https://docs.travis-ci.com/user/workers/standard-infrastructure
https://docs.travis-ci.com/user/workers/container-based-infrastructure/
Nov 2018 Update
It seems that container-based infrastructure is getting deprecated. From the docs:
Container-based infrastructure is currently being deprecated. Please
use the fully-virtualized infrastrstructure via sudo: required
instead.
As explained in "Combining The Linux Infrastructures"
Going forward, we will slowly transition the container-based environment out, in favor of a build environment that is entirely virtual machine-based.
Folks using container-based infrastructures will be the only ones affected, and this transition will roll out slowly, depending on whether you specify sudo: false in your .travis.yml.
This is illustrated in Git 2.20 (Q4 2018), with:
Travis CI will soon deprecate the container-based infrastructure enabled by sudo: false in ce59dff (Git 2.8.0, Jan. 2016).
See commit 0f0c511 (01 Nov 2018) by SZEDER Gábor (szeder).
(Merged by Junio C Hamano -- gitster -- in commit 57f06d5, 13 Nov 2018)
travis-ci: install packages in 'ci/install-dependencies.sh'
Ever since we started using Travis CI, we specified the list of packages to install in '.travis.yml' via the APT addon.
While running our builds on Travis CI's container-based infrastructure we didn't have another choice, because that environment didn't support 'sudo', and thus we didn't have permission to install packages ourselves.
With the switch to the VM-based infrastructure in the previous patch we do get a working 'sudo', so we can install packages by running 'sudo apt-get -y install ...' as well.
Let's make use of this and install necessary packages in 'ci/install-dependencies.sh', so all the dependencies (i.e. both packages and "non-packages" (P4 and Git-LFS)) are handled in the same file.
Install gcc-8 only in the 'linux-gcc' build job; so far it has been unnecessarily installed in the 'linux-clang' build job as well.
Print the versions of P4 and Git-LFS conditionally, i.e. only when they have been installed; with this change even the static analysis and documentation build jobs start using 'ci/install-dependencies.sh'
to install packages, and neither of these two build jobs depend on and
thus install those.
This change will presumably be beneficial for the upcoming Azure Pipelines integration preliminary versions of that patch series run a couple of 'apt-get' commands to install the necessary packages before running 'ci/install-dependencies.sh', but with this patch it will be sufficient to run only 'ci/install-dependencies.sh'.