On Mon, 2024-01-15 at 18:23 +0100, Jan Kiszka wrote:
> On 15.01.24 16:28, 'Earl Chew' via EFI Boot Guard wrote:
> > After making a backup of my EFI ESP partition in another partition,
> > I
> > was surprised to
> > find that efibootguard would no longer boot.
> >
> > The relevant part of env/fatvars.c is:
> >
> > if (numHandles > ENV_NUM_CONFIG_PARTS) {
> > ERROR(L"Too many config partitions found.
> > Aborting.\n");
> > goto lc_cleanup;
> > }
> >
> > result = BG_SUCCESS;
> >
> > if (numHandles < ENV_NUM_CONFIG_PARTS) {
> > WARNING(L"Too few config partitions: found: %d, but
> > expected %d.\n",
> > numHandles, ENV_NUM_CONFIG_PARTS);
> > /* Don't treat this as error because we may still
> > be
> > able to
> > * find a valid config */
> > result = BG_CONFIG_PARTIALLY_CORRUPTED;
> > }
> >
> > While too few config parts might be considered fatal, the
> > implementation is
> > optimistic because "we may still be able to find a valid config".
Hi, I agree.
I stumbled upon this as well, but in my case it was about having
multiple devices (e.g. disks) having EBG partitions. This was not
supported due to the reason you stated above. I then fixed that by only
probing the root device. Technically this was achieved by forwarding
the device UUID via the systemd bootloader interface (a set of efi
variables) to the userspace and limiting the search to that device:
https://github.com/siemens/efibootguard/commit/ffbd35f76b7ae587211f999a8cbf4514b0ac4ed2
> >
> > It seems odd that the opposite case where there is an oversupply of
> > config partitions should not be treated the same way because "we
> > may
> > still be
> > able to find a valid config".
> >
> > The implementation of load_config() considers the loaded config
> > data to
> > find the most recent two versions (the latest version N, and its
> > predecessor
> > version N-1), then chooses one of them.
> >
> > Instead of /* Load all config data */, load_config() could to walk
> > all
> > available
> > config files, but only retaining the two most recent versions. This
> > would
> > allow load_config() succeed even when there is an oversupply of
> > config
> > partitions.
Either like that, or simply take the first valid partition on the
active device. Just keep in mind, that these problems (multiple
unrelated EBG partitions on multiple devices and multiple somehow
related ones on a single device) are independent aspects.
Also, keep in mind that we read the EBG partitons both at boot time
(EFI), as well as at update time (from userspace). Both implementations
should behave semantically identical, even if they are implemented
differently due to technical reasons.
IMHO your proposal totally makes sense and improves the robustness of
EBG. Patches welcome!
Best regards,
Felix
> >
> > Thoughts?
>
> Reminds me of
> https://groups.google.com/d/msgid/efibootguard-dev/b83c1681629e5b09c773d6ac6a32a8694bff16d4.camel%40siemens.com
> - Felix, any comments on that?
>
> Jan
>
--
Siemens AG, Technology
Linux Expert Center
--
You received this message because you are subscribed to the Google Groups "EFI
Boot Guard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to efibootguard-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/efibootguard-dev/f1ebd9ba94690ca06f667eac044e392ef4fb4ee8.camel%40siemens.com.
