Date: Thu, 31 Mar 2022 23:07:23 -0600 From: Warner Losh <imp@bsdimp.com> To: George Michaelson <ggm@algebras.org> Cc: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: 12.1 bootblocks the last known good choice for older Dell h.w Message-ID: <CANCZdfpvWJSHFBQ480i3iagOovqa=xD7g_cWYNm1cBRoHjgzZQ@mail.gmail.com> In-Reply-To: <CAKr6gn2u4BoSSHHWaiyD3BefUvgyCtg-gR55tS3G4DqHCuREdA@mail.gmail.com> References: <CAKr6gn2u4BoSSHHWaiyD3BefUvgyCtg-gR55tS3G4DqHCuREdA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000001a45e605db90c1f0 Content-Type: text/plain; charset="UTF-8" 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 > > --0000000000001a45e605db90c1f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 31, 2022 at 9:20 PM Georg= e Michaelson <<a href=3D"mailto:ggm@algebras.org">ggm@algebras.org</a>&g= t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">a Dell= (not the one with the cam problem I posted about as well today)<br> refuses to get. beyond BIOS device detection on any bootblocks after<br> 12.1.<br> <br> I've tried every .iso 12.2 through to FreeBSD-Current snapshots, and<br= > they all display the same problem hanging on the bootable drive detect<br> 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.<br> <br> Is there some debug possible on the MBR boot stage? I see no path in,<br> to get more message.<br></blockquote><div><br></div><div>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.<br></div><div>=C2=A0</= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"> I am loath to over-diagnose this, it is possible /boot/loader.conf is<br> working but the delay between runtime and output to console means I<br> "see" the problem as during MBR phase.<br> <br> The last thing to happen is the first "/" of the text spandrel is= <br> drawn. That's it.<br></blockquote><div><br></div><div>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...<br></d= iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> There is a BIOS upgrade for this box. Its on a 2020 BIOS, the 2022<br> edition appears to be mitigations for CPU attacks, it doesn't mention<b= r> any boot time stability issues.<br></blockquote><div><br></div><div>I suspe= ct it won't help, but maybe it will (especially if we're making a b= ogus BIOS call)....<br></div><div><br></div><div>Warner<br></div><div>=C2= =A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e= x;border-left:1px solid rgb(204,204,204);padding-left:1ex"> G<br> <br> </blockquote></div></div> --0000000000001a45e605db90c1f0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpvWJSHFBQ480i3iagOovqa=xD7g_cWYNm1cBRoHjgzZQ>