Hi,

> > Do not touch the EFI Boot Guard config unless you updated something that
> > is related to it. You can perfectly use swupdate to change artifacts on
> > your installed system without touching the boot paths, e.g. deploy a new
> > application into a common (not a/b-updated) partition.
> >
> 
> The problem is that swupdate uses the bootloader configuration to store
> update status when used with hawkbit server.

Not only when used with the hawkBit suricatta module but also for other
"ingress" channels. 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?


> Quick check (
> https://github.com/sbabic/swupdate/blob/a10214e88eba43ae0382c84d9f0d10cf5d623e2a/suricatta/server_hawkbit.c#L926
> and several other points).
> By default swupdate creates a "transaction" every time it makes an update
> even if the file does not touch boot related artifacts (kernel or rootfs).
> This behavior can be forcibly disabled, but then swupdate cannot read back
> the update status.

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)


> > And that is a bug in your configuration. Kernel and rootfs should be
> > considered one logical artifact, even if they are distributed in
> > separate pieces. So should the related config switch look like. Anything
> > else will just break in practice.
> >
> 
> I totally understand and agree, I am trying to make things work with this
> setup:
> EFIBootguard + swupdate + hawkibit.
> The situation is this:
> 1. swupdate + hawkbit expects to send update status to hawkbit if it finds
> TESTING usate in current EBG configuration
> https://github.com/sbabic/swupdate/blob/a10214e88eba43ae0382c84d9f0d10cf5d623e2a/suricatta/server_hawkbit.c#L926
> 
> 2. swupdate normally creates a "transaction" on each update, and current
> implementation of EBG clones the current configuration to a new one:
> https://github.com/sbabic/swupdate/blob/a10214e88eba43ae0382c84d9f0d10cf5d623e2a/bootloader/ebg.c#L57

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?



Kind regards,
   Christian

-- 
Dr. Christian Storm
Siemens AG, Technology, T CED SES-DE
Otto-Hahn-Ring 6, 81739 München, Germany

-- 
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/20220614153021.aa2p65mqiyna3p4c%40MD1ZFJVC.ad001.siemens.net.

Reply via email to