| Message ID | 20250627082502.74292-1-alexander.heinisch@siemens.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | [v2] classes/image-postproc: Enable systemd units based on systemd presets | expand |
On Fri, 2025-06-27 at 10:25 +0200, alexander.heinisch via isar-users wrote: > From: Alexander Heinisch <alexander.heinisch@siemens.com> > > By default population of the presets is automatically done by systemd > on first-boot. > > There were several issues with that: > > 1. The rootfs we get as a build artifact does not reflect the actual > system running in the field. This might be intentional. We especially need to ensure that things like the machine-id or ssh keys (machine fingerprint) are not populated. > > 2. For setups without writeable /etc this fails. With that addition > it happens already at build time. We already had bugs in this area (no rw on kernel cmdline) [1] and discussed with the systemd maintainers (Unfortunately I can't find the issue...). IIRC the answer was that systemd requires a RW /etc when transitioning out of the initrd. Having /etc RO is only supported under some conditions (e.g. after a on-first-boot). Unfortunately Debian itself does not rely on the systemd on-first-boot logic, but directly adds the systemd symlinks in /etc - which makes it inherently incompatible with sd first boot logic. In general, I prefer to have a concept in ISAR how we want to handle the first-boot case, instead of papering over the incompatibility of Debian-install and systemd first boot & vendor-preset over and over again. [1] https://groups.google.com/g/isar-users/c/dbxcePqSc04/m/a5y1HgGgBgAJ Felix
On Mon, 2025-07-14 at 11:17 +0000, Moessbauer, Felix (FT RPD CED OES- DE) wrote: > On Fri, 2025-06-27 at 10:25 +0200, alexander.heinisch via isar-users > wrote: > > From: Alexander Heinisch <alexander.heinisch@siemens.com> > > > > By default population of the presets is automatically done by > > systemd > > on first-boot. > > > > There were several issues with that: > > > > 1. The rootfs we get as a build artifact does not reflect the > > actual > > system running in the field. > > This might be intentional. We especially need to ensure that things > like the machine-id or ssh keys (machine fingerprint) are not > populated. We just populate services based on preset here. - no machine-id handling, no ssh key regen, or similar. > > > > > 2. For setups without writeable /etc this fails. With that addition > > it happens already at build time. > > We already had bugs in this area (no rw on kernel cmdline) [1] and > discussed with the systemd maintainers (Unfortunately I can't find > the > issue...). IIRC the answer was that systemd requires a RW /etc when > transitioning out of the initrd. Having /etc RO is only supported > under > some conditions (e.g. after a on-first-boot). Probably, you are referring to [2]. Imo, that does not help with true immutability (RO /etc), but that's something we were discussing here [3]. > > Unfortunately Debian itself does not rely on the systemd on-first- > boot > logic, but directly adds the systemd symlinks in /etc - which makes > it > inherently incompatible with sd first boot logic. How does population of services to /etc/systemd/... relate to first- boot? First-boot condition (apart from kernel cmdline) only depends on the existence of /etc/machine-id, or "uninitialized" in /etc/machine-id, respectively. > > In general, I prefer to have a concept in ISAR how we want to handle > the first-boot case, instead of papering over the incompatibility of > Debian-install and systemd first boot & vendor-preset over and over > again. > > [1] > https://groups.google.com/g/isar-users/c/dbxcePqSc04/m/a5y1HgGgBgAJ > > Felix > > [2] https://github.com/systemd/systemd/issues/14131#issuecomment-689643106 [3] https://lists.cip-project.org/g/cip-dev/message/19275?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2CAlexander+Heinisch%2C20%2C2%2C0%2C113913313 BR Alex -- Alexander Heinisch Siemens AG http://www.siemens.com/
diff --git a/RECIPE-API-CHANGELOG.md b/RECIPE-API-CHANGELOG.md index 8468717d..fb9ad4f3 100644 --- a/RECIPE-API-CHANGELOG.md +++ b/RECIPE-API-CHANGELOG.md @@ -727,3 +727,21 @@ Changes in next This was never documented and never had practical relevance. `oci-archive` is the useful OCI image format that can be imported, e.g., by podman. + +### Populate systemd units based on presets during image postprocessing + +By default population of the presets is automatically done by systemd +on first-boot. + +There were several issues with that: + +1. The rootfs we get as a build artifact does not reflect the actual +system running in the field. + +2. For setups without writeable /etc this fails. With that addition +it happens already at build time. + +**Note**: Additional services are enabled only. Services already enabled +during the package installation won't be changed. + +Opt-out: `ROOTFS_POSTPROCESS_COMMAND:remove = "image_postprocess_populate_systemd_preset"` diff --git a/meta/classes/image-postproc-extension.bbclass b/meta/classes/image-postproc-extension.bbclass index 991bac4c..269b86c0 100644 --- a/meta/classes/image-postproc-extension.bbclass +++ b/meta/classes/image-postproc-extension.bbclass @@ -95,3 +95,8 @@ image_posprocess_disable_systemd_firstboot() { fi fi } + +ROOTFS_POSTPROCESS_COMMAND =+ "image_postprocess_populate_systemd_preset" +image_postprocess_populate_systemd_preset() { + sudo chroot '${ROOTFSDIR}' systemctl preset-all --preset-mode="enable-only" +}