Re: Git core dump checking out main on armv7

On Wed, Jun 19, 2024 at 12:50:48PM -0700, Mark Millard wrote:
> 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.
> 
The off-by-one sort of makes sense; my host is expecting one more file than yours.

> 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.
>

Apparently the numerical address had been used before, as I got an ssh message
saying it was already known. 

Eventually I tried:
# git clone --depth=1 -o freebsd ssh://[email protected]/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 22152), reused 43688 (delta 11830), pack-reused 0
Receiving objects: 100% (104639/104639), 345.58 MiB | 1.35 MiB/s, done.
fatal: pack is corrupted (SHA1 mismatch)
fatal: fetch-pack: invalid index-pack output

The SHA1 mismatch has been seen before, so I renamed the
empty (according to ls -al) src directory, created a new
one and tried again with the same command. Same output,
same error.

Is it plausible that a stuck bit in a scratch area of the microSD
card might lead to mischief like this? Maybe a hardware problem in
the Pi itself (it's been in use since late 2015)? I didn't imagine 
it possible to wear one out, but...  

I have two other armv7 Pi 2 hosts, one running -current and one 
recently updated to 

FreeBSD www.zefox.com 14.1-STABLE FreeBSD 14.1-STABLE #53 stable/14-n267957-048ad7a9ef9f-dirty: Mon Jun 17 11:52:13 PDT 2024     [email protected]:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm   {no idea where the "dirty" came from}
 
that both seem to work much better. They both run from USB hard disks, 
with the microSD used only for bootstrapping. They're a couple years newer.
I'll try updating them to see if any new problems emerge.
 
Thanks very much for all your help!

bob prohaska

> 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 <[email protected]> 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://[email protected]/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://[email protected]/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://[email protected]/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
> 
>