Re: Git core dump checking out main on armv7
Date: Wed, 19 Jun 2024 22:56:14 UTC
On Jun 19, 2024, at 14:32, bob prohaska <fbsd@www.zefox.net> wrote:
> 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://anongit@192.158.248.9/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
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
The explicit 192.158.248.9 is deliberate to avoid
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