On Sat, 9 Mar 2024 at 09:59, Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:
> On 05/03/2024 at 00:58, Luca Boccassi wrote:
> > On Mon, 4 Mar 2024 at 23:28, Steve McIntyre <st...@einval.com> wrote:
> >>
> >> What's your plan for installing as the secondary boot loader for shim
> >> to call?
> >
> > 'bootctl update' already recognises and prefers foo.efi.signed if
> > present, so installing to the ESP is easy (PR still doesn't add the
> > call, will probably add a trigger).
> >
> > But as you know Shim right now compiles in the filename of the second
> > stage, so for now interested testers will have to manually rename the
> > file in the ESP from systemd-bootx64.efi to grubx64.efi, which is of
> > course not ideal - let's call it a technological preview.
> What about the installation of shim files into the ESP along with
> systemd-boot ? Does bootctl take care of it ? If no, are there any plans
> to integrate it ?

It does not, there are plans to extend it to do so but it needs 2
things to happen in shim first:

- support runtime configuration of second stage, rather than just
build time - ie, we definitely do not want our tools to install
'grubx64.efi' as that would be invading someone else's namespace
- support providing a version in the PE header so that updates can be
done too, not just first installations


> Also, are there any plans to support multiple ESPs for boot redundancy
> (e.g. in software RAID setups) ?

It's been asked multiple times, but nobody implemented it so far:


Thing is, because the ESP content is trivial and can be recreated from
packages every time if needed, it's not really a very interesting use
case for us. if someone wants to do the work to get bootctl to
duplicate the content and keep it in sync we can review it and there's
no opposition in principle to have it, but we (core devs) are not
going to implement it, someone who cares about the use case needs to
do so.

Reply via email to