From nobody Mon May 30 22:34:32 2022 X-Original-To: current@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 C72281B5B3EE for ; Mon, 30 May 2022 22:34:36 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LBqwC16vNz4Yvs for ; Mon, 30 May 2022 22:34:35 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id vi4ons8RcwtwGvnxznrinM; Mon, 30 May 2022 22:34:27 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id vny5nfv11yz1uvny5nD33a; Mon, 30 May 2022 22:34:34 +0000 X-Authority-Analysis: v=2.4 cv=J4G5USrS c=1 sm=1 tr=0 ts=6295467a a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=oZkIemNP1mAA:10 a=HHGDD-5mAAAA:8 a=7Qk2ozbKAAAA:8 a=JAf30KXuAAAA:8 a=BWvPGDcYAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=4VOk7pbHtyGBV5aI4CYA:9 a=JOWeiY5itpwPQvuQ8dm/GawRuwE=:19 a=CjuIK1q_8ugA:10 a=1lyxoWkJIXJV6VJUPhuM:22 a=GEL62FyrTCmHtEug2d3R:22 a=pxhY87DP9d2VeQe4joPk:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id E3678371; Mon, 30 May 2022 15:34:32 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id D91C518F; Mon, 30 May 2022 15:34:32 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Warner Losh cc: Toomas Soome , David Wolfskill , FreeBSD Current Subject: Re: Loader can't find /boot/ua/loader.lua on UFS after main-n255828-18054d0220c In-reply-to: References: <7BEE44CC-4D31-4CBC-BC12-9A327424299C@me.com> Comments: In-reply-to Warner Losh message dated "Mon, 30 May 2022 08:16:20 -0600." List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 May 2022 15:34:32 -0700 Message-Id: <20220530223432.D91C518F@slippy.cwsent.com> X-CMAE-Envelope: MS4xfLub0arT+ey2AKK5z58lno8qJXQaQa0ATb0uqXQ7XGVW/pQOFxovMxLsH7/KjKV2Y0A8sG6hqDnqYEmXrkIOSfo+lwcIKj3qtEY33fQHs03Sly+huY08 eXOchOWExW27X3ndu0JVRjPrYwQNxr6BxkUpyk6Bd9aPJWJeLC1xSsu92Ly2c/msjGG0jTG1VI3+PEPsUW6jY9nk03FMtW+Z/UDZ+ADUGy9A+Du3vhkZ9C9I EhOafVBNIeX3ZtqfKcmBn5tHNGg4ptEHkDKhI6gsSr0= X-Rspamd-Queue-Id: 4LBqwC16vNz4Yvs X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.32) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.80 / 15.00]; HAS_REPLYTO(0.00)[Cy.Schubert@cschubert.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.32:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[70.66.148.124:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[current]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_CC(0.00)[me.com,catwhisker.org,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N In message , Warner Losh writes: > --0000000000008495bd05e03b4d42 > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Mon, May 30, 2022 at 8:14 AM Toomas Soome wrote: > > > > > > > On 30. May 2022, at 17:06, Warner Losh wrote: > > > > > > > > On Mon, May 30, 2022 at 4:26 AM David Wolfskill > > wrote: > > > >> On Mon, May 30, 2022 at 08:40:10AM +0300, Toomas Soome wrote: > >> > ... > >> > Does loader_4th have same issue? > >> > .... > >> > >> I don't know; I hadn't tried it. I will do so later today & report > >> back. > >> > > > > So if it's only one system, and it's only UFS, then what does fsck of tha= > t > > UFS system tell you? > > The loader can't find its UFS filesystem to read the configuration from. > > So either its having trouble > > finding the device (unlikely since that code hasn't changed in a long > > time), or its having heartburn > > with the UFS system for some reason it's being silent about (within the > > realm of possibilities because > > there might be an unknown edge case in Kirks recent UFS integrity > > changes). I suspect that the 4th > > boot loader will have the same issue, but a different error message. > > > > Others have reported issues with GELI, but that's not in play here, If I'= > m > > reading this correctly. Right? > > > > Warner > > > > > > Ye, thats why I was asking about loader_4th. I=E2=80=99m trying to spot t= > he issue > > from ufs image sample. > > > > I thought it was a good suggestion. My guess on it not working wasn't to > imply it wasn't. Backing out 076002f24d35962f0d21f44bfddd34ee4d7f015d restored the one machine of mine that did have the problem. The other three were fine with that commit. To summarize, things I tried: - Reinstall all boot blocks. - set currdev to my USB rescue disk, ls works, boots fine - boot from my USB rescue disk, set currdev to the boot disk, boots - boot from the USB rescue disk, copy /boot/loader* to the boot disk, works around the problem. - Revert 076002f24d35962f0d21f44bfddd34ee4d7f015d resolves the problem. Other data points: My three AMD machines on Asus motherboards had no problem with the commit. My Acer laptop with Intel CPU suffered the same problem. Could it be that malloc() worked on the Asus/AMD machines while it failed on the Acer/Intel laptop? If my hunch that this may be caused by a malloc() failure, would it be a good idea to print a nasty warning when malloc failures in loader occur? Because silently failing, resulting in weird behaviour is more of a POLA than a nasty message. If not this, a loader variable to enable verbose messages might help in debugging these kinds of problems. Again, this assumes my hunch that it's a malloc() failure is what actually happened. -- Cheers, Cy Schubert or FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=0