From nobody Fri Apr 1 05:07:23 2022 X-Original-To: freebsd-stable@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 1AA301A50FB7 for ; Fri, 1 Apr 2022 05:07:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KV7T96bQMz3n2c for ; Fri, 1 Apr 2022 05:07:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2d.google.com with SMTP id z134so1630418vsz.8 for ; Thu, 31 Mar 2022 22:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mF2cNTs1Mo7+lOx8xipGmEOGHFRSLWlpdEYXDEDlldc=; b=8VJHS/khX9/7OVX/yOqXM4K/tYVnkJpWzY5JPVvThnDFm5FaYrS/0vkHY4iyzbj8pm FBKJpGv7EAfLFV8vp0XkE0UqDS1xem9332tqb7NqMqCAtYpUJrUoPiE/qBpYd1nM9M7d 2hTNJY+LlHQYl+v0QPY+2gOfo4wLqILQ191kM+yYOFiY90SRBoaN/qK+k+2hsQTmymiW a3p/5/kdwP5KL6ZHb+moeULa6nTYZBBIlILL586kDCsqobBNbkFwcioggp/sCshvqDaG 6VHAmxf7/7C7syzQViQVfWox6afMVEP2kMZhMi6coW/GGP1dOONlGuStzHVEbgWPJEia fChg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mF2cNTs1Mo7+lOx8xipGmEOGHFRSLWlpdEYXDEDlldc=; b=Yg8EWN6o8jrAAFsfiAYwOVoHR2Yuy9YLmFyh/s/wBRxpkM48AJL66Ibqd79PnGle7L fafJSQCEuSclYq1y64l8mEoKepWSnGTPFR4JIAI3S08+bBvyh4TC393GOZUyjcsM9/Wb NUo8xpsxy678VAScANFXu9bS8HzapocSP0muMzqNP1MjfaTyHn8fffGK6Z22CuPVgaQH N8wMFmsatS6w9lIsuybYsN3rIh9OAgUFQQ+PSmU6bb8yLdeQx2/ffokT0AhWuxhVu5XC WKAlhYEYaKd8c9MN23+nXF68mRiNM/n6zNGiruUXj6dL/WWDC39uY6MNqqo/G7OyeWyJ x+FQ== X-Gm-Message-State: AOAM53261mOyg78Cxd8NaUl7TiPJ8e4P+/V1acKyU7Nr/MycgMX66JvE IPQFouGWzr51T/nZwrLYgutV8tKWwzy6bNUBqdT6yUk1+gaWgw== X-Google-Smtp-Source: ABdhPJyGz0DAW7g4LU6DueabJnlUTuhFJD5eNKYMrrba7o/c3fP+EZAOCkn57ifx2/KHNIZLvRjgKomE9mxA+YVhNJQ= X-Received: by 2002:a05:6102:ed0:b0:325:9a2f:579b with SMTP id m16-20020a0561020ed000b003259a2f579bmr2897512vst.77.1648789645045; Thu, 31 Mar 2022 22:07:25 -0700 (PDT) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Thu, 31 Mar 2022 23:07:23 -0600 Message-ID: Subject: Re: 12.1 bootblocks the last known good choice for older Dell h.w To: George Michaelson Cc: FreeBSD Stable Content-Type: multipart/alternative; boundary="0000000000001a45e605db90c1f0" X-Rspamd-Queue-Id: 4KV7T96bQMz3n2c X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="8VJHS/kh"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2d) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2d:from]; NEURAL_HAM_SHORT(-0.50)[-0.498]; MLMMJ_DEST(0.00)[freebsd-stable]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; R_SPF_NA(0.00)[no SPF record]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --0000000000001a45e605db90c1f0 Content-Type: text/plain; charset="UTF-8" On Thu, Mar 31, 2022 at 9:20 PM George Michaelson wrote: > a Dell (not the one with the cam problem I posted about as well today) > refuses to get. beyond BIOS device detection on any bootblocks after > 12.1. > > I've tried every .iso 12.2 through to FreeBSD-Current snapshots, and > they all display the same problem hanging on the bootable drive detect > phase. I don't like running newer kernels on old MBR bootblocks. Maybe > I'm wrong, but I always do gpart bootblocks update for a major FreeBSD > upgrade. > > Is there some debug possible on the MBR boot stage? I see no path in, > to get more message. > You may have to bisect changes in stable/12 to find the answer. I suspect you'll find something that increases the size, making us too big to run on the dell because it has a few fewer bytes and we wind up crashing because of it... But I don't know for sure. Well, the other possibility since it's a silent failure is that we're making a new BIOS call with 12.2 that we didn't in 12.1 and dell's BIOS doesn't like it. > I am loath to over-diagnose this, it is possible /boot/loader.conf is > working but the delay between runtime and output to console means I > "see" the problem as during MBR phase. > > The last thing to happen is the first "/" of the text spandrel is > drawn. That's it. > That would be consistent with my theory of crashing... Usually, though, with mbr-based boot loaders we have btx to catch the exceptions and print a traceback... > There is a BIOS upgrade for this box. Its on a 2020 BIOS, the 2022 > edition appears to be mitigations for CPU attacks, it doesn't mention > any boot time stability issues. > I suspect it won't help, but maybe it will (especially if we're making a bogus BIOS call).... Warner > G > > --0000000000001a45e605db90c1f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Mar 31, 2022 at 9:20 PM Georg= e Michaelson <ggm@algebras.org&g= t; wrote:
a Dell= (not the one with the cam problem I posted about as well today)
refuses to get. beyond BIOS device detection on any bootblocks after
12.1.

I've tried every .iso 12.2 through to FreeBSD-Current snapshots, and they all display the same problem hanging on the bootable drive detect
phase. I don't like running newer kernels on old MBR bootblocks. Maybe<= br> I'm wrong, but I always do gpart bootblocks update for a major FreeBSD<= br> upgrade.

Is there some debug possible on the MBR boot stage? I see no path in,
to get more message.

You may have to bi= sect changes in stable/12 to find the answer. I suspect you'll find som= ething that increases the size, making us too big to run on the dell becaus= e it has a few fewer bytes and we wind up crashing because of it... But I d= on't know for sure. Well, the other possibility since it's a silent= failure is that we're making a new BIOS call with 12.2 that we didn= 9;t in 12.1 and dell's BIOS doesn't like it.
=C2=A0
I am loath to over-diagnose this, it is possible /boot/loader.conf is
working but the delay between runtime and output to console means I
"see" the problem as during MBR phase.

The last thing to happen is the first "/" of the text spandrel is=
drawn. That's it.

That would be con= sistent with my theory of crashing... Usually, though, with mbr-based boot = loaders we have btx to catch the exceptions and print a traceback...
=C2=A0
There is a BIOS upgrade for this box. Its on a 2020 BIOS, the 2022
edition appears to be mitigations for CPU attacks, it doesn't mention any boot time stability issues.

I suspe= ct it won't help, but maybe it will (especially if we're making a b= ogus BIOS call)....

Warner
=C2= =A0
G

--0000000000001a45e605db90c1f0--