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

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

> 
>