From nobody Wed Jun 19 22:56:14 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 4W4Jrr6hWCz5P7mt for ; Wed, 19 Jun 2024 22:56:28 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic315-55.consmr.mail.gq1.yahoo.com (sonic315-55.consmr.mail.gq1.yahoo.com [98.137.65.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 4W4Jrr3w2Kz41p0 for ; Wed, 19 Jun 2024 22:56:28 +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=1718837785; bh=xROADwljh7x/PYFi7mGsaaOaZKVfdWwx32Ich3pTwCE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=JhWQ/+rz/5hXXUyzo283LbcbcHKfKgg+m84G/XZ1pQj3A4WMnat6y9SIkPAZ27YlH8VnXcMiHvgZvVwifWH/ocy17U593hziqp4zajn8uPNSzl4vFwj4ve1hDjpKjFJ5WVGp0e9+JJ6vJYG0Kppxh/ANYeLYxNm0u9lsyXdKgMeqs0yGFBnsdE9uKbgc20ilQgHBRvkPpxdXYIiF+k1lPKjQG0CULxVu7pWkj5W+8mYGuGADbHPZ9Kt4bDH1enVT0OJvSr9Qkqhs9k7574PwTaZOGQgzeNcUQzXP+Jkj+2YXgnYxnxpEwKRAxHk8wZMqoeJ/QjHkwKe7ryz2LSo1mQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1718837785; bh=GN4oreGbNX0DjqBfYWgWYYk32N/3hF1HB1jR3ZNlHtd=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=rMOQU5IxAFRN8PcSY9sTjsnlOOrIDtZpd7YmEHXRYOjY+xI8qjyJCdKavcXxhNIU4ZyRAE9QUb2QQV5VzxcM5neBjldevMdjHHiRYvc0vV/M+w4NYxKxopl+38YnGbuCfgJB7YlPJWeS7nRrTe6ziBkWm5XWyTiShKumdN4LboJVXAssXqYfRW28El9bdCMdevkqM7RnW8CYEC/PFZYnRgT3c0Z8zHffsUFDC+wBcZNoEMZIzm0so0nI//0sS1bcbtJ+YSSe9u1Dh3TQHwZS6a24PwHDP+1EMPT5NLPZ7i/gYUp0VgTrpvbwHwhui0ouUEWKnRwyaDAwqRQx2kBmQQ== X-YMail-OSG: 6e9mi6kVM1nKKH1t4MXJM7UL_lJDDao.yk0RMi2Y99Z5T1Dwdq8uMXoPzFEli9I tTqGHjmIPALhWx0S2Ahbiv2gZhNtEcvNXNQWoiHrPikROVEZjVTUVwWr6HaPq85oVzG93Y1yDa7l 78BOLFlXOQwq34sisECOjDKN_mOgxA6X97BlEHJuLRpS1NiTKulLGa7Nmn8KUr29m1Fcg_SC2xsr VsO3DSMsNoklK8yk51Xr9VDjahZDpZyLts8d914m01ZYrGoIrlOwYw6kew8tu3S33eXvQB__otqx peLa38CkWPosnZPNO4uFqUD_qohQKr_Xm9_LfJqqjj2EUeQYftyxFwx4NwKb6ZrNvIpSV3n5bFSt cmodQ9qlh.E_Y0qqdjJ5ydDXqH1DmZrJ8aPaXC6WSaJfXyBaLMIU0m5odr3Lm09b0tMYARfWezsO NCngy6s9hj.YphZBb8vWAT98z2760q1ljRzTNqzVSvXhKSOh3CNuY4cUGRYxCLQwFkMRlZPx1MA. WNI9Q95Hw4462mugvGC1nbqRI4vvG.3fHOIv9rw9_09yThoQeDQki1O08cgbURaGGGgIdEuyFNkA 3ruwTd90.yO9IyeBsAEYZR.KdyUc4Q5S48ivW49x9vE2lZbGZU7TwGiyDK7BvVFIoZw_uy68vnkR vb_xyPRZgvz8rF40Ge7KqiuhmnckldDLJsaZSZpGz6EJfiw8UXI1R1HcZOvZ4XupoDaMjTX6N_ST tQySIOIiCv3DqwKRBOMDJI._ixR9LkahRYZhUWqsos7Ejqt7Yx7ZpUcqUmg230KMTdUmM_NBTCqf ystvrEN0ur52VXnMPS1UGpeolYba49SwaxAIrUhJB5IWeTPBnlpuhdNOV3OeloqVJPm5AgllzJD5 2pHop1iMszSsTUMYfh1cGFwEPZFBu_wL1UWbuTm1sCRpHvlQUInU_IAWX_pykczgVaNZo.n7bzA2 O9jKu1CHcYAIErj0cUMNtobgGdLIOk_Hln.TzAPpYrGuser6Diy_LJ3zSaq_DC4t.AWHuLAuTU9p RFv39Frnpf84KF5ceO7_SljT1uQ4Jrgc.rcDgAQ_WUSmRm6LQhb1Kk3EnMyuSAF.1JpSOCFQGCMA ZVNOYrd80ML2nBTTVO35KBW5SbOgGcRiznkaiTyenwlhLLxC_gdGufSWaNNTE5gZNKEGTck174xd rWztoBaTi90zSzJ10TYo0sYfMj8pgAEkv3kvx9Bci1bs7DDIxOF4CqBs_ZoNi1J1hgbgf8K4dva1 _WkUyN23b0iOqfphEaVtGSEazTaR6oElf1Ltbqcypg3RIq5iKnt6AbzkIsymi96LivnQYP9rFuh7 v5i9HDWCii5C9d4X2sgqn1vAkyTCqxPlR38PeSXeVNK7gev.imtDK8jIKk7JmWeHQvLbWPx1xbF2 49eqyY1.qhk4O9ovarUcmR21CxRZm9CKsrzHiCmeZlILE9qS2dyZxDt8CCz9DVZ9X9Fr4UHbytGC dEON7JQWIG1t4_nDa.cxt2_W8t7sGo_aW1gEe1NJRBKaKF01E2sfd.zcjRBTeHIRvqlE1yO4f0Jg BWwf83uRuLGD68p9AZpxH3FKBTqLEh3hmm_AdgI7U2RqjaW9XyidE3riI_LTeDk_VuDe3kiZ5ijK Kioyuefx8yGAdeJ2QdXuXnk09_RZQvVUkfUGqx3_VWjgKap4SunIizyJFi3BWAGZxPJth6bqKKph BVQvmyLbjvhG7C_46p430MSv_UDo3M219x_BO5wtLxpF5rm0vRzWO9KcUDmKkoV4OJTuUQ_INymB KHftSEI1hnSxd2JXDVLiPGEEGK1HFMziyduGUuM8M09fFmmU.7JhDP7kBCoAWGu2AFJRS.1xdFpc OUSeLrdKSkoRPBD07xQTslNINhUjzTtTzWp8q.5uTBTTpu3B5linnGvmkII2byYwoT1DQvZQh3.L gGHGotb8AoOE3dKuqlGl5Cly2aF_xJg7YK4N53pEJJZ7FwO0kSJnX1.geuer_xxTkGP2hD1TBWYS MFR8DcurHPxxeMsORVTdnXf9NzgSq0qcApBdfzz5o3ZVCdAcvCLlCUpvMVGRokEclm7_LY_Rf6zS pfVPZb1EEIS7kzg7XHTAxrxMTgHb1ceZiDd8UKzc2_71JvtxtuNHRvmxc9a38Y5BZvHtrO_walOL tgTAyo0CXBey3.ZWm16Lg0PIzeu72fESsfPYoFVUKRfETe65bSWSzMcg8ThgAvZwvQlyBC2e1W5P LnHXVm2aZ_C1_4iOqOAkIDa99xKUZB0dyIhEWADW9Gg4OiKAgY4Ag2SpkyylK7buK4LvQnhgp5HE F44NTQo22B0BZHmAp4NBs X-Sonic-MF: X-Sonic-ID: 0457d456-b2cf-45e8-964d-509c2042f0ab Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.gq1.yahoo.com with HTTP; Wed, 19 Jun 2024 22:56:25 +0000 Received: by hermes--production-gq1-5b4c49485c-ns8tm (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID bcbe2a9e62d58579015fa435e2fc8fb5; Wed, 19 Jun 2024 22:56:25 +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 core dump checking out main on armv7 From: Mark Millard In-Reply-To: Date: Wed, 19 Jun 2024 15:56:14 -0700 Cc: FreeBSD ARM List Content-Transfer-Encoding: quoted-printable Message-Id: <5D5B6739-1685-43F5-80CC-E55603181D09@yahoo.com> References: <7B376999-B84B-459E-B1C4-CC99EEF8D55A.ref@yahoo.com> <7B376999-B84B-459E-B1C4-CC99EEF8D55A@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: 4W4Jrr3w2Kz41p0 On Jun 19, 2024, at 14:32, bob prohaska wrote: > On Wed, Jun 19, 2024 at 12:50:48PM -0700, Mark Millard wrote: >> I see a difference for "22164" vs. "22165" in mine vs. yours: >>=20 >> remote: Total 104639 (delta 22164), reused 43690 (delta 11830), = pack-reused 0 >> Resolving deltas: 100% (22164/22164), done. >>=20 >> vs. yours: >>=20 >> remote: Total 104639 (delta 22165), reused 43690 (delta 11830), = pack-reused 0 >> . . . >> Resolving deltas: 100% (22165/22165), done. >>=20 >>=20 >> My guess here is that you end up at a server that has messed up = content and I do not. >>=20 > The off-by-one sort of makes sense; my host is expecting one more file = than yours. >=20 >> I can end up at: >>=20 >> # traceroute git.FreeBSD.org >> traceroute to gitmir.geo.FreeBSD.org (192.158.248.9), 64 hops max, 40 = byte packets >> . . . >> 14 isc.gigabitethernet1-1-44.switch55.fmt2.he.net (66.160.158.246) = 26.076 ms >> gitmir.fmt.freebsd.org (192.158.248.9) 28.271 ms >> isc.gigabitethernet1-1-44.switch55.fmt2.he.net (66.160.158.246) = 27.410 ms >>=20 >> You might want to try forcing an explicit reference to something = like: >>=20 >> # git clone --depth=3D1 -o freebsd ssh://192.158.248.9/src.git = /usr/src >>=20 >> and see if that makes any difference in your context. >>=20 >=20 > Apparently the numerical address had been used before, as I got an ssh = message > saying it was already known.=20 >=20 > Eventually I tried: > # git clone --depth=3D1 -o freebsd ssh://anongit@192.158.248.9/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 22152), reused 43688 (delta 11830), = pack-reused 0 > Receiving objects: 100% (104639/104639), 345.58 MiB | 1.35 MiB/s, = done. > fatal: pack is corrupted (SHA1 mismatch) > fatal: fetch-pack: invalid index-pack output I recommend trying on the different machines that have sufficient disk space for holding a temporary clone: # git clone --depth=3D1 -o freebsd ssh://anongit@192.158.248.9/src.git = /PATH-TO-NON_EXISTING The explicit 192.158.248.9 is deliberate to avoid variability in that much. 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. 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. > 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