Date: Sat, 3 Aug 2024 21:51:49 -0600 From: Warner Losh <imp@bsdimp.com> To: bob prohaska <fbsd@www.zefox.net> Cc: Mark Millard <marklmi@yahoo.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: BOOT LOADER IS TOO OLD. PLEASE UPGRADE. Message-ID: <CANCZdfrR6KbixK9ubReXQv2Ak%2BNVuCxO6V8S3Mv91S3hLkXayA@mail.gmail.com> In-Reply-To: <Zq5-TZs86Kfkf2Rk@www.zefox.net> References: <Zq2Tn6XycReuifF6@www.zefox.net> <D4358DC6-E1FD-4558-80CF-1A0F62CBE58F@yahoo.com> <Zq25RlA8XtCJetH-@www.zefox.net> <FA91BB64-A9B3-485B-9BC9-6C8426AB50A5@yahoo.com> <Zq4-jgWn9FTEyNc2@www.zefox.net> <CANCZdfqb%2Bs0f3QuVAHzY54wg=9TrvLXrJ2VgnznFbjhA8JHUUA@mail.gmail.com> <Zq5-TZs86Kfkf2Rk@www.zefox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000095c2a8061ed37b54 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 3, 2024 at 1:00=E2=80=AFPM bob prohaska <fbsd@www.zefox.net> wr= ote: > On Sat, Aug 03, 2024 at 08:47:54AM -0600, Warner Losh wrote: > > On Sat, Aug 3, 2024, 8:28=E2=80=AFAM bob prohaska <fbsd@www.zefox.net> = wrote: > > > Is there some reason installworld (or some other make target) doesn't > > > do this by default? The msdos filesystem is mounted and writeable any > > > time the host is running. > > > > > > > > > I have the doodle of a design to have a make installboot that would do = it > > based on parameters set for their system. But i got bogged down when > uboot > > and powerpc ofw got into the mix. > > Could the problem be made less intractable by limiting the scope per > board or board family? I've not played with any but Raspberry Pi in > the past 9 years so have little idea what's in use today. > Well, not really... But writing one for just UEFI isn't terrible for the typical case. We set loader variables in EFI variable space to say what the loader was. So we can look at them to see. We can translate the path to the actual ESP that was updated, and we can know the full path to the last booted thing. But... there's a fair amount of variation even in that. Some safeguards are needed. We know the path of what booted, but we don't necessarily know what the .efi file in FreeBSD is that needs to be copied over. And that's before we have the 'old bootloader' from FreeBSD 11 or earlier that doesn't have a big enough ESP to do the upgrade. Most of these failure cases though we just need to fail-safe: Sorry, you can't upgrade automatically. Really old loaders don't set the variables, So we'd have to fall back to looking at efibootmgr -v to work it out. armv7 and some systems that don't have efi will both have problems, since we can't get the efi variables we want. So do you puzzle out these, or ??? And finally, even if we know exactly what to upgrade and where, there's several people that have mirrored setups, exiter explicitly or implicitly. So should a uefi-update handle some or all of these cases? With or without explicit fallbacks? Should unmounted ESPs be mounted for a minute to do the update? Maybe I'm overthinking this, eh? Warner p.s. the uboot stuff was even more of a convoluted mess. --00000000000095c2a8061ed37b54 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 Sat, Aug 3, 2024 at 1:00=E2=80=AFP= M bob prohaska <<a href=3D"mailto:fbsd@www.zefox.net">fbsd@www.zefox.net= </a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:= 0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">= On Sat, Aug 03, 2024 at 08:47:54AM -0600, Warner Losh wrote:<br> > On Sat, Aug 3, 2024, 8:28=E2=80=AFAM bob prohaska <<a href=3D"mailt= o:fbsd@www.zefox.net" target=3D"_blank">fbsd@www.zefox.net</a>> wrote:<b= r> > > Is there some reason installworld (or some other make target) doe= sn't<br> > > do this by default? The msdos filesystem is mounted and writeable= any<br> > > time the host is running.<br> > ><br> > <br> > <br> > I have the doodle of a design to have a make installboot that would do= it<br> > based on parameters set for their system. But i got bogged down when u= boot<br> > and powerpc ofw got into the mix.<br> <br> Could the problem be made less intractable by limiting the scope per <br> board or board family? I've not played with any but Raspberry Pi in<br> the past 9 years so have little idea what's in use today. <br></blockqu= ote><div><br></div><div>Well, not really...</div><div><br></div><div>But wr= iting one for just UEFI isn't terrible for the typical case. We set</di= v><div>loader variables in EFI variable space to say what the loader was. S= o</div><div>we can look at them to see. We can translate the path to the ac= tual ESP</div><div>that was updated, and we can know the full path to the l= ast booted thing.</div><div><br></div><div>But... there's a fair amount= of variation even in that. Some safeguards</div><div>are needed. We know t= he path of what booted, but we don't necessarily</div><div>know what th= e .efi file in FreeBSD is that needs to be copied over. And</div><div>that&= #39;s before we have the 'old bootloader' from FreeBSD 11 or earlie= r</div><div>that doesn't have a big enough ESP to do the upgrade. Most = of these failure</div><div>cases though we just need to fail-safe: Sorry, y= ou can't upgrade automatically.</div><div><br></div><div>Really old loa= ders don't set the variables, So we'd have to fall back to looking<= /div><div>at efibootmgr -v to work it out.<br></div><div><br></div><div>arm= v7 and some systems that don't have efi will both have problems,</div><= div>since we can't get the efi variables we want. So do you puzzle out<= /div><div>these, or ???</div><div><br></div><div>And finally, even if we kn= ow exactly what to upgrade and where, there's</div><div>several people = that have mirrored setups, exiter explicitly or implicitly.</div><div><br><= /div><div>So should a uefi-update handle some or all of these cases? With o= r without</div><div>explicit fallbacks? Should unmounted ESPs be mounted fo= r a minute to do</div><div>the update?</div><div><br></div><div>Maybe I'= ;m overthinking this, eh?</div><div><br></div><div>Warner</div><div><br></d= iv><div>p.s. the uboot stuff was even more of a convoluted mess.<br></div><= /div></div> --00000000000095c2a8061ed37b54--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrR6KbixK9ubReXQv2Ak%2BNVuCxO6V8S3Mv91S3hLkXayA>