Hi Christian,
thanks a lot for helping out!
Il giorno mar 14 giu 2022 alle ore 17:29 Christian Storm <
[email protected]> ha scritto:
> It seems that your "problem" is actually different
> *types* of artifacts: one is firmware for which you probably will want to
> persistently store state and the other is some (application) software for
> which you don't want such behavior, right?
>
Totally correct, you nailed the problem. We need to update an application
(running on node) without touching the rootfs or kernel. Still, we'd also
like to update the kernel+rootfs combination if required.
There are actually *two* markers SWUpdate persistently stores in the
> bootloader environment:
> (1) bootloader_transaction_marker → recovery_status
> (2) bootloader_state_marker → ustate (per default)
>
Correct. Both are handled differently depending on the actual bootloader.
If using grub or u-boot, it uses variables. When using EFIBootguard instead
(1) creates a new configuration cloning the old one.
Due to the "clone" behavior and with 2 configuration partitions, after the
first update it happens that CFG #1 has the highest revision number.
kernelparams still point to the correct rootfs device (unchanged by the
update) and kernelpath still points to the previous kernel path, which is
the CFG #0 partition.
Now, should we decide to update the kernel, we'll be in the dire situation
of having to touch both the partitions:CFG #0 contains the failback kernel,
so we'll have to write the new one in the partition of CFG #1, while the
update will actually change the configuration of partition CFG #0 (which is
not in use).
It seems a mess to me.
At the moment I am working with a different setup: I have double copy
partitions of boot rootfs and kernel. Kernels are not stored in the same
partitions as EFI configs, but configs point to the correct kernel path
using labels. It seems a lot more safe to me, even without considering
swupdate.
You can disable one or both of the above with a snippet like the
> following in the sw-description file *per update artifact* ―
> though also globally which you don't want to if I got it right:
>
> software =
> {
> bootloader_transaction_marker = false;
> bootloader_state_marker = false;
>
> ...
>
> So, setting bootloader_transaction_marker = false solves your problem?
Thanks for your suggestion, this may actually work. swupdate will not be
able to report update status back to hawkbit automatically though, so this
will require specific handling (restarting swupdate with "-c 2" parameter?).
I am not sure if this is the best way to go, but I'll try it.
In any case, updating the kernel file on a separate partition seems way
safer to me in case of a power failure, so if there are no drawbacks I may
consider to continue with separate kernel partitions and keeping only
configs in EBG partitions.
As a last question, what is the suggested kernel update procedure with
EFIBootguard?
Do you have any considerations or suggestions?
Thanks,
Marco
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/efibootguard-dev/CAEPsuKPq98xdMX0NDtMaccFWgK7d9EznZhGa_LBdFrcR4YiAMw%40mail.gmail.com.
