Re: [isar-cip-core][RFC][PATCH 00/10] Provide A/B snapshot support for persistent /var

Jan Kiszka
2025-02-03T17:18:02Z

On 30.01.25 10:39, Jan Kiszka wrote:
> This is a first attempt to provide a pattern and reusable recipes for
> saving and rolling back the persistent data during A/B updates. The
> obvious approach is using a filesystem that supports snapshots and
> linking those to the rootfs revision that is being booted. As first
> implementation, we are using btrfs. While the current implementation is
> built around btrfs, the concept should not. It may even work with
> device mapper snapshots.
>
> That said, the devil is always in the details. And even this "simple",
> btrfs-only implementation took some rounds to find a logic that neither
> piles up obsolete snapshots or deletes them prematurely. Still, careful
> review is highly welcome, specifically of patch 3.
>
> As we are currently having split /var and /home partitions, this does
> not cover anything in home directories. However, this will automatically
> change when [1] is addressed.
>
> Jan
>
> [1] https://gitlab.com/cip-project/cip-core/isar-cip-core/-/issues/123
>
> Jan Kiszka (10):
> initramfs-crypt-hook: Add support for btrfs
> initramfs-crypt-hook: Bump revision
> initramfs: Add hook for managing /var in A/B fashion
> initramfs-overlay-hook: Optimize variable initialization
> initramfs-overlay-hook: Tune the parameter documentation
> initramfs-overlay-hook: Add awareness for abvar hook
> initramfs-overlay-hook: Bump revision
> swupdate: Make var filesystem type configurable for update images
> swupdate: Activate abvar initramfs hook when VAR_FS_TYPE is set to
> btrfs
> Enable A/B snapshot for /var on x86 and qemu-arm64
>
> classes/swupdate.bbclass | 1 +
> conf/machine/qemu-amd64.conf | 5 +-
> conf/machine/qemu-arm64.conf | 5 +-
> conf/machine/x86-uefi.conf | 5 +-
> kas/opt/ebg-swu.yml | 6 +-
> kas/opt/swupdate.yml | 1 +
> .../cip-core-initramfs/cip-core-initramfs.bb | 3 +-
> .../files/local-bottom.tmpl | 86 +++++++++++++++++++
> .../initramfs-abvar-hook_0.1.bb | 31 +++++++
> .../files/local-top-complete | 7 ++
> ...ook_0.5.bb => initramfs-crypt-hook_0.6.bb} | 6 ++
> .../files/local-bottom.tmpl | 10 ++-
> ...k_0.2.bb => initramfs-overlay-hook_0.3.bb} | 8 +-
> wic/bbb-efibootguard.wks.in | 2 +-
> wic/hihope-rzg2m-efibootguard.wks.in | 2 +-
> wic/qemu-arm64-efibootguard-secureboot.wks.in | 2 +-
> wic/qemu-arm64-efibootguard.wks.in | 2 +-
> wic/qemu-riscv64-efibootguard.wks.in | 2 +-
> wic/x86-uefi-efibootguard-secureboot.wks.in | 2 +-
> wic/x86-uefi-efibootguard.wks.in | 2 +-
> 20 files changed, 168 insertions(+), 20 deletions(-)
> create mode 100644 recipes-initramfs/initramfs-abvar-hook/files/local-bottom.tmpl
> create mode 100644 recipes-initramfs/initramfs-abvar-hook/initramfs-abvar-hook_0.1.bb
> rename recipes-initramfs/initramfs-crypt-hook/{initramfs-crypt-hook_0.5.bb => initramfs-crypt-hook_0.6.bb} (93%)
> rename recipes-initramfs/initramfs-overlay-hook/{initramfs-overlay-hook_0.2.bb => initramfs-overlay-hook_0.3.bb} (87%)
>

Patch 1 and 2 look ready enough to me now while the rest needs a bit
more time. Therefore, I will keep the first two in next and push the
others into a wip/abvar staging branch so that we can move forward with
other pending patches.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center