Error: git-remote-https died of signal 4

Expected Behaviour:

OS: Debian GNU/Linux 11 (bullseye) x86_64
Webserver: Apache 2
Expected: Running pihole -up successfully

Actual Behaviour:

pihole - up

returns the following error:

[✓] Update local cache of available packages
  [i] Existing PHP installation detected : PHP version 7.4.30
  [✓] Checking for git
  [✓] Checking for iproute2
  [✓] Checking for whiptail
  [✓] Checking for ca-certificates

  [i] Checking for updates...
error: git-remote-https died of signal 4
  [i] Pi-hole Core:	up to date
  [i] FTL:		up to date

  [✓] Everything is up to date!

Manually updating via GitHub does not work either. FTL was updated correctly though.

Other than this, pi-hole is running as expected.

Any idea?

Debug Token:

[Replace this text with the debug token provided from running pihole -d (or running the debug script through the web interface]

git-remote-https is not a command we use.

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

Thanks for the reply. Interesting, why this message pops up, even though not used in the code.
Logs are uplaoded,

https://tricorder.pi-hole.net/rDO1tHwY/

I just learned that git internally uses this command when fetching/pulling from remote https repos. (What we do during installation/upgrade).
There is another report here about the issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010340

(TL;DR:

So this is not really a bug in git, but a bug in GnuTLS when running QEMU with Windows as host (with Hyper-V acceleration hax or whpx).)


Are you running QEMU?

No, I do not use QEMU at all. Plain Debian Linux, and is has worked before without any issues.
I saw the thread compiling GIT to use OpenSSL instead of GnuTLS. But this was all related to QEMU.

Compiling git with openSSL is working ok. But,

pihole -up

is pulling the orginal version back via the package manager.
The newly compiled version of git if showing

git version 2.37.1

pihole is obviously preferring

git version 2.30.2

Question would now be, how to prevent pihole -up from updating git, and just accepting the more recent version.

I think it's called pinning:
https://wiki.debian.org/AptConfiguration

Not sure, if I want to go this route.

The package tracker is indicating, that there might be a release of 2.37 available anytime soon.

https://tracker.debian.org/pkg/git

I tried various things like comiling git with openSSL, using a higher version like 2.34, trying to nailing down the issue. But matter of fact, this issue needs to be solved either with git or pihole.

[1153236.725350] traps: git-remote-http[143342] trap invalid opcode ip:7f89733c5d45 sp:7ffe53ad8890 error:0 in libcurl-gnutls.so.4.7.0[7f897338e000+66000]
[1154443.633759] traps: git-remote-http[145562] trap invalid opcode ip:7f139a16ad45 sp:7ffe951ba060 error:0 in libcurl-gnutls.so.4.7.0[7f139a133000+66000]

This seems tobe the real issue. I haven't foudn anything specific yet about it though.

Thanks for opening an issue on Github.

No way for us to do that really. We call apt-get and act on what it reports. There may be a way for apt to use the locally installed version but you would have to create a local apt package with the compiled version and dpkg -i it in.

The issue is not related to apt, but git. That is where the fundamental failure is located. See the issue I opened for details.

I did read your issue.

Seems you have manually compiled some software? We use apt to install the packages that we need. If apt doesn't see your manually compiled package then there's nothing we can do to prevent apt from overwriting your manual changes.

That's not fully correct.

I used the standard version provide with Debian Bullseye initially,

git version 2.30.2

That is giving the issues.
Searching through various forums, I found a hint point to a GnuTLS and that might can be circumvented by a fresh compile version of git which results in

git version 2.37.1

It does not change anything at all. And I reverted back to the standard version anyway.

Apparently, git fixed something on their side, but I can't confirm. The update went through this morning. :person_shrugging:

Thanks for letting us know. Glad it's resolved.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.