On 13.06.22 22:49, Marco Braga wrote: > Hi, > I am currently testing a system based on yocto dunfell + swupdate + > EFIBootguard and I am concerned by the way the kernel is stored in the > same partition of the configuration. > I am using 2 config partitions for EFIBootguard, and also a double copy > strategy for rootfs. At start, partition 0 contains the kernel > associated with the installed rootfs. > If I use swupdate to update some parts of the system (not related to > rootfs or kernel), this creates a new configuration on partition 1, but > the kernel file position is still on partition 0.
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. However, if you update something that affects the updatability of the resulting boot path (kernel, rootfs and possibly more), make sure to create a consistent v2 of all those bits. Then switch. You may optimize the update, avoiding to transfer also unchanged artifacts by either using a delta update or by copying unchanged bits over from v1 on the target using swupdate scripting. > Should then I need to update both the kernel and the rootfs, this would > switch back to having a new active configuration on partition 0, but the > new kernel should be written on configuration partition 1 to preserve > the currently running kernel (resident on partition 0) as a fail safe in > case of a rollback. > This brings to a situation where cfg in use is in a partition, but the > kernel is on another one. 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. > It also makes updated more complex: due to the double copy strategy, not > only I have to detect the inactive rootfs partition, but also the > inactive configuration partition where to store the kernel. I am really > uneasy about this. > Sadly EFIBootguard cannot boot the kernel stored on ext4 /boot rootfs > directlry, so I am That is a related to UEFI not supporting ext4 or other filesystems by default. Could be addressed with extra UEFI drivers, but I'm not even aware if those exist. It's easier and probably also more secure (if you are after secure boot) to confine the functionality of UEFI. > 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. Jan -- Siemens AG, Technology Competence Center Embedded Linux -- 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/79aebedf-bcb3-008f-1579-e1d438033cbc%40siemens.com.
