Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7
Date: Sun, 23 Jun 2024 17:17:53 UTC
On Jun 23, 2024, at 07:28, bob prohaska <fbsd@www.zefox.net> wrote: > On Sat, Jun 22, 2024 at 06:21:13PM -0700, Mark Millard wrote: >> On Jun 22, 2024, at 16:10, bob prohaska <fbsd@www.zefox.net> 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