From nobody Wed Jun 26 00:28:03 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 4W82cR06g4z5QJ3m for ; Wed, 26 Jun 2024 00:28:39 +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 4W82cH51hVz4ktF for ; Wed, 26 Jun 2024 00:28:31 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of fbsd@www.zefox.net has no SPF policy when checking 50.1.20.27) smtp.mailfrom=fbsd@www.zefox.net Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.17.1/8.17.1) with ESMTPS id 45Q0SICI077929 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 25 Jun 2024 17: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 45Q0SGr9077927; Tue, 25 Jun 2024 17:28:16 -0700 (PDT) (envelope-from fbsd) Date: Tue, 25 Jun 2024 17:28:03 -0700 From: bob prohaska To: Mark Millard Cc: FreeBSD ARM List 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: X-Spamd-Bar: / X-Spamd-Result: default: False [-0.98 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.99)[-0.989]; NEURAL_HAM_SHORT(-0.89)[-0.894]; WWW_DOT_DOMAIN(0.50)[]; MID_RHS_WWW(0.50)[]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; MISSING_XM_UA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[yahoo.com]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DMARC_NA(0.00)[zefox.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org]; R_SPF_NA(0.00)[no SPF record] X-Rspamd-Queue-Id: 4W82cH51hVz4ktF On Sun, Jun 23, 2024 at 10:17:53AM -0700, Mark Millard wrote: > On Jun 23, 2024, at 07:28, bob prohaska 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 > >