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

Reply: bob prohaska : "Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7"
In reply to: bob prohaska : "Git clone failures on armv7, was Re: Git core dump checking out main on armv7"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: Mark Millard <marklmi_at_yahoo.com>
Date: Sun, 23 Jun 2024 01:21:13 UTC
On Jun 22, 2024, at 16:10, bob prohaska <fbsd@www.zefox.net> wrote:

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

Are they both microsd card based? If they are, what if
a microsd card USB reader/writer is used instead of the
microsd card slot for booting the microsd card? (This
might require another microsd card with that has just
a sufficiently modern bootcode.bin on it to enable the
USB based boot.)

I can think of one other type of test that somewhat
isolates kernel vs. world issues:

It should be possible to mount the media normally used
on one of the RPi2B v1.1's on, say, an RPi4B. One could
then set up enough context to, say, chroot into the
armv7 file system and try executing the clone in that
context.

The result would be using the RPi4B aarch64 kernel and
the armv7 world. If that has no problems, then the armv7
kernel likely has problems that contribute but the armv7
world would be less likely to.

Doing this can get into first using the likes of
(notation presumes use of /mnt at the mount point used
above):

# mount -tdevfs devfs /mnt/dev/
and possibly:
# mount -tfdescfs none /mnt/fd/

before doing the likes of:

# chroot /mnt/
# # EXPERIMENT HERE
# exit

Also, after exiting the chroot session, one would
do the likes of:

# umount /mnt/dev/
and possibly:
# umount /mnt/fd/

# umount /mnt/

Note: The RPi4B kernel should not be an older vintage
than the armv7 world. Also, the RPi4B kernel should not
be stable/14 based if the armv7 world is main [15]
based. But a new enough RPi4B main [15] kernel should
be sufficient for both types of armv7 world.

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