Re: 12.1 bootblocks the last known good choice for older Dell h.w

From: Warner Losh <imp_at_bsdimp.com>
Date: Fri, 01 Apr 2022 05:07:23 UTC
On Thu, Mar 31, 2022 at 9:20 PM George Michaelson <ggm@algebras.org> 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
>
>