Hi Jan, thanks for answering. Il giorno mar 14 giu 2022 alle ore 12:17 Jan Kiszka <[email protected]> ha scritto:
> 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. 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. > 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 3. Due to above, it may happens that: a. A system update stores kernel in C:BOOT0/bzImage, using CFG #0 b. swupdate applies an update (which may be something totally unrelated to boot artifacts - kernel or rootfs etc) c. swupdate clones CFG #0 to CFG #1 due to its implementation of transactions, but the kernel path is still C:BOOT0/bzImage d. on reboot, swupdate finds CFG#1 in ustate TESTING ans commits CFG #1 setting ustate to OK, then notifies hawkbit that the update went well. Result is that CFG#1 is used for boot, and its kernel path is on partition used by CFG #0 The update has nothing to to with boot, so it didn't touch kernel path in CFG #1 which still points to C:BOOT0/bzImage. I am not sure how to handle this. > > looking for an alterlative strategy. At the moment this involves 2 > > partitions dedicated to storing the kernel file, without saving it in > > the configuration partitons. > > What do you think? > > There is no need to store the kernel and the corresponding EBGENV.DAT in > different partitions if you follow the switching pattern above. Ok, assuming I find a workaround for the problem above, what is the suggested way of updating the kernel for next boot? If I understand correctly I should create a new CFG (ex: bg_setenv -u), then mount the partition used by the new config and write the kernel there, umount, set the kernel path as required and ustate to INSTALLED and reboot. Is it correct? What if the FAT partition is corrupted when writing the kernel there? (Still a possibility on embedded devices). 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/CAEPsuKMkW2e2jd0GBuhjTpOW_KLziTHUo9Sz-iFpk_Aa8jtFNA%40mail.gmail.com.
