I'm currently using Ubuntu 18.04 LTS, and I am trying to install GitLab via the instructions on https://www.linode.com/docs/development/version-control/install-gitlab-with-docker/.
Initially, I was following the instructions to download and install GitLab via Ubuntu 18.04 LTS at: https://about.gitlab.com/install/#ubuntu, which lead to a problem similar to the problem posed here: https://askubuntu.com/questions/637962/gitlab-install-is-stuck-at-0-on-ubuntu.
I then tried removing the processes involving dpkg with the help of sudo pkill gitlab, following the instructions posed at: https://unix.stackexchange.com/questions/94430/process-id-and-killing-process-ps-commmand.
However, I obtained the following error:
Is there a way to resolve this such that you must manually run sudo dpkg --configure -' to correct the problem does not appear again?
To answer your specific question, running dpkg --configure -a once should resolve the issue and you won't see the message again on future apt install execution. This problem arises because you kill apt in the middle of it doing work.
It seems like the root of the issue may be that you cannot access the GitLab package repository, or CloudFront, to pull the package?
Are you able to access https://packages.gitlab.com/gitlab/gitlab-ee from this system? i.e. curl https://packages.gitlab.com/gitlab/gitlab-ee
If the above works, can you try downloading an actual package manually to see if that works? i.e. wget --content-disposition https://packages.gitlab.com/gitlab/gitlab-ee/packages/ubuntu/xenial/gitlab-ee_12.2.4-ee.0_amd64.deb/download.deb
The image itself is served via CloudFront. So I wonder if you're able to connect to https://packages.gitlab.com but not cloudfront.net once the actual file is served.
I am having a problem while trying to decrypt some keys using GPG. The following output is given to me:
gpg: can't connect to the agent: IPC connect call failed
I already edited some files, pointed in this tutorial: https://michaelheap.com/gpg-cant-connect-to-the-agent-ipc-connect-call-failed/ but with no success.
Possible reasons for that?
Even I had the above issue in Ubuntu 20 WSL, I tried all the below | above suggestions, but none worked for me.
root#7400-9888K13:/mnt/c/Users/PKammari# wget -q -O - https://packages.cloudfoundry.org/debian/cli.cloudfoundry.org.key | sudo apt-key add -
gpg: can't connect to the agent: IPC connect call failed
What did I do to resolve the issue?
remove gpg
install other version of gpg.
How do I do it?
apt remove gpg ( follow the instructions)
apt install gnupg1 (follow the instructions)
Option 2.
sudo apt update --y
`sudo apt remove gpg`
`sudo apt-get update -y`
`sudo apt-get install -y gnupg1`
Proof. (refer to the screenshot):
There is probably already a gpg-agent running on the system, which your gpg command is unable to connect to.
If you do a pkill -9 gpg-agent and then source <(gpg-agent --daemon) to restart the agent, you should be able to connect to the pinentry-curses for inputting your password.
In my case the agent wasn't even started. This is what I did to resolve:
C:\Program Files (x86)\gnupg\bin>gpg-connect-agent -v
gpg-connect-agent: no running gpg-agent - starting 'C:\Program Files (x86)\gnupg\bin\gpg-agent.exe'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established
> ^Z
Afterwards the commands to the agent started working.
To hopefully add to preetam's excellent answer above for those very new to this.
To install gnupg1 - if you get the error "Package gnupg1 is not available, but referenced....."
sudo apt remove gpg
sudo apt-get update -y
sudo apt-get install -y gnupg1
For me, previous responses worked, but partially, what made the magic in my case was a combination of all, see the commands below.
If you get error add-apt-repository: command not found, then, install package software properties common.
sudo apt remove gpg
sudo apt-get update -y
sudo apt-get install -y gnupg1
# In case of Error when adding "ppa" with message: add-apt-repository: command not found
sudo apt-get install software-properties-common
# Now, the hack
sudo add-apt-repository ppa:rafaeldtinoco/lp1871129
sudo apt update
wget https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1871129/+files/libc6_2.31-0ubuntu8+lp1871129~1_amd64.deb
sudo dpkg --install libc6_2.31-0ubuntu8+lp1871129~1_amd64.deb
sudo apt-mark hold libc6 #to avoid further update
# Edit: /var/lib/dpkg/info/libc6:amd64.postinst and remove the sleep 1 that is in nearly the last line.
apt-get install -y gnupg gnupg1
cp -a /usr/bin/gpg /usr/bin/gpg2
ln -sf /usr/bin/gpg1 /usr/bin/gpg
apt-key worked for me after executing those commands.
I'm WSL 2.0 with Ubuntu 20.04 (Windows 10 Build 2004).
Reason:
uninstalling gnupg (2.x) also uninstalls gpg-agent, which is required.
installing gnupg1 (1.x) will install only gpg binary, not gpg-agent.
Both are required to work, but we want gnupg1 (1.x) to be the default "gpg" command (despite working with 2.x support-tools).
Based upon other behaviors in my Windows 10 system and through experimentation, I believe sometimes Windows Defender blocks gpg-agent from running because of a Windows Defender bug that slows the system trying to access low-level CPU counters.
Read Windows Defender can Significantly Impact Intel CPU Performance, We have the Fix. Work around the issue by downloading Counter Control from TECHPOWERUP and clicking "Reset Counters" when this problem arises. (See below.)
In my case I would frequently get the following error while trying to sign JAR files for deployment to Maven Central.
gpg: can't connect to the gpg-agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: skipped "…": No agent running
gpg: signing failed: No agent running
Sometimes if I kept trying over and over and over, eventually it would succeed.
Based on other answers, when this happened I trying manually connecting to the gpg-agent, but even that would time out:
> gpg-connect-agent --verbose
gpg-connect-agent: no running gpg-agent - starting 'C:\\Program Files (x86)\\GnuPG\\bin\\gpg-agent.exe'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: waiting for the agent to come up ... (4s)
gpg-connect-agent: waiting for the agent to come up ... (3s)
gpg-connect-agent: waiting for the agent to come up ... (2s)
gpg-connect-agent: waiting for the agent to come up ... (1s)
gpg-connect-agent: can't connect to the gpg-agent: IPC connect call failed
gpg-connect-agent: error sending standard options: No agent running
Because I've been experiencing similar slowdown issues on my machine seemingly related to Windows Defender, I ran "Counter Control" and sure enough, it showed that Windows Defender was maxing out the counter access as described in the article above. (Image embedded from the article.)
I tried to manually connect to gpg-agent again, but this time I hit "Reset Counters" in the utility just as gpg-connect-agent was retrying. When I did this, it immediately connected!
> gpg-connect-agent --verbose
gpg-connect-agent: no running gpg-agent - starting 'C:\\Program Files (x86)\\GnuPG\\bin\\gpg-agent.exe'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to the agent established
This seems unlikely to be a coincidence that it would connect at just the moment I reset the counters. Moreover Windows Defender has been causing other slowdown problems on my machine.
I believe that buggy behavior of Windows Defender is causing this problem on my machine. Please investigate and report if you can reproduce this workaround. (Note that, as per the article, this problem only affects certain generations of Intel CPUs.)
Update: Upon further testing, I'm still getting can't connect to the gpg-agent even if I've already reset counters to prevent Windows Defender from hogging the CPU as explained above. For some reason I normally still have to manually run gpg-connect-agent. Now it may be that resetting the counters while gpg-agent was trying to connect allowed it to connect. And it could still be be that Windows Defender is stopping gpg-agent from connecting when my system starts up. But at this moment all I know is that 1) gpg-agent isn't starting up automatically, 2) I have to run gpg-connect-agent manually, and 3) even running gpg-connect-agent will time out unless I reset the CPU counters to stop Windows Defender from hogging the CPU.
Mine is a windows machine, and when I do git commit I get the following message. I have already configured gpg keys on my machine.
gpg: can't connect to the gpg-agent: IPC connect call failed
gpg: keydb_search failed: No agent running
gpg: skipped "BBB42EB62E25E8EB33AE2E65F40A504840B1C66B": No agent running
gpg: signing failed: No agent running
error: gpg failed to sign the data
fatal: failed to write commit object
Will Buffington answer worked for me.
I had to apply the command
gpg-connect-agent -v
repeatedly as shown below. And it worked in the third attempt.
Once the I get the message connection to agent established, I now ran the commit command again. Now its successful. Note the -S flag to sign my commits.
Update
This morning, it did not start even after 3 attempts. I had to double click the exe from its installed location.
I had the same problem. In my case, the gpg config files were somehow corrupted. To solve it, I have removed all the configurations inside ~/.gnupg (make sure to backup any keys that you still need). Then I have reinstalled gpg and everything worked well.
On WSL1 Ubuntu 20.04 following workaround available: https://github.com/microsoft/WSL/issues/5125#issuecomment-619097534
sudo add-apt-repository ppa:rafaeldtinoco/lp1871129
sudo apt update
sudo apt install libc6=2.31-0ubuntu8+lp1871129~1 -y
sudo apt-mark hold libc6
I had to use:
sudo apt autoremove gpg gnupg1 gnupg2
In windows subsystem Ubuntu 20 works these steps:
sudo apt remove gpg
sudo apt-get update -y
sudo apt-get install -y gnupg1
After that steps appear "Ok"
I had the same problem when I killed the agent. It was not able to connect to agent again. So I had to remove all gpg gpg-related packages, and reinstall. I had to remove gpg-agent as well.
so what I did
sudo apt remove gpg gpg-agent
sudo apt-get install -y gpg
I was able to connect without installing new software. In my case the issue was that the IPC file wasn't in the expected position.
Check if gpg-agent with ps -eaf | grep gpg is running and kill it if it is running with killall gpg-agent
Start gpg-agent with verbose
$ gpg-agent --daemon -v
...
GPG_AGENT_INFO=/tmp/.../S.gpg-agent; export GPG_AGENT_INFO
copy-paste the GPG_AGENT_INFO line, including the export, in the shell where you need the agent.
I'm using Ubuntu 16.04.
When I update, I got the following message
$ sudo apt-get update
....
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
Following the error message, I try
$ sudo dpkg --configure -a
setting up snapd (2.14.2~16.04) ...
then it hangs forever.
Does anybody know how can I fix this problem?
Thanks.
This is a confirmed bug.
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621336
A workaround is listed:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621336/comments/4
Adding the workaround from Axel Kämpfe since the links seems to be broken:
Start a rootshell with "sudo -i"
Run echo "bash -c 'service snapd.boot-ok start'" | at now + 4 min
Then run apt install snapd (if it argues about canceled dpkg processes use the dpkg --configure -a. Then wait for at least 4 minutes. The hanging should gone then.
Good luck! :)
/Patrik
I had a similar problem twice and I have noticed that it happens everytime my system wants to upgrade to a new Kernel. The steps below seem to work for me all the time;
Boot into the recovery mode of your newest kernel versions.
Log-in to the system as root from the drop-down menu.
Edit the /etc/resolv.conf file using a text editor, I normally use vi, i.e.
vi /etc/resolv.conf
and put in the contents below and save file;
nameserver 208.67.222.220
nameserver 208.67.222.222
After the above step, Ctrl+D (exit) back into the recovery mode menu and click on networking to enable network/internet connection.
Next, click on the dpkg item to fix broken packages.
That's it, after the reboot your system should have the right kernel install and broken packages fixed/removed.
Identify the application that is causing the dpkg --configure -a hanging error.
Example: snapd
Execute the following command:
sudo apt-get remove snapd
In my case, I entered the following command:
sudo apt-get remove mysql-server-8.0
Re-install the application if necessary.
I hope this helps you too. Health!
Yesterday my vagrant box was working fine. Now it's not. When I try to provision my box again, or run this command (or any apt-get):
sudo /usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install postgresql
I get this error:
E: Couldn't determine free space in /var/cache/apt/archives/ - statvfs (20: Not a directory)
I've:
done a destroy, and I still get this error.
removed all but a couple packages from my provisioner I still get this error.
created a new vagrant file, using the same box, and I do NOT get this error.
cloned my vagrant file into a new folder, and I still get this error.
What is going on here?
UPDATE: It looks like there is a lock file in /var/cache/apt/archives/
I was using the vagrant-cachier pluggin, and it had cached a bad apt-get request that put in a lock. When I disabled this pluggin and rebuild the machine there were no issues.
I'm working on a bash setup script for CentOS 6.4 machines. On a brand new install I'm running into an issue that seems to be reproducible, but the scenario is unusual.
The setup script is run with root. The first step is to run yum update with no options:
yum update
This completes successfully with a zero exit code. The next step is to retrieve the EPEL rpm using wget:
wget http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
However, this is consistently failing when resolving the host name every time this is run from a clean CentOS install:
wget: unable to resolve host address “dl.fedoraproject.org”
When executing these commands in succession from the command line however, no issues are encountered and wget is able to retrieve the EPEL rpm:
sudo yum update
sudo wget http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
Is there anything that happens during the yum update that could cause the DNS lookup to fail without exiting the script first? If I rerun the script after the first failure, it passes on the second time around.
It's possible when the Time to Live of the domain name expires on the system or on a cache DNS server before the next instance of wget and the next attempt to resolve the domain name from the authorative server fails. See http://en.wikipedia.org/wiki/Time_to_live#DNS_records. Of course it's also possible that the cache DNS server becomes inaccessible.