From nobody Sun Jun 23 01:21:13 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 4W6Cwl1y06z5NRbV for ; Sun, 23 Jun 2024 01:21:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic308-8.consmr.mail.gq1.yahoo.com (sonic308-8.consmr.mail.gq1.yahoo.com [98.137.68.32]) (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 4W6Cwk6ZpHz4gxN for ; Sun, 23 Jun 2024 01:21:26 +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=1719105684; bh=zZWsJdReeNUMYr/MSqFnLl+IJxOxnIVECxxBoa4gRow=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=bY5WfXvL1+vTffE6LcdmNr6JK/rCONXXuat58WjakFjj5SBYp8l3HJmiDMNn7rz49UDxLNS2q1BaMOzbCAuh4ccybujBtTZMtpO+WHTlLf4Mz/RgcvMPRk4XUtrgmg7f75vHRqbKwwJvvVrLxQNtFEzWQgQOVOq6evMKgeesAh2U5UMcH4VBQc5Vi+PV9oAGP0VnF74y7ixZUOvFHYge2FBPclcrUCXlBbab4dNHkUrvq/3S1O2pWnNY5OkDkDOB5IkXbjvXCtyn03DJMesc1eUqOWkG1espsSN4tlNO6sH2BUhSWXis+ce665h6oixVTXutEkAulDCL9n1ILXm3gg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1719105684; bh=5UqH+DAm4kbCaywx6KQaT0pyP6C8E9Vl6ZQ6aQdMJaA=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=gnXFAsQpCISoSQYCi6ZL3dGe79l0jwiZaF3Jf4bCCBcwCWeyOsmbTDATu/r/OyQVrxzq7hDq0ltiSdB6tYJg/bYtHssvBsKcRMHkNYfreC+Du3lDmnUDUOU0U+Jh/XLeAeWKhgyCIZOnazMGbJhF3CWt+2FSuIJ7GaIGRER0e09Yk8gBXH+GzijaaH//mRYwy0zDphRi0TwwNsOxWVDvPAmhpslyzUjjLzuiRwYhZku6eLQhA91IaVxr23PbJP+gUxhQ0geS1Ba8R7vIG3jowxD5TZzASKyiHA5c0kgIh/156cnrvNWG43ra4ekxdzE15BLNE23uVrJhqVtlc7x09g== X-YMail-OSG: QNzSaQkVM1nyPsyxTFMz_vx_b80JCSJkqOZBkfDSyY0gS.swKrjRAmYXgNEiKN3 P9CkP54Jasbjt3jsXu1bYA90EB7Vd7inU4ykRsbw5QUozIaSkkejiWvrG1f117cVFOoW_5jALE1S T9MZhUaXOGSd2xwidBeULIXuRO55fNQO2x7I7.O4lIQsqT.WK7PZOitG.cmF844qWuQjieK6r3FZ FaG4cF5MdLR6vSogQZN8ku704NO_IeXo5sPZ5h9oWNBuT4uNL_KRQOEZdbt2idvGtKZ8YGYFzjOg uiCR8vjGnJ.DHkpsW74hPCgEbaKtW6JdVrWrGm423BXlwOMyKv0oUkJDHj48m74wHdJggOa2hbYi U9yBb.M5ZUyfSfBiCqHVQ44f6yu2vEq6svMON4.t1jNmRD8uAqWrbFUWYeeRKqn6YzbRnLha5fZt Jq8.74vezrF9HDBw__TjPmpbgTrKC0rUs9LEybH9GrUtze8oeSQhCKkYtZCniTLOtUjB_bHMBkXw QGEn5ZMGzK4I8fIi9fQnmqNd7uuNusxnXR0MK.f4aqBibqDB91hyUQKe2xhOfiOiL901_kufq9Ee vma_iabF8F4rvAT4jxVRFm.iiGfxR.zvbnAbFdPC2SKH9EqDquRB3is.cI1XnVbMQl_VDB8C0_lm 7xVSzaJbiAhDGklc4YRy73_3zBbaIbkAJ7o9hJpQsQkvuuBXLKectMCoqFKEjf7ERCg7j4f2gRwH 8S2tsyUKYBfAIWy4sPy1a2BbvmJHDB2FYw5zEM_a8RgpCRQnTOBuvZk_KBDggbmHSJSrZS4xjnpj Qq3yGmqXZTlgtbFpcoErTCtMuLPWX4XGr18hWpacsK8DRVuEWtYizOzwRSEdZesnyhWX6qzyuJma mJ1Gd4DA3SrFWIMRAJuT89UqKUorMn8b4OxPkJZdqKKknrK8UJ8qSzfmYYUWhN.HSzPVtWXrmVHW m1xkMf_O8JktKsaVlf54t8Cr_pHgwg6zoe74ihk4jtKIs_JvYDGyXW_Lvk7P4b7HEZTy7DNKSiKg a5EnlrP4HTy68RjuyS.wHdjOz9WXk3O_ucdUbVAqDFXaXIX7WkVI_iV2adCtL7sjsEZPM.A_zICs arojPkto6x.45M0yHrSgBn0EsPM_R2FpVNzHPA2pBB57zlqQYNRwUI5PUr9p5bdkKclO3ab94B84 59uvK5B3Dn_c_SvcRbfCCmmJ0rh7aBP45dTnWBaufb6RehsmChnlBlOUfQIxqCi19_ejnIUeuNAg lzVBnJ5nelIOrAf_zZ7.0Bfchk9tP68QBJ.hMV3p9ajtFtxuiN0NV2Me5gsHzZ64bRfINbipdeLg Q0FCQvlS7MVdgWE16OlnIP_hhF9pvyqFA5t2eeRfY06fIRrD5Ii0Hguksmbe4wqVqxrcFzOCO_VE A61NvvMb46unxflSqqjZVKRtVPWBy9e8IXE9KJvScu2GR9STvKgw03FVEGaH65XPwfaSjLIhCucw UwYcUuDQtXW_wSk9ZbjYxPA1ZU0K7Dn6QZP0P5WPKk483tD3_vSSSWFMpEq.hujaEBDv1fbC.Oyl s2wzoI6GbDI8Nps6CG6pYIHpyFz11fo5_s3wThXob5MNA8GKDmjP9WMyXDkRE6UpYFoOWMGEInKM Pa7a9CSB08XqVW1ZIs5j_LrtmghfaE5KaZzKAJBJcko0EMKMBknB9WEGDKxBkvlcH_rC1EFgAGE6 gz3QZxekBnUM8u1c_ilgLyOdHfQrAXSts_qvw.PmbyQa.DOWy3qeyP63mZm5srWEjsBb2BdrAtZx dG0XMx8nwMspLa7fVpETr1ccken.AR7DNN4tTwVSIRi9ntgL8XlwyGJzYXpYKZ6WmyhnvIUjXnIK ZeLFHHlnOjTpOGfgsrtHuQRm8dFkIApiXr.DswlTuBVUuOshcztTcsIOH0Xv0NLUde.z9NHUL1GH BHZVvWI0EHKlR2vlk70Phw1GcJlqD5usEtCHXMva9xh.iU4r7kgZv4z8_kC9FP8_Tt5Tni2RRO48 nJUB21w9u8d0HTnI0HifC83dLv1Dt5LBnmASlfCa6MwJW3q5x4Wu9Uo0zVAJwB.8XuJ5JbXje_wb VFa9GG8vK5PxahYYRNjcGt1QfCPYyc6T46IqgM2RotRtOtvi8lyFmmSPDPq0jar6ZgaFIeLBj2X5 R9DotrA9kvyxkG9ObgrjJyHHTD9222GX35jGcJzeojNmJEO9B1vGXVOOgwjmLyNvQcyYWkd0ZEMN E3kapMSsmKsYw2mqXNWvo9boP7JF0hcjaEO3RCsKC6sJY0UmAruSnX2yXD6wBb5TAWSwr0pFRx8k 16dU7kITKv3TlJQ3R_Q-- X-Sonic-MF: X-Sonic-ID: 25034055-6d85-4202-a25b-6665b58799a6 Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.gq1.yahoo.com with HTTP; Sun, 23 Jun 2024 01:21:24 +0000 Received: by hermes--production-gq1-5b4c49485c-4758j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID ebbc728fc703381e1e02bdce70e9a2f8; Sun, 23 Jun 2024 01:21:24 +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: Sat, 22 Jun 2024 18:21:13 -0700 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <8F4F4B49-5ED3-4ACA-B0D3-356D8459BE95@yahoo.com> References: <7B376999-B84B-459E-B1C4-CC99EEF8D55A.ref@yahoo.com> <7B376999-B84B-459E-B1C4-CC99EEF8D55A@yahoo.com> <5D5B6739-1685-43F5-80CC-E55603181D09@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: 4W6Cwk6ZpHz4gxN On Jun 22, 2024, at 16:10, bob prohaska wrote: > On Wed, Jun 19, 2024 at 03:56:14PM -0700, Mark Millard wrote: >>=20 >> I recommend trying on the different machines that have >> sufficient disk space for holding a temporary clone: >>=20 >> # git clone --depth=3D1 -o freebsd = ssh://anongit@192.158.248.9/src.git /PATH-TO-NON_EXISTING >>=20 >=20 > It looks like the problem is somehow associated with Pi2/armv7. >=20 > A fresh clone using a Pi4 running -current aarch64 worked fine: >=20 > # git clone --depth=3D1 -o freebsd = ssh://anongit@192.158.248.9/src.git . > remote: Enumerating objects: 104635, done. > remote: Counting objects: 100% (104635/104635), done. > remote: Compressing objects: 100% (88902/88902), done. > remote: Total 104635 (delta 22157), reused 43604 (delta 11818), = pack-reused 0 > Receiving objects: 100% (104635/104635), 345.59 MiB | 1.26 MiB/s, = done. > Resolving deltas: 100% (22157/22157), done. > Updating files: 100% (101035/101035), done. >=20 > On a Pi2 v1.1 armv7 running 14.1-STABLE I got > # git clone --depth=3D1 -o freebsd ssh://anongit@192.158.248.9/src.git = . > Cloning into '.'... > remote: Enumerating objects: 104635, done. > remote: Counting objects: 100% (104635/104635), done. > remote: Compressing objects: 100% (88902/88902), done. > remote: Total 104635 (delta 22150), reused 43604 (delta 11818), = pack-reused 0 > Receiving objects: 100% (104635/104635), 345.59 MiB | 1.28 MiB/s, = done. > fatal: pack is corrupted (SHA1 mismatch) > fatal: fetch-pack: invalid index-pack output >=20 > On a Pi2 v1.1 armv7 running 15.0-CURRENT I got a different error: >=20 > root@www:/mnt/usr/gittest # git clone --depth=3D1 -o freebsd = ssh://anongit@192.158.248.9/src.git . > Cloning into '.'... > remote: Enumerating objects: 104635, done. > remote: Counting objects: 100% (104635/104635), done. > remote: Compressing objects: 100% (88902/88902), done. > remote: Total 104635 (delta 22159), reused 43604 (delta 11818), = pack-reused 0 > Receiving objects: 100% (104635/104635), 345.59 MiB | 1.34 MiB/s, = done. > Resolving deltas: 100% (22159/22159), done. > fatal: missing blob object '21481e27bf936a0f820482403f4c81d810b2382c' > fatal: remote did not send all necessary objects >=20 > It seems like there's something wrong with the clone command on armv7. >=20 > If you can suggest other tests I'll try them. Both armv7 hosts run > git pull successfully. It was possible to copy source trees using > sftp, so there is a workaround of sorts. >=20 > Thanks for all your help! >=20 > bob prohaska >=20 Are they both microsd card based? If they are, what if 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.) 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. 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 Also, after exiting the chroot session, one would do the likes of: # umount /mnt/dev/ and possibly: # umount /mnt/fd/ # umount /mnt/ 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 >> variability in that much. >>=20 >> The goal is to see which contexts work vs. which fail >> --and the type of failures. I'd also test non-armv7 >> systems types that may be present as part of the >> activity. >>=20 >> Is the one armv7 the only system that gets the failure? >> If yes, then that suggests that some stage(s) unique to >> the one system are having problems with some I/O involved. >>=20 >>> The SHA1 mismatch has been seen before, so I renamed the >>> empty (according to ls -al) src directory, created a new >>> one and tried again with the same command. Same output, >>> same error. >>>=20 >>> Is it plausible that a stuck bit in a scratch area of the microSD >>> card might lead to mischief like this? Maybe a hardware problem in >>> the Pi itself (it's been in use since late 2015)? I didn't imagine=20= >>> it possible to wear one out, but... =20 >>>=20 >>> I have two other armv7 Pi 2 hosts, one running -current and one=20 >>> recently updated to=20 >>>=20 >>> FreeBSD www.zefox.com 14.1-STABLE FreeBSD 14.1-STABLE #53 = stable/14-n267957-048ad7a9ef9f-dirty: Mon Jun 17 11:52:13 PDT 2024 = bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm {no idea = where the "dirty" came from} >>>=20 >>> that both seem to work much better. They both run from USB hard = disks,=20 >>> with the microSD used only for bootstrapping. They're a couple years = newer. >>> I'll try updating them to see if any new problems emerge. >>>=20 >>> Thanks very much for all your help! >>>=20 >>> bob prohaska >>>=20 >>>> If it does avoid the problem, you might want to do a: >>>>=20 >>>> # traceroute git.FreeBSD.org >>>>=20 >>>> and report the results as indicating the likely place that has the = problem. >>>> There may be a better list to also send to for such a report. >>>>=20 >>>>=20 >>>> Mark >>>>=20 >>>> On Jun 19, 2024, at 12:14, bob prohaska wrote: >>>>=20 >>>> On Tue, Jun 18, 2024 at 10:22:25PM -0700, Mark Millard wrote: >>>>>=20 >>>>> I'm going to quote kevens on discord from another git context: >>>>>=20 >>>>> QUOTE >>>>> kevans: once you have git installed anongit via ssh is a lot more = reliable, especially for the ports tree >>>>> END QUOTE >>>>>=20 >>>>> (Watch out for my unusual directory naming on the left side of the = lines:) >>>>>=20 >>>>> If your context allows use of: ssh:// . . . >>>>>=20 >>>>> # grep -rE "(^\[|url =3D )" /usr/*/.git/config >>>>> /usr/official-src/.git/config:[core] >>>>> /usr/official-src/.git/config:[remote "freebsd"] >>>>> /usr/official-src/.git/config: url =3D = ssh://anongit@git.FreeBSD.org/src.git >>>>> /usr/official-src/.git/config:[branch "main"] >>>>> /usr/official-src/.git/config:[branch "stable/14"] >>>>> /usr/ports/.git/config:[core] >>>>> /usr/ports/.git/config:[remote "freebsd"] >>>>> /usr/ports/.git/config: url =3D = ssh://anongit@git.FreeBSD.org/ports.git >>>>> /usr/ports/.git/config:[branch "main"] >>>>>=20 >>>>>=20 >>>>> I have historically found such more reliable than use of: https:// = . . . >>>>>=20 >>>>> ssh:// . . . can also be used on the command line. >>>>>=20 >>>>>=20 >>>>> If both ssh:// . . . and https:// . . . fail that likely has >>>>> implications different than if just one form does. >>>>=20 >>>> Looks as if they both fail: >>>>=20 >>>> # git clone --depth=3D1 -o freebsd = ssh://anongit@git.FreeBSD.org/src.git /usr/src >>>> Cloning into '/usr/src'... >>>> remote: Enumerating objects: 104639, done. >>>> remote: Counting objects: 100% (104639/104639), done. >>>> remote: Compressing objects: 100% (88894/88894), done. >>>> remote: Total 104639 (delta 22165), reused 43690 (delta 11830), = pack-reused 0 >>>> Receiving objects: 100% (104639/104639), 345.56 MiB | 1.34 MiB/s, = done. >>>> Resolving deltas: 100% (22165/22165), done. >>>> fatal: missing blob object = '619155cafe9277d1b3fc1bfd02fe76e27042a115' >>>> fatal: remote did not send all necessary objects >>>> #=20 >>>>=20 >>>> Both the "missing blob.." and "pack is corrupt..." messages have = been=20 >>>> seen regularly before. The system is running from microSD, but that >>>> didn't prevent cloning, checking out and building the existing = system >>>> installation. Is there some way to check if the blob object named = is >>>> actually present on the server? If not, that would be a clue. =3D=3D=3D Mark Millard marklmi at yahoo.com