From nobody Sun Jun 23 17:17:53 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 4W6d8d3FQCz5NdP2 for ; Sun, 23 Jun 2024 17:18:09 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-55.consmr.mail.gq1.yahoo.com (sonic308-55.consmr.mail.gq1.yahoo.com [98.137.68.31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4W6d8c6PZHz43BP for ; Sun, 23 Jun 2024 17:18:08 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1719163086; bh=HxfWwt3S6XE3C6NSUw/IccKY47CpUUUMua0lmih/q9A=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=SJjWTVP2As85PpDkyIUjZAoXEBi2u+gsAz5DOXDRsle1o1fmJPAXayT73RAiqH+qsOVNREU4RGC3Atz1pF+ZW4py1sAJUFrLQqzWc1piWZIY4b3jXqZbKAKJClVJOxe1lCb49yXLEtFBAyyE5pFCFVuQhv5ETdxUydx7BYOqbqTVtF8TYDaPh7Ku90DC8rjqvcUJjVdl6N0SXaNUsEGdbaSjD9wqK5lbJRZ4Ozz+PCXyb5WylCYnWuOYdELgMlhnmveAsrshWRRpim/8XFQYzMZQCVeBaOKS5NplzTh2H7WgOEmCq2D8vDrL8BLF/P5RP86Znr5SoEkK/cqox4CXAQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1719163086; bh=0SnQlM1Bgn/9bAnd/kKdIBPaTfZ7I5fQPc+g7pFthHw=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=pZcHyfISTIN92VfjtkkAb2CGoDjGQc3cs70rRpFQrydelWbRHRMa21xB07+zMeviv/RIvi55ueyDQ6ODh0vidElxCMemeAz7OqNTRGHyUxngboGPvYwJ7WP6JlvtyuTSj6cXxzUFCzWYYXAkAzYmpkPUPSXCOzwNcGos0ShqLqwJNK0jPklPpBVPh9z85K1+5Vgbr47dUzyjb2ysfg7Vi+nuBTHGCZozvMwPxIaG863v3Evvj3pAZM1hjvIYDYoiT6+/JU0HI1VNAxeq7NffKF4ZO9bZiqSlUpwX45PUGcZ2UFZVqv2LjhmQLm02t9us0+cEW8QEm8SugOyCItxXTA== X-YMail-OSG: goSV0B0VM1nfwAp05uFZpAuqyvPu22HpcGLwh7tX.sj9XAWbZpF3CxPOiYImaIz Pn.FtFugD0SPeF1l7ep8f7p7buPODB8mIuRgjLE_vojlkgzLvF3.dieyfTDVxjRiX99HjMhwVTmN lt0rVav1lne7j1L8tKoLXdJoxMX7DNVB_ycCbzvLSbSK4nz.1vspqRD2FjB8Nv0FlJjn1b70qRLA TvDZvf59j_XqsENCjdgCPX7f3MK1D17EmrFJncfSfaeSSX4F5gIXAAbYDB.mB.U8TTVNlDV5Xhuq HY6nccmxOmVRVY_v_ugFXZQmky9PWOsO5_gvBF69obNgHuojAA.XaQQuyB0okeLvXhEAFq8XC7Vg KL3im15_nDFFkQJbyqOsShWcwr6tvXcasQ3vBu9fDuE28k4PXmKncSHNY1lrXZVz5gd_lTcp221S JyTfCJCuHef_gHoArfmG3WNaR0vumvBRcchB6kfbuvTfqF0iff71oGrfjl35Y8km_pOOYX_DSRHj i3xFtoCR.GTmeb1fSQeHCFeWA_0GD4o_Ng.gTJk1HGR_x_BBhauiaxc8sStKlJFwahXCXhJi772t 1A8_62qq4X2tGA36K4FN4kpJNgVU1RGK2fI8xCo7qmt2A0x0nZ43_GNBa1.ed4D8KzZhPUqkpcVj pUGI_xsDjUZkBgcPy3lQtU4.AeMPLEf3_8_r8zDfgtGIJD9MVR.NVWpHeDg0RwCVEw4QhlZDRXg5 H3WrQT6WoUKgIopDSKIWuMLiRh6nMt9lcnW4KzWJqm9EsDMvO.UZ_iqC9uvprR0tQLO.A334QDO7 203aw7ChfY_SgtxqzKQNonNZD75AVG5CIu92sMFwv6Fp9c7CgxzvKvtHOmwUJuvwVuBqpcvxWpCl rZIUhvf2aki2oOjxQIrveC1LSJ1nhZTcSECC..irkp260FoyKU07PHOG5aDgH5Gsy0lUNoZiaIr_ RkSXdml7.R8Knvftw4.NsFVTMtfgD4wvoaG397jR.P7N58RV64VMtcYakA9XL5EmUM7wJMKyuyeG 5XgCyl8M36iJ30DXOwg6jcb3ClA0tYjzdu7iAQNMoXhdMb5NueogLGRnPfV1YY7GRpzBkTnuPlFt WtJhDMfCi7bHs2b27WXy5rWp0wBBHGrl40RoWVMOh8saiB9n48unmnLoOBRqERNovwguAq2pSEm. SLDBUnRP_gEPOvC3KDeDggfJc2IMNe_iQ4IcoonBTlQhXlfE1CfrLVhIee0jxaHErqSS8eQRwx36 goCQ1gRnLJWLXvl2JqFrLHbrSnDrsjP22P65TWFdRjd0lclOc8SxNEmkXg0pVWnvXPDmlLTmYxM9 5FIY32lxy0iR.WRhYA6QUYsyEc.oT2MAP_DCgA78CfenSM8NLTo3SyLWJvwMLvrse7XLSbdKuZHB Sq8s5Z07JIsCo19YweYo5zYj6jRwYO5bYNlQScv3hArBFrPU192H157_.uvtb3QT7D6wYWSV5qRy gLaOmTNnqhOCK68QPRHhNNkozIZ9JBbdh3V59T6Wm_D3AYYom6EDATFU_HNGBL0EocCwKt2pHBiE Q0RSkJ42YXX_h.3gB4Y2OEFx17B4O21aqalzj1zjI5k6nyi6zaikeJxAj87X9syf0Li1l8Xdc9D7 csqv65qZvMbypi64kdrj7LadmQu7RTBK7zdLck9JB712U17kQU2yf_AlwBh5BDOZTvUvrsTmYYum kMMF02drHLWNtb_dbgKVVXyFtHRJzslU3p4rsdSmyV51jpoI9DED_H9a8sgAvD8R6U5U_YxHo0lr 9J4cUlbsLDu3ckL5txTTK..RcRCZjZJ9a25xGivx4H57fO9UbiYVRLowjoE_9fy1emepnwH0DlVy jUo_6eCqH26hlagT3GBcey7VlXEv1A5cLFX0juo.GUAcm8UtGXRdkO.Ld5C6aMBB5bE1uvIg.q9n 69uKppWbHClix9nMpcF291Ot3MbpE9vXM9dYyCfJ16raHRyceyqdHtfZVMAkBZzdKYLX9lvn5Z1R ELuCy1WrWKNoIZR25j40rMfaMgFPNV.gpWfYNyd8zRHB.btXLo29nJB1u3Q8fQYBtKkSoZhiaQkr 9p7x4iQspBoPBwOmW6TMgjTrgzwHqWNLGW6eHzvxtlgk31EKLX15rY9xZ9Z1kI0pRmczMSyrju3G gQJCd91kn.Xhcb39B6cffKQpR0k5kmrWI9Yma2T0pEfAucP5RfByW_mTlNdRjWVwt28SZQeaPv5Y G9VaHrhuHDf.78c0HB0jby9oIqp9QNipMJ_2lFqy76jPmtut_tp10.jPXnXtYhGc6GBS.4ofg_OU s X-Sonic-MF: X-Sonic-ID: 4f6ec7a0-6d3d-4d1e-9b20-7ad8a8e3c697 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 23 Jun 2024 17:18:06 +0000 Received: by hermes--production-gq1-5b4c49485c-sbfr9 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 80bd96b996c34a05a69315c186823fb2; Sun, 23 Jun 2024 17:18:04 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Git clone failures on armv7, was Re: Git core dump checking out main on armv7 From: Mark Millard In-Reply-To: Date: Sun, 23 Jun 2024 10:17:53 -0700 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable 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> To: bob prohaska X-Mailer: Apple Mail (2.3774.600.62) 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:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Queue-Id: 4W6d8c6PZHz43BP On Jun 23, 2024, at 07:28, bob prohaska wrote: > On Sat, Jun 22, 2024 at 06:21:13PM -0700, Mark Millard wrote: >> On Jun 22, 2024, at 16:10, bob prohaska 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