From nobody Sun Jun 23 14:28:25 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W6YNn5tzHz5PbGl for ; Sun, 23 Jun 2024 14:28:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "generic", Issuer "generic" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W6YNn2CwNz4ptN for ; Sun, 23 Jun 2024 14:28:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.17.1) with ESMTPS id 45NESPRu068390 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 23 Jun 2024 07:28:26 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.17.1/8.17.1/Submit) id 45NESP0x068389; Sun, 23 Jun 2024 07:28:25 -0700 (PDT) (envelope-from fbsd) Date: Sun, 23 Jun 2024 07:28:25 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ARM List , bob prohaska Subject: Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7 Message-ID: References: <7B376999-B84B-459E-B1C4-CC99EEF8D55A.ref@yahoo.com> <7B376999-B84B-459E-B1C4-CC99EEF8D55A@yahoo.com> <5D5B6739-1685-43F5-80CC-E55603181D09@yahoo.com> <8F4F4B49-5ED3-4ACA-B0D3-356D8459BE95@yahoo.com> List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8F4F4B49-5ED3-4ACA-B0D3-356D8459BE95@yahoo.com> X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Queue-Id: 4W6YNn2CwNz4ptN On Sat, Jun 22, 2024 at 06:21:13PM -0700, Mark Millard wrote: > On Jun 22, 2024, at 16:10, bob prohaska 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. > 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. > 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/ > > 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! > Also, after exiting the chroot session, one would > do the likes of: > > # umount /mnt/dev/ > and possibly: > # umount /mnt/fd/ > > # umount /mnt/ > Thank you for the cleanup details! > 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. Thanks for writing! bob prohaska