Re: Git core dump checking out main on armv7

It is not via an armv7 and it might not use the same server(s) you get to but:

# git clone --depth=1 -o freebsd ssh://anongit@git.FreeBSD.org/src.git /tmp/src
Cloning into '/tmp/src'...
remote: Enumerating objects: 104639, done.
remote: Counting objects: 100% (104639/104639), done.
remote: Compressing objects: 100% (88894/88894), done.
Receiving objects: 100% (104639/104639), 345.57 MiB | 8.39 MiB/s, done.
remote: Total 104639 (delta 22164), reused 43690 (delta 11830), pack-reused 0
Resolving deltas: 100% (22164/22164), done.
Updating files: 100% (101036/101036), done.


I see a differences in the ordering of the output for mine vs yours:

Receiving objects: 100% (104639/104639), 345.57 MiB | 8.39 MiB/s, done.
remote: Total 104639 (delta 22164), reused 43690 (delta 11830), pack-reused 0

vs. yours:

remote: Total 104639 (delta 22165), reused 43690 (delta 11830), pack-reused 0
Receiving objects: 100% (104639/104639), 345.56 MiB | 1.34 MiB/s, done.

(More significant?:)
I see a difference for "22164" vs. "22165" in mine vs. yours:

remote: Total 104639 (delta 22164), reused 43690 (delta 11830), pack-reused 0
Resolving deltas: 100% (22164/22164), done.

vs. yours:

remote: Total 104639 (delta 22165), reused 43690 (delta 11830), pack-reused 0
. . .
Resolving deltas: 100% (22165/22165), done.


My guess here is that you end up at a server that has messed up content and I do not.

I can end up at:

# traceroute git.FreeBSD.org
traceroute to gitmir.geo.FreeBSD.org (192.158.248.9), 64 hops max, 40 byte packets
. . .
14  isc.gigabitethernet1-1-44.switch55.fmt2.he.net (66.160.158.246)  26.076 ms
    gitmir.fmt.freebsd.org (192.158.248.9)  28.271 ms
    isc.gigabitethernet1-1-44.switch55.fmt2.he.net (66.160.158.246)  27.410 ms

You might want to try forcing an explicit reference to something like:

# git clone --depth=1 -o freebsd ssh://192.158.248.9/src.git /usr/src

and see if that makes any difference in your context.

If it does avoid the problem, you might want to do a:

# traceroute git.FreeBSD.org <http://git.freebsd.org/>

and report the results as indicating the likely place that has the problem.
There may be a better list to also send to for such a report.


Mark

On Jun 19, 2024, at 12:14, bob prohaska <fbsd@www.zefox.net> wrote:

On Tue, Jun 18, 2024 at 10:22:25PM -0700, Mark Millard wrote:
> 
> I'm going to quote kevens on discord from another git context:
> 
> QUOTE
> kevans: once you have git installed anongit via ssh is a lot more reliable, especially for the ports tree
> END QUOTE
> 
> (Watch out for my unusual directory naming on the left side of the lines:)
> 
> If your context allows use of: ssh:// . . .
> 
> # grep -rE "(^\[|url = )" /usr/*/.git/config
> /usr/official-src/.git/config:[core]
> /usr/official-src/.git/config:[remote "freebsd"]
> /usr/official-src/.git/config: url = ssh://anongit@git.FreeBSD.org/src.git
> /usr/official-src/.git/config:[branch "main"]
> /usr/official-src/.git/config:[branch "stable/14"]
> /usr/ports/.git/config:[core]
> /usr/ports/.git/config:[remote "freebsd"]
> /usr/ports/.git/config: url = ssh://anongit@git.FreeBSD.org/ports.git
> /usr/ports/.git/config:[branch "main"]
> 
> 
> I have historically found such more reliable than use of: https:// . . .
> 
> ssh:// . . . can also be used on the command line.
> 
> 
> If both ssh:// . . . and https:// . . . fail that likely has
> implications different than if just one form does.

Looks as if they both fail:

# git clone --depth=1 -o freebsd ssh://anongit@git.FreeBSD.org/src.git /usr/src
Cloning into '/usr/src'...
remote: Enumerating objects: 104639, done.
remote: Counting objects: 100% (104639/104639), done.
remote: Compressing objects: 100% (88894/88894), done.
remote: Total 104639 (delta 22165), reused 43690 (delta 11830), pack-reused 0
Receiving objects: 100% (104639/104639), 345.56 MiB | 1.34 MiB/s, done.
Resolving deltas: 100% (22165/22165), done.
fatal: missing blob object '619155cafe9277d1b3fc1bfd02fe76e27042a115'
fatal: remote did not send all necessary objects
# 

Both the "missing blob.." and "pack is corrupt..." messages have been 
seen regularly before. The system is running from microSD, but that
didn't prevent cloning, checking out and building the existing system
installation. Is there some way to check if the blob object named is
actually present on the server? If not, that would be a clue.

Thanks for writing!

bob prohaska


> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
> 


===
Mark Millard
marklmi at yahoo.com