Re: expand-on-first-boot: Additional findings

[Henning Schild <henning.schild@siemens.com>]

Am Wed, 29 Jun 2022 12:03:40 +0000
schrieb "Schmidl, Tobias" <tobiasschmidl@siemens.com>:

> Hi all,
> 
> in addition to the changes in the last patch [1] I tried defer the
> call to systemd-growfs to the way it was intended by systemd: By
> setting a fstab option. This proved to be unsuccessful, as
> systemd-growfs ist triggered via systemd-remount, and this is way
> earlier in the boot chain than I was able to set
> expand-on-first-boot. (systemd-analyze seems to report not the full
> truth in this case.) The same is with systemd-repart.
> 
> Additionally, systemd-repart requires the user to make changes (and,
> more importantly, keep them in sync) to both the wic file and the
> systemd- repart config file:
> - The wic file needs to set the correct UUID for the partition -
> which are both platform and usage dependent, according to the
> Discoverable Partitions Specification [2]
> - The systemd-config refers to these UUIDs in an abstracted way [3]
> 
> This is in my opinion too error prone to be used in a production
> environment.

Maybe systemd-repart can be used even with Isar. But there is no
generic way to say "grow that last partition", you can only say grow
the first partition with the funny UUID which would kind of dictate a
UUID for the "last partition" and no other partition before would be
allowed to use that.

The whole thing sounds promising to enable luks, maybe with tpm
binding, or lvm2 ... or any sort of partition dynamics on first boot.
But such things are going to be pretty target specific and Isar can not
cater here ...

Henning

> 
> Kind regards,
> 
> Tobias
> 
> [1] https://groups.google.com/g/isar-users/c/8NATfl5i2a4
> [2] https://systemd.io/DISCOVERABLE_PARTITIONS/
> [3] https://manpages.debian.org/testing/systemd/repart.d.5.en.html
>