From nobody Thu Oct 12 06:20:10 2023 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 4S5fdV56qNz4xK3L for ; Thu, 12 Oct 2023 06:20:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic304-23.consmr.mail.gq1.yahoo.com (sonic304-23.consmr.mail.gq1.yahoo.com [98.137.68.204]) (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 4S5fdV2BDsz4rKD for ; Thu, 12 Oct 2023 06:20:30 +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=1697091628; bh=xYOcSiDzEIYukechkjD7CDBmBwq5VJYln9GFRU+n7+k=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=FawKUs/PT74CZ59Vdq/BG4+dCBrU/bv+H/DEL9RsNvO2dko0mmluswSUTtuI1XYXZ0DWUmxZJUDSY7gjdNofVeF6MtBBbtL2BPQjp2bospS6UKrbr3eJ6cpvwxDYFRfccgp5qQWULcqFQRd3edW6TlwtraHKYcmdBPiRyNGGyW3QpSqh04tUPC7+zTRvPXZWYm2rSZSc2hRGLQOvRmCrtBJHWZW2SntHsUq0wegZvKKKG10zT7PSGGj55dYN4Z636WG1Vx4vgkWcbxzDszh7eZxc0RL/HznJbGp6KsNRMsCI++Ysgk4GtN+eG2pIy8p2QzG8GDKXZQVP5qUViZXczQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1697091628; bh=ovv3GHXeGcRpGjRyNOSEKZ/86rv09WFNwRlIq5ij+3j=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=jqV+TJ50dzQSpKwcIhhYDYuZLNHkYJQwWd7KAfGBRkKz5VzSu7b7tgalmNhx/qXdXjIys3YHHkNlCVx5FU8vm4VpcVIMihM/L6B/Qn+8T1ASc5+SBkHoCdywoOlIEL3QYnAHIZalzUh0KvvmOpj59K1S3MSKDR08Fbr/cETehzJPwu8JF8uk+ORGTF4O9UNfF0HZHjLP9KkGhaLTgGwJ3NHJLqVqewZrrNf/JmvpSzUsV+0tbYuL8OXgBxOSaTKv5h6gRXIQM6w8f0tT81wX+uty0aILsPlJ1wjPBfBR/sk4wzjRx1/2HueZ5h4jzkcXfo4o65EqapVomqrCzCKaPA== X-YMail-OSG: Vfv3w1sVM1lPt1K9ca_e5wU8.mFdDj4C86ssD4PAY6BW_9ph.3_5hG7uWHZIHC_ qeinNFRmgtnnUAVmzlHIoR4MByk_i4t_f5syC_ea.wBAs3ra4.l.etJWAkR2lKZ7P7KsfTP_kya5 mGB1ruWsCa9ZnRK7lQa5j3s5f.WOtK7Hc8SSPT_OxVGXOm4mvqP_LqB30V.4RYu7HSyfjA64Eee8 wI2Bxg5rUvkus.LglX4AyvtHuAHztIYVHBGPcO7FVfNCqcxQus27vL16BFtW.hnzPfXFl2h8q8NS K.YOTPNlPyHdx3g9Qz8yrnknTV_B.UI5xYyz_wYqu9WBEQftAvdPSKVFXMzjclGMTct4OPsoEn2G XqM1tjpVqWlHXpXr1kRrm6P8VcQ6bQgIDFvmQMCfEkWoYqUEAONC46CE_1bVnssM4X3Z3aoaMbrf Mcp0Y8KDq5F_U41iqL03m2MbSNaz4cy9NYZm2fJLGPb2KnlLnxVBzKfCTmJdaivSRixHHWtmemhG RwW6h.Pqueba8ggPEGmczRineYB3wNVRT9xDYwKNLV_UJD6KTn9YHhjSJlkUIXLyPvuLFDC5Y2Rf ADQXoChUMFLuK0sZu9XJvcjvJjitDvi332MYW7xe7h2DN97d5mqhgtb6iZmejOGMw8AGmcOB0Se. hwytT9KkgzH3txQTRSGkmOE7Vl1VCHlz_VVTEu.my5mKqK_Fc8tQ9HdT57ECWhJDpaj18Zh0MXUt JyeImehxbXqid0Mvn7pOykTVWgF4H6DeDUDPkoUt.Zn4F4M5VYKUhHQPbMk6LrygYkTW.Qs7OG1t aJWxfDrCGQMw.2ObrvKSKuhVUaWZ5.0.EAgp4uLASNcz0qi2AtAbleWe87B6a3DETE8W23V20evM t9tklBcv_Vb4Mj3W47WTeGgmQHSKq3a2GaSN1kyzpJ5shPHAxbE5kT93TuCDgEWqHKJCF_l1vN_x d6pHg.eln6nbDEO88e5RstdVtSYQBN0LmmUETcjdkIR7FA78HD9f_duCPd7kp66zHIy4o4dxa8.1 i_i1.Gh2aOXTuZ6G4r8UKDOjZWtunXOiBXA3jD4p2d.Ht6gIb5G2zj5DXnrYcvDRlrOgSYlO1Dkt u2jsPgrRfkseXoK_.h__7Pbsr7_4VSdYJpVftlJ5A3c1BwlIh.jjMVSg9Iat6zV0hJgn36FD2MDR rLTp35mdC_I.iv.6LEiyRV8Pf.2a3ASxWWPzoxwn_Di4_OXy9Ugwn8L2f_cSr_MncF1Oz.PBWp.G Nn_N.42dEeh8rV0ES.ZpMGPFo55pQEoJ.Zx7wpKvZiDCSUfeg.uViNO2lWkxOv.YlVxptnijBAES 4JFHeZ4vreg7vVt4JNND6hPK5sTLahwSpRxDGYvlPsGbb.r4DhSd5M5fbXNwgBPqRQ0AmUwMFWfz 8nw74ja9JstSaXUF8_ROMUbkmhW_y0ElKLCL5xntaMEcz0gg6P8BDKRURoOwxGUZpH2aOv1c4I0n ZmyMwaTw_J3UjDt9I1wgPA8CNvsgoy2iMebdA87DN2E1zoF50KsB2Y_pWgezf.u.g7G74FY0IowL 2zw7L_Lp6egq8W98xPn8uJJPK17pV2XXCdExZKCK7GydS56HD4wBqA_FqhuyvRqu8qKt5uj92bd. Q6Rh6tBQQtFS4n1Za2WG2nFkUp7tkguR31FgslaJdvoK5qaRMhtYHuxNvD_Eb6Oe9En24uiFdD3g ECTtKZIYLEoFyf49Ks71zMt7yBkSYiodU7KQzJXSDbJvLZoi17eNy3fT7DteygM8sHD1N2GKPXLa Ax7bEyjYz1eIiMkN0S0EvEP4Y.k4.QAXaWcFXp4SiKG6lK68umzeN40.9f9bBMh05HgAokdO6zfa i.WOhbk3_4HPR7VhvR5fGKgjF5Yf67thbQqXpu8fY3uU67qmmT3jF5eYGFoRUMS74FDCTCAiU7Xj khCRCGtm.ASnpGImHr76rlzH7LOamfuvAVDs43lv6DLl7z4ymm1XZ96X7aRG65nVOoCAuc4lHrKq CN85TkmkLxaEg5LvKz3ffjQv1ZQEv0n0z3YgYn0tb_wl9yVcgGhmwWEBAR32zE8Uye57DwXGkIEi b5nRzR9IOXBiM.kgHJTjXpNGM69WTKbo4pYY70gfYnSMmNJamYoovChbEj0hS0pcngD69KPACWAK ok0eiNQKeYsiWARries7gXVHw5_3JyFuh3sZQfTnLvIfqfev3wawji6AikiAUVCzYtYxwp674Z_z 92M21ZlNwVdZ0qxKYMkEmNee8mK1iun2J0YP2JYW4_u3oi2KqrI8EpzTte_7nM6X.4Lvxt.O4 X-Sonic-MF: X-Sonic-ID: 13d77d96-b0e5-4257-94a1-7f2ab7882488 Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.gq1.yahoo.com with HTTP; Thu, 12 Oct 2023 06:20:28 +0000 Received: by hermes--production-bf1-74bfc65597-hc4hf (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID faf8f8872cbc0d86362f83a990f0de1b; Thu, 12 Oct 2023 06:20:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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.100.2.1.4\)) Subject: Re: unable to boot latest 14-stable From: Mark Millard In-Reply-To: Date: Wed, 11 Oct 2023 23:20:10 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4DAF934C-BCED-4096-869E-405F5A539BC1@yahoo.com> References: <841CA663-55E0-4EAD-B700-66DC884B50FA@yahoo.com> <55C64D6A-2712-408A-B7A7-BA8081CA99FC@yahoo.com> <005C6B77-2ED1-4FA9-9A6D-B97FB9E8ADD8@yahoo.com> To: void X-Mailer: Apple Mail (2.3774.100.2.1.4) 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: 4S5fdV2BDsz4rKD On Oct 11, 2023, at 21:34, void wrote: > Hi Mark, Hello. > I think the zpool upgrade thing is a red herring, a symptom of the = root cause. You reported text showing the loader's message about rejecting the attempted use. That text was from before the FreeBSD kernel had been loaded: QUOTE Consoles: EFI console=20 GELI Passphrase for disk0p3:=20 Calculating GELI Decryption Key for disk0p3: 422818 iterations... ZFS: unsupported feature: com.delphix:head_errlog ZFS: pool zroot is not supported Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p1: FreeBSD/arm64 EFI loader, Revision 1.1 Command line arguments: loader.efi END QUOTE You also reported that replacing the msdosfs content fixed the problem, if I understand right. That in turn means that only that material changed and the FreeBSD kernel/world did not change via that specific update, if I understand right. If you still have access to the loader vintage from before that msdosfs update, you could put just that one file back and see what happens. (This would cross check on if other msdosfs content was somehow involved.) > On the 30th September the machine was upgraded from 13-stable of that = date to 14-stable of that date. When it became 14-stable, zpool was = upgraded. >=20 > In the days between then and 11th October, the machine was rebooted = several times, > each time it came back up normally. >=20 > Around the 10-11th October, sources were updated and a new buildworld = etc cycle > happened, installing a slightly later 14-stable version. >=20 > The boot failure would seem to indicate the msdos materials needed for = booting > changed between the 30th Sept and 10-11th October. Either that or = something > the materials invoke on the zfs side of things. What all did you change vs. not change when you did the msdosfs content update? Did you change anything else? (I'm presuming not.) > The problem I'm having > is that I cannot find anything relevant for this on cgit in the = timeframe This I do not understand. The loader's build would be dependent on the openzfs source code. =46rom what I see you are indicating that the Sept-30 stable/13 to stable/14 conversion had the openzfs source code from the following: =E2=80=A2 Sun, 24 Sep 2023 . . .=20 =E2=80=A2 git: 6cfb90c6ebe4 - stable/14 - zfs: merge = openzfs/zfs@5f3069867 (zfs-2.2-release) into stable/14 Martin Matuska but did not have the openzfs source code from either of the following: Wed, 04 Oct 2023 =E2=80=A2 . . . =E2=80=A2 git: a21cb0234b89 - stable/14 - zfs: merge = openzfs/zfs@8015e2ea6 (zfs-2.2-release) into stable/14 Martin Matuska Sun, 08 Oct 2023 =E2=80=A2 git: fdc38bc6cd28 - stable/14 - zfs: merge = openzfs/zfs@2407f30bd (zfs-2.2-release) into stable/14 Martin Matuska So, unless you have analyzed that source code to know that none of that more recent source code was involved in the loader's build, there was plunty of opportunity for the loader to have changed behavior by openzfs source changing. Nothing about that needs to get to the stage were the kernel is loaded and started in order for there to be a potential difference loader behavior. > and there's no mention of anything relevant to this in UPDATING, so I = can't anticipate the problem happening again. UPDATING does not document all the implications of openzfs bugs or fixes to openzfs bugs. (Similarly for FreeBSD's own bugs, although more is likely know for them.) As far as I know, no one tries to figure out all those implications. As far as I can see, reducing the risk at issue is best handled by 2 things both being done, as has been stated in various ways multiple times: A) Always updating the loader just before doing the pool upgrade. B) Delaying the pool upgrade until others have tested it out well over a = notable time. (There is no implication about delaying the updates to FreeBSD, just delaying the pool upgrades.) =3D=3D=3D Mark Millard marklmi at yahoo.com