Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld"

[Rodney W. Grimes]

> On Mon, Mar 25, 2019, 11:03 PM Rodney W. Grimes <
> freebsd-rwg at gndrsh.dnsmgr.net> wrote:
> > > On Mon, Mar 25, 2019, 9:48 PM Rodney W. Grimes <
> > > freebsd-rwg at gndrsh.dnsmgr.net> wrote:
> > >
> > > > > On 3/25/19 8:05 AM, Warner Losh wrote:
> > > > > > We started installing /boot/loader with install world in FreeBSD
> > -3.x
> > > > and
> > > > > > it has affected the boot ability that whole time... in the early
> > days
> > > > of
> > > > > > loader, the kernel loader handoff protocol was immature enough to
> > need
> > > > a
> > > > > > matched kernel. But that period lasted only a few months...
> > loader has
> > > > > > also been weird in other ways as well, since some embedded systems
> > > > used the
> > > > > > one in its, while others needed an extra step. As UEFI support has
> > > > matured
> > > > > > we're finding there are several issues around it as well where
> > > > updating the
> > > > > > ESP needs to be tied to updating /boot for the system to work
> > > > sometimes. It
> > > > > > has grown more complex over time, so we should separate. It's been
> > a
> > > > little
> > > > > > weird on all the non x86 platforms to different degrees, but now
> > that
> > > > our
> > > > > > main platform is affected it's become clear we may need to change.
> > > > > >
> > > > > > But we need to do so carefully as this violates POLA in a huge
> > way, as
> > > > well
> > > > > > as needing doc changes in a bajillion places.
> > > > >
> > > > > I think we should treat files on the ESP the same way we treat other
> > boot
> > > > > blocks.  installworld should continue to install the latest version
> > into
> > > > > /boot (e.g. /boot/boot that holds UFS boot1 + boot2), but then some
> > other
> > > > > tool is used by the user to copy the updated loader.efi into the ESP.
> > > > >
> > > > > I think the main difference here is that traditionally other boot
> > blocks
> > > > > didn't change very often, so no one really needed to update it them
> > > > > post-install.  loader.efi changes often enough we probably need to
> > > > document
> > > > > updating the ESP as an optional step in the upgrade process.  I think
> > > > > having an automagical script will probably go sideways, but
> > standardizing
> > > > > where to mounting the ESP (or ESPs when doing RAID mirroring, etc.)
> > means
> > > > > we can provide a script with defaults (or instructions) that work
> > with
> > > > > the standardized approach.
> > > >
> > > > Is there anyway to stash an easy to extract "version" in
> > > > loader.* so that a Makefile/.sh script could easily check
> > > > to see that your boot code is == `uname -KU` and just emit
> > > > a warning at the end of installworld?
> > > >
> > >
> > > No. There is no simple version we can check to make sure things are a
> > > matched set..
> >
> > Then I would call that a pretty fatal flaw in design.  There needs
> > to be a way to find out what version of "loader" /boot/loader.efi
> > is there.
> >
> > I was also not asking if we have a way now, I was asking if there
> > was a way to implement, and I doubt the answer to that question is
> > no.
> >
> 
> I know. We've not needed it before, and I'm having trouble seeing it now
> how it is connected to uname -UK. The path forward isn't DWIM. There are
> too many variables. Without DWIM requirements, a tight, buttoned up version
> isn't needed.

I attached it to uname -UK as from an operational standpoint the easy
semi-unique or matching qualifier for compatibilty is exactly that
token.  I am not advocating we enforce a version match, but that
it would certain of helped me several times in the past to know that
my /boot/* files are from 1100122 1100122 and hence need to be updated.

The current BTX 1.1 is bit rot, that value has not changed in ages
and tells me nothing about what boot code I am running, why do we
even output it?

> Warner
> > Warner
> > > > John Baldwin
> > > > Rod Grimes rgrimes at freebsd.org
> > 012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789
> > Why does your mail client wrap my <70 column signature?

> Ask Google.
Your saying gmail is doing this when you reply?  Interesting

> Warner
> > Rod Grimes
> > rgrimes at freebsd.org
-- 
Rod Grimes                                                 rgrimes at freebsd.org