Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 24 Mar 2019 18:49:17 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        Rebecca Cran <rebecca@bluestop.org>
Cc:        Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org>,  "freebsd-arch@freebsd.org" <arch@freebsd.org>
Subject:   Re: Adding a new efi-update-loader script: need help understanding Makefile.inc1 for "make installworld"
Message-ID:  <CANCZdfodhpRcUJoGZs1F3zcXGLAZKh=dVJ_oRGkF=eCV6zUW9Q@mail.gmail.com>
In-Reply-To: <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org>
References:  <642fed43-0535-9ae3-6f01-a943650cd511@bluestop.org> <20190324090103.GO1923@kib.kiev.ua> <e6695237-6a22-3ff0-b113-9efeee05a51a@bluestop.org> <CANCZdfq1vb2-R-R4AZyoqi_940GCooMuhXyjCgSkHSusic5p_w@mail.gmail.com> <5cda4bb9-c10e-2b44-65db-5a9f29f498d8@bluestop.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 24, 2019, 6:20 PM Rebecca Cran <rebecca@bluestop.org> wrote:

> On 3/24/19 5:57 PM, Warner Losh wrote:
>
>
> He's asking for stopping doing a make install in src/stand. I'm thinking
> that's a good thing. We should update the ESP's \efi\freebsd\loader.efi,
> but leave the\efi\boot\bootXXXX.efi alone as part of this new installloader
> phase. Again, only if the ESP is mounted, and we have a default spot for
> it. For this script, I don't think hunting for the ESP is the right way to
> go... which means we need to define a standard place for the ESP to be
> mounted, which we should do before we turn on any of these features.
>
> We have the start of a generic script to update things in
> src/tools/boot/install-boot.sh which was supposed to install boot blocks on
> everything known to run FreeBSD.
>
>
> Only updating \efi\freebsd\loader.efi is the wrong thing to do in my
> opinion: there are situations like on ARM where EFI variables aren't
> persistent, and we need \efi\boot\bootxxxx.efi for booting. What we could
> do is check if QueryVariableInfo returns EFI_UNSUPPORTED, in which case we
> know any changes to BootXXXX variables won't survive a reboot, and we need
> BOOTxxxx.efi.
>
Systems that don't support variables are a super duper weird special case.
Let's not let them drive the design. I want to get to (a) a standardized
mount point and (b) drive people towards having the boot loader be in
/efi/freebsd/loader.efi. our tooling should reflect that first and
foremost. The weirdo, special cases that likely won't be updating from
source are secondary.  Let's get a good design flow down first for the most
common case, one that encourages the most people to adopt the standard boot
flow as possible.

Is it safe to assume there's only a single ESP in the system? Is it not
> normal for there to be one ESP per disk for mirrored configurations, in
> which case each would need to be updated?
>

None of those are safe. We shouldn't look for the ESP to mount. It should
be mounted and we should only update it if it is. DWIM will get us into a
lot of trouble with the boot path, I believe.

Do you envision src/tools/boot/install-boot.sh moving to /usr/sbin, or
> remaining where it is? We'd also need to update the ESP for binary installs
> using freebsd-update
>

Eventually, but it has a ways to go.

Warner

> --
> Rebecca Cran
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfodhpRcUJoGZs1F3zcXGLAZKh=dVJ_oRGkF=eCV6zUW9Q>