Git clone failures on armv7, was Re: Git core dump checking out main on armv7

Reply: Mark Millard : "Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7"
In reply to: Mark Millard : "Re: Git core dump checking out main on armv7"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: bob prohaska <fbsd_at_www.zefox.net>
Date: Sat, 22 Jun 2024 23:10:46 UTC
On Wed, Jun 19, 2024 at 03:56:14PM -0700, Mark Millard wrote:
> 
> I recommend trying on the different machines that have
> sufficient disk space for holding a temporary clone:
> 
> # git clone --depth=1 -o freebsd ssh://anongit@192.158.248.9/src.git /PATH-TO-NON_EXISTING
> 

It looks like the problem is somehow associated with Pi2/armv7.

A fresh clone using a Pi4 running -current aarch64 worked fine:

#  git clone --depth=1 -o freebsd ssh://anongit@192.158.248.9/src.git .
remote: Enumerating objects: 104635, done.
remote: Counting objects: 100% (104635/104635), done.
remote: Compressing objects: 100% (88902/88902), done.
remote: Total 104635 (delta 22157), reused 43604 (delta 11818), pack-reused 0
Receiving objects: 100% (104635/104635), 345.59 MiB | 1.26 MiB/s, done.
Resolving deltas: 100% (22157/22157), done.
Updating files: 100% (101035/101035), done.

On a Pi2 v1.1 armv7 running 14.1-STABLE  I got
# git clone --depth=1 -o freebsd ssh://anongit@192.158.248.9/src.git .
Cloning into '.'...
remote: Enumerating objects: 104635, done.
remote: Counting objects: 100% (104635/104635), done.
remote: Compressing objects: 100% (88902/88902), done.
remote: Total 104635 (delta 22150), reused 43604 (delta 11818), pack-reused 0
Receiving objects: 100% (104635/104635), 345.59 MiB | 1.28 MiB/s, done.
fatal: pack is corrupted (SHA1 mismatch)
fatal: fetch-pack: invalid index-pack output

On a Pi2 v1.1 armv7 running 15.0-CURRENT I got a different error:

root@www:/mnt/usr/gittest # git clone --depth=1 -o freebsd ssh://anongit@192.158.248.9/src.git .
Cloning into '.'...
remote: Enumerating objects: 104635, done.
remote: Counting objects: 100% (104635/104635), done.
remote: Compressing objects: 100% (88902/88902), done.
remote: Total 104635 (delta 22159), reused 43604 (delta 11818), pack-reused 0
Receiving objects: 100% (104635/104635), 345.59 MiB | 1.34 MiB/s, done.
Resolving deltas: 100% (22159/22159), done.
fatal: missing blob object '21481e27bf936a0f820482403f4c81d810b2382c'
fatal: remote did not send all necessary objects

It seems like there's something wrong with the clone command on armv7.

If you can suggest other tests I'll try them. Both armv7 hosts run
git pull successfully. It was possible to copy source trees using
sftp, so there is a workaround of sorts.

Thanks for all your help!

bob prohaska






> variability in that much.
> 
> The goal is to see which contexts work vs. which fail
> --and the type of failures. I'd also test non-armv7
> systems types that may be present as part of the
> activity.
> 
> Is the one armv7 the only system that gets the failure?
> If yes, then that suggests that some stage(s) unique to
> the one system are having problems with some I/O involved.
> 
> > 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     bob@www.zefox.com:/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 <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.
> 
> 
> ===
> Mark Millard
> marklmi at yahoo.com
> 
>