On Aug 13, 2023, at 15:33, bob prohaska <f...@www.zefox.net> wrote:

> On Sun, Aug 13, 2023 at 12:45:12PM -0700, Mark Millard wrote:
>> 
>> Wow. I'm going to suggest doing a clone (to a temporary
>> place) on one or more different types of system, such
>> as aarch64 or amd64. If, say, aarch64 works but armv7
>> does not, then the corruption may well be in some armv7
>> FreeBSD handling of data transfers, in places common
>> to both https:// and ssh:// use.
>> 
> That seems to have worked on a Pi4 8GB running -current:
> 
> root@nemesis:/usr # mv src src.old
> root@nemesis:/usr # git clone  -o  freebsd 
> ssh://anon...@git.freebsd.org/src.git /usr/src
> Cloning into '/usr/src'...
> The authenticity of host 'git.freebsd.org (96.47.72.109)' can't be 
> established.
> ED25519 key fingerprint is SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE.
> This key is not known by any other names.
> Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
> Warning: Permanently added 'git.freebsd.org' (ED25519) to the list of known 
> hosts.
> remote: Enumerating objects: 4323641, done.
> remote: Counting objects: 100% (381285/381285), done.
> remote: Compressing objects: 100% (28204/28204), done.
> remote: Total 4323641 (delta 375527), reused 353081 (delta 353081), 
> pack-reused 3942356
> Receiving objects: 100% (4323641/4323641), 1.54 GiB | 390.00 KiB/s, done.
> Resolving deltas: 100% (3432012/3432012), done.
> Checking objects: 100% (16777216/16777216), done.
> Updating files: 100% (95944/95944), done.
> root@nemesis:/usr # 
> 
> 
>> Note that, if you get a good clone, you can locally
>> copy the tree over to the armv7 media. But that is
>> not the point of my suggestion above.
> 
> Under the circumstances it seems like the path of
> least resistance. Can I do something simple like
> sftp, using get -r ? Any trick to updating the copy? 
> 

Given that you are having networking problems, I was
thinking more of moving the hard disk to be temporarily
connected to the system with the good copy, mounting the
UFS file system (I presume UFS), and using the likes
of "cp -aRx SOMEPATH/ /mnt/usr/src/" to make the copy.
(Presumes the armv7 media's /usr/src/ is empty.) Then
umount, disconnect, and put things back on the armv7
system, boot that, and continue on.

It is less obvious what to do about future git fetch
activity on the armv7 system if that activity also has
problems.

But, you could try local area network based copying to
explore if that also has problems. That would involve
having git validate the copy after the copy is done.
If you found that some methods work and others do not,
that would be good to report. Similarly for the limiting
conditions: all network copying fails vs. local network
copies always work for all techniques tried.

Up to you.

===
Mark Millard
marklmi at yahoo.com


Reply via email to