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

On Jun 25, 2024, at 17:28, bob prohaska <fbsd@www.zefox.net> wrote:

> On Sun, Jun 23, 2024 at 10:17:53AM -0700, Mark Millard wrote:
>> On Jun 23, 2024, at 07:28, bob prohaska <fbsd@www.zefox.net> wrote:
>>>> 
>>>> 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.
>>>> 
>>> 
>>> That's physically not hard to do. Just power down the stable/14
>>> Pi2 and plug the Pi2's boot disk into the Pi4.
>> 
>> Up to power issues, if bus powered.
>> 
>>>> 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/
>> 
>> That last should have been:
>> 
>> # mount -tfdescfs none /mnt/dev/fd/
>> 
>> Use of the likes of "mkdir -p . . ." may be required in
>> order to have the directories for use as mount points
>> if they are missing.
>> 
>>>> 
>>>> before doing the likes of:
>>>> 
>>>> # chroot /mnt/
>>>> # # EXPERIMENT HERE
>>>> # exit
>>>> 
>>> I didn't realise that armv7 binaries would run under
>>> an aarch64 kernel. Most convenient!
>> 
>> Such can be used to have a faster way to build armv7
>> packages, that also allows larger armv7 processes to
>> be involved (but still 32-bit limited with part of
>> the address space reserved, for sure). Not only that,
>> the process size limit is not a system
>> size limit: An RPi4B with 8 GiBytes of RAM can have
>> several armv7 processes at once that total over 4
>> GiBytes of RAM in use at the time, no swapping
>> needing to be involved.
>> 
>>>> Also, after exiting the chroot session, one would
>>>> do the likes of:
>>>> 
>>>> # umount /mnt/dev/
>>>> and possibly:
>>>> # umount /mnt/fd/
>> 
>> That should have been (order dependent for fd inside dev):
>> 
>> possibly:
>> # umount /mnt/dev/fd/
>> 
>> then:
>> 
>> # umount /mnt/dev/
>> 
>>>> 
>>>> # umount /mnt/
>>>> 
>>> Thank you for the cleanup details!
>> 
> 
> I ended up trying the experiment twice. The first try used the mistaken
> mount -tfdescfs none /mnt/fd/ but since it was noted "possibly" I ignored
> the error and the git clone command completed successfully. After noticing
> your correction, the experiment was repeated and the clone failed:
> 
> root@nemesis:/usr/2ndgittest # git clone --depth=1 -o freebsd ssh://anongit@192.158.248.9/src.git .
> Cloning into '.'...
> remote: Enumerating objects: 104636, done.
> remote: Counting objects: 100% (104636/104636), done.
> remote: Compressing objects: 100% (88903/88903), done.
> client_loop: send disconnect: Broken pipe88.34 MiB | 165.00 KiB/s

The above "client_loop: send disconnect: Broken pipe"
seems to be the original error here.

It would be interesting to have evidence of how
repeatable such is and what variety of other
results happen.

So far it is suggestive of the armv7 kernel having
problems that the chroot on aarch64 does not have.

> fetch-pack: unexpected disconnect while reading sideband packet
> fatal: early EOF
> fatal: fetch-pack: invalid index-pack output
> root@nemesis:/usr/2ndgittest # 
> 
> The invalid index-pack output error has been seen on the Pi2s, but it
> isn't the most common recently. It followd a successful clone by a 
> few minutes. 
> 
> Hopefully somebody can make sense of the result...!
> 
> Thanks for all your help!
> 
> bob prohaska

===
Mark Millard
marklmi at yahoo.com