Re: 12.1 bootblocks the last known good choice for older Dell h.w
- In reply to: George Michaelson : "12.1 bootblocks the last known good choice for older Dell h.w"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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 > >