Date: Sun, 23 Jun 2024 10:17:53 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: FreeBSD ARM List <freebsd-arm@freebsd.org> Subject: Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7 Message-ID: <F05531C2-F2F3-463A-9E89-3EB8A5D714B6@yahoo.com> In-Reply-To: <ZngxCS22kAZSrWH4@www.zefox.net> References: <7B376999-B84B-459E-B1C4-CC99EEF8D55A.ref@yahoo.com> <7B376999-B84B-459E-B1C4-CC99EEF8D55A@yahoo.com> <ZnMuDbaGEe273kK1@www.zefox.net> <B3467762-6F13-4BBE-A22E-612A44A59533@yahoo.com> <ZnNOXjgfyHQh7IeH@www.zefox.net> <5D5B6739-1685-43F5-80CC-E55603181D09@yahoo.com> <ZndZ9pVET2mCCpe8@www.zefox.net> <8F4F4B49-5ED3-4ACA-B0D3-356D8459BE95@yahoo.com> <ZngxCS22kAZSrWH4@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >>=20 >> Are they both microsd card based? If they are, what if >=20 > 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. =20 >=20 >> 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.) >>=20 >=20 > 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: >>=20 >> 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. >>=20 >=20 > 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. >>=20 >> Doing this can get into first using the likes of >> (notation presumes use of /mnt at the mount point used >> above): >>=20 >> # 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. >>=20 >> before doing the likes of: >>=20 >> # chroot /mnt/ >> # # EXPERIMENT HERE >> # exit >>=20 > 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: >>=20 >> # 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/ >>=20 >> # umount /mnt/ >>=20 > 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=20 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=3D"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=3D"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. >>=20 >=20 > The only Pi4 on hand is running -current. The armv7 system > is stable/14. I'll give it a try tomorrow. =20 =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F05531C2-F2F3-463A-9E89-3EB8A5D714B6>