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

On Jun 23, 2024, at 07:28, bob prohaska <[email protected]> wrote:

> On Sat, Jun 22, 2024 at 06:21:13PM -0700, Mark Millard wrote:
>> On Jun 22, 2024, at 16:10, bob prohaska <[email protected]> wrote:
>> 
>> 
>> Are they both microsd card based? If they are, what if
> 
> No, all three were writing to a USB hard disk. The Pi4
> running -current the the Pi2 running stable/14 were
> using the disk holding root, the Pi2 running -current
> was using a disk plugged in and attached at /mnt, but
> not part of the root filesystem.  
> 
>> 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.)
>> 
> 
> In general, letting git write to usb flash has been a
> bad idea for me. It works sometimes, but mechanical
> disks seem better-behaved.

No reason for microsd card experiments, given the lack of
microsd card involvement.

>> 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.
>> 
> 
> 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 have local directory trees that are armv7 worlds.
The below shows "df -m" output with one example
armv7 chroot active:

# df -m
Filesystem          1M-blocks   Used  Avail Capacity  Mounted on
/dev/gpt/PkgBaseUFS    632802 147790 434387    25%    /
devfs                       0      0      0     0%    /dev
/dev/gpt/PkgBaseEFI       244     26    218    11%    /boot/efi
/dev/gpt/RPi5-edk2     121910      2 121908     0%    /RPi5-edk2
devfs                       0      0      0     0%    /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/dev
fdescfs                     0      0      0     0%    /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/dev/fd
/usr/official-src      632802 147790 434387    25%    /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/official-src
/usr/main-src          632802 147790 434387    25%    /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/main-src
/usr/src               632802 147790 434387    25%    /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/PkgBase-src 

I'll note that I use a script to do the chroot. It also
shows how I use mount_nullfs to have the chroot reference
some directories from the boot environment. (Such seems
not to be a likely things to do in your current
activities.)

You can ignore/avoid the:

env IN_CHROOT="main-armv7-chroot-ports-official"

that is in front of the chroot command. It is associated
with something personal that I do in the .shrc that ends
up being used as I have things set up.

FYI: I use /bin/sh and avoid /bin/csh use.

# more ~/do-chroot-main-armv7-chroot-ports-official.sh
#! /bin/sh
mkdir -p /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/dev/ \
&& mount -tdevfs devfs /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/dev/ \
&& mkdir -p /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/dev/fd/ \
&& mount -tfdescfs none /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/dev/fd/ \
&& mkdir -p /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/official-src/ \
&& mkdir -p /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/main-src/ \
&& mkdir -p /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/PkgBase-src/ \
&& mount_nullfs /usr/official-src/ /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/official-src/ \
&& mount_nullfs /usr/main-src/     /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/main-src/ \
&& mount_nullfs /usr/src/          /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/PkgBase-src/ \
&& env IN_CHROOT="main-armv7-chroot-ports-official" chroot /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/
umount /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/PkgBase-src/
umount /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/main-src/
umount /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/usr/official-src/
umount /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/dev/fd/
umount /usr/obj/DESTDIRs/main-armv7-chroot-ports-official/dev/

>> 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.
>> 
> 
> The only Pi4 on hand is running -current. The armv7 system
> is stable/14. I'll give it a try tomorrow.  


===
Mark Millard
marklmi at yahoo.com