Date: Sat, 3 Aug 2024 08:47:54 -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: <CANCZdfqb%2Bs0f3QuVAHzY54wg=9TrvLXrJ2VgnznFbjhA8JHUUA@mail.gmail.com> In-Reply-To: <Zq4-jgWn9FTEyNc2@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>
next in thread | previous in thread | raw e-mail | index | archive | help
--000000000000257371061ec88841 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Aug 3, 2024, 8:28=E2=80=AFAM bob prohaska <fbsd@www.zefox.net> wrot= e: > On Fri, Aug 02, 2024 at 11:08:36PM -0700, Mark Millard wrote: > > > > > > On Aug 2, 2024, at 21:59, bob prohaska <fbsd@www.zefox.net> wrote: > > > > > On Fri, Aug 02, 2024 at 09:02:46PM -0700, Mark Millard wrote: > > >> On Aug 2, 2024, at 19:19, bob prohaska <fbsd@www.zefox.net> wrote: > > >> > > >>> After a build/install of -current on a Raspberry Pi 2 (so, armv7) > the > > >>> console output reported: > > >>> > > >>> > ********************************************************************** > > >>> > ********************************************************************** > > >>> ***** > ***** > > >>> ***** BOOT LOADER IS TOO OLD. PLEASE UPGRADE. > ***** > > >>> ***** > ***** > > >>> > ********************************************************************** > > >>> > ********************************************************************** > > >>> > > >>> The statement is likely true, but it's a bit hard to guess exactly > > >>> what needs upgrading. The boot process succeeded. Is it wiser to > > >>> heed the command, or leave well enough alone? AFAIK there's no > > >>> firmware to upgrade on the Pi2. > > >> > > >> The message is about the likes of: > > >> > > >> RPi2 v1.1 (armv7)? /boot/efi/EFI/BOOT/bootarm.efi > > >> RPi2 v1.2 (aarch64)? /boot/efi/EFI/BOOT/bootaa64.efi > > >> > > >> Those are not RPi* firmware, nor armstub* , nor are they U-Boot. > > >> > > >> They are code from FreeBSD: FreeBSD UEFI loader code. So, yes, > > >> there is new code to update to. > > >> > > > Where can I find the newer version? Following buildworld/kernel > > > find / -name bootarm.efi > > > locates only > > > /boot/msdos/EFI/BOOT/bootarm.efi > > > which I imagine is the obsolete version. > > > > > > Apologies if this is naive, something suggests it might be.... > > > > Presuming a self-hosted build was done and was installed to > > update that system, the updates could be done via: > > > > > > On armv7 (RPi2 v1.1 --or RPi2 v1.2 used with an armv7 kernel/world): > > > > # cp /boot/loader.efi /boot/efi/EFI/BOOT/bootarm.efi > > In this case the path turns out to be > /boot/msdos/EFI/BOOT/bootarm.efi but the fix was otherwise trivial. > It was surprising to find the old file dated Jul 2 2020, I didn't > realize the machine has been up that long. > > > > > In other words, they are copies of the FreeBSD boot loader > > but under other path and naming conventions on the msdosfs > > that is involved. > > > > 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. > Except it's not. When FreeBSD first did UEFI support we did it in the half assiest way possible. We had a file that was a FAT that would get dd'd onto the ESP. So, this was never mounted. That is mistake #1. The boot loader could never grow. Nor change, really. Or get any new functionality. Oh, and it was a copy of the loader.efi, but without the scripting. It was a total mess that barely worked for UFS. So, there never was a standard place to mount it early on. Plus some people think having the ESP mointed was bad. So for years we argued about even whether or not to mount it. Plus, there are two places yhat loader.efi can go. One is in /efi/boot/bootXxx.efi. this is the place the BIOS looks for it on removable media. But is terrible for multiboot. So we implemented the efiboitmgr protocol and put it in /efi/freebsd/loader.efi. efibootmgr lets it be anywhere. Also, there are still systems that use boot1.efi which are impossible to change. So what do we update in installworld? How do we deal with all the cases needing some level dwim, but guessing about the boot loader is high stakes. It doesn't take too many wrong guesses to really frustrate and drive away a lot of users. 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. Warner Thank you very much! > > bob prohaska > > > --000000000000257371061ec88841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" = class=3D"gmail_attr">On Sat, Aug 3, 2024, 8:28=E2=80=AFAM 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:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex">On Fri, Aug 02, 2024 at 11:08:36PM -07= 00, Mark Millard wrote:<br> > <br> > <br> > On Aug 2, 2024, at 21:59, bob prohaska <<a href=3D"mailto:fbsd@www.= zefox.net" target=3D"_blank" rel=3D"noreferrer">fbsd@www.zefox.net</a>> = wrote:<br> > <br> > > On Fri, Aug 02, 2024 at 09:02:46PM -0700, Mark Millard wrote:<br> > >> On Aug 2, 2024, at 19:19, bob prohaska <<a href=3D"mailto:= fbsd@www.zefox.net" target=3D"_blank" rel=3D"noreferrer">fbsd@www.zefox.net= </a>> wrote:<br> > >> <br> > >>> After a build/install of -current on a Raspberry Pi 2 (so= , armv7) the <br> > >>> console output reported:<br> > >>> <br> > >>> *********************************************************= *************<br> > >>> *********************************************************= *************<br> > >>> *****=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *****<br> > >>> *****=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BOOT LOADER= IS TOO OLD. PLEASE UPGRADE.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *****<br> > >>> *****=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 *****<br> > >>> *********************************************************= *************<br> > >>> *********************************************************= *************<br> > >>> <br> > >>> The statement is likely true, but it's a bit hard to = guess exactly<br> > >>> what needs upgrading. The boot process succeeded. Is it w= iser to<br> > >>> heed the command, or leave well enough alone? AFAIK there= 's no<br> > >>> firmware to upgrade on the Pi2.<br> > >> <br> > >> The message is about the likes of:<br> > >> <br> > >> RPi2 v1.1 (armv7)?=C2=A0 =C2=A0/boot/efi/EFI/BOOT/bootarm.efi= <br> > >> RPi2 v1.2 (aarch64)? /boot/efi/EFI/BOOT/bootaa64.efi<br> > >> <br> > >> Those are not RPi* firmware, nor armstub* , nor are they U-Bo= ot.<br> > >> <br> > >> They are code from FreeBSD: FreeBSD UEFI loader code. So, yes= ,<br> > >> there is new code to update to.<br> > >> <br> > > Where can I find the newer version?=C2=A0 Following buildworld/ke= rnel<br> > > find / -name bootarm.efi<br> > > locates only<br> > > /boot/msdos/EFI/BOOT/bootarm.efi<br> > > which I imagine is the obsolete version. <br> > > <br> > > Apologies if this is naive, something suggests it might be....<br= > > <br> > Presuming a self-hosted build was done and was installed to<br> > update that system, the updates could be done via:<br> > <br> > <br> > On armv7 (RPi2 v1.1 --or RPi2 v1.2 used with an armv7 kernel/world):<b= r> > <br> > # cp /boot/loader.efi /boot/efi/EFI/BOOT/bootarm.efi<br> <br> In this case the path turns out to be <br> /boot/msdos/EFI/BOOT/bootarm.efi but the fix was otherwise trivial.<br> It was surprising to find the old file dated Jul 2 2020, I didn't<br> realize the machine has been up that long.<br> <br> > <br> > In other words, they are copies of the FreeBSD boot loader<br> > but under other path and naming conventions on the msdosfs<br> > that is involved.<br> ><br> <br> Is there some reason installworld (or some other make target) doesn't<b= r> do this by default? The msdos filesystem is mounted and writeable any <br> time the host is running.<br></blockquote></div></div><div dir=3D"auto"><br= ></div><div dir=3D"auto">Except it's not.</div><div dir=3D"auto"><br></= div><div dir=3D"auto">When FreeBSD first did UEFI support we did it in the = half assiest way possible. We had a file that was a FAT that would get dd&#= 39;d onto the ESP. So, this was never mounted. That is mistake #1. The boot= loader could never grow. Nor change, really. Or get any new functionality.= Oh, and it was a copy of the loader.efi, but without the scripting. It was= a total mess that barely worked for UFS.</div><div dir=3D"auto"><br></div>= <div dir=3D"auto">So, there never was a standard place to mount it early on= . Plus some people think having the ESP mointed was bad. So for years we ar= gued about even whether or not to mount it.</div><div dir=3D"auto"><br></di= v><div dir=3D"auto">Plus, there are two places yhat loader.efi can go. One = is in /efi/boot/bootXxx.efi. this is the place the BIOS looks for it on rem= ovable media. But is terrible for multiboot. So we implemented the efiboitm= gr protocol and put it in /efi/freebsd/loader.efi. efibootmgr lets it be an= ywhere.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Also, there are = still systems that use boot1.efi which are impossible to change.</div><div = dir=3D"auto"><br></div><div dir=3D"auto">So what do we update in installwor= ld? How do we deal with all the cases needing some level dwim, but guessing= about the boot loader is high stakes. It doesn't take too many wrong g= uesses to really frustrate and drive away a lot of users.</div><div dir=3D"= auto"><br></div><div dir=3D"auto">I have the doodle of a design to have a m= ake 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.</div><di= v dir=3D"auto"><br></div><div dir=3D"auto">Warner</div><div dir=3D"auto"><b= r></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"g= mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l= eft:1ex"> Thank you very much!<br> <br> bob prohaska<br> <br> <br> </blockquote></div></div></div> --000000000000257371061ec88841--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqb%2Bs0f3QuVAHzY54wg=9TrvLXrJ2VgnznFbjhA8JHUUA>