[PATCH 0/1] expand-on-first-boot: Use proper first-boot semantics

[Tobias Schmidl]

This patch changes the first boot behavior from disabling itself after
the run to using the ConditionFirstBoot.

Notice: This doesn't work on buster, as the first boot mechanic on
buster is different, so the first boot on target isn't recognized as
such.

Tobias Schmidl (1):
expand-on-first-boot: Use proper first-boot semantics

.../expand-on-first-boot/files/expand-on-first-boot.service | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

--
2.36.1

[Tobias Schmidl]

We can now rely on systemd's ConditionFirstBoot to determine whether we
should run or not.

Signed-off-by: Tobias Schmidl <tobias...@siemens.com>
---

.../expand-on-first-boot/files/expand-on-first-boot.service | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service b/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service
index fda5001..7c686c8 100644
--- a/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service
+++ b/meta/recipes-support/expand-on-first-boot/files/expand-on-first-boot.service
@@ -8,13 +8,13 @@ Description=Expand last partition
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-remount-fs.service
-Before=local-fs-pre.target shutdown.target
-ConditionPathIsReadWrite=/etc
+Before=local-fs-pre.target shutdown.target first-boot-complete.target
+Wants=first-boot-complete.target
+ConditionFirstBoot=true

[Service]
Type=oneshot
ExecStart=/usr/share/expand-on-first-boot/expand-last-partition.sh
-ExecStartPost=-/bin/systemctl disable expand-on-first-boot.service

[Install]
WantedBy=sysinit.target
--
2.36.1

[Henning Schild]

If this does not work on buster and maybe ubuntu versions we might
carry, we can not merge this.
We will have to find a way to use the old way for buster and the new
way for versions that actually do work.

Or what does "does not work with buster" actually mean? Will the
overall systemd status turn red and the resize fail, or will it be a
problem we can consider minor?

Henning

Am Wed, 10 Aug 2022 21:26:45 +0200
schrieb Tobias Schmidl <tobias...@siemens.com>:

[Schmidl, Tobias]

Hi Henning,

Am Donnerstag, dem 11.08.2022 um 20:55 +0200 schrieb Henning Schild:
>
> If this does not work on buster and maybe ubuntu versions we might
> carry, we can not merge this.
> We will have to find a way to use the old way for buster and the new
> way for versions that actually do work.
>
> Or what does "does not work with buster" actually mean? Will the
> overall systemd status turn red and the resize fail, or will it be a
> problem we can consider minor?
>

The `ConditionFirstBoot` is not met, not even on the first boot on the
system:


```
root@localhost:~# systemctl status --no-pager expand-on-first-boot
● expand-on-first-boot.service - Expand last partition
Loaded: loaded (/lib/systemd/system/expand-on-first-boot.service; enabled; vendor preset: enabled)
Active: inactive (dead)
Condition: start condition failed at Wed 2022-08-10 13:16:50 UTC; 1min 5s ago
└─ ConditionFirstBoot=true was not met
```

So yes, `expand-on-first-boot` is never executed with this patch on
buster.

Kind regards,

Tobias

[Henning Schild]

Am Thu, 11 Aug 2022 21:07:23 +0200
schrieb "Schmidl, Tobias (T CED SES-DE)" <tobias...@siemens.com>:

And on top systemd might be unhappy about general health i guess.

Anyhow, Reject! buster is an isar target and has to work.

Henning

>
> Kind regards,
>
> Tobias