[PATCH 1/1] fix: rebuild rootfs on change of USERS

17 views
Skip to first unread message

Felix Moessbauer

unread,
Apr 11, 2025, 5:44:32 AM4/11/25
to isar-...@googlegroups.com, adriaan...@siemens.com, Felix Moessbauer, Clara Kowalsky
In case a change to the Isar created users is done, this currently
only re-triggers the do_rootfs_postprocess task. This task changes the
rootfs (e.g. home dirs are moved) and by that needs to operate on a
clean one. Otherwise old homedirs might still remain in the final rootfs
or move operations are not possible.

We fix this by ensuring that the do_rootfs_install task is executed
whenever a change to USERS is done. By that, we enter the
do_rootfs_postinstall with a clean rootfs.

Reported-by: Clara Kowalsky <clara.k...@siemens.com>
Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---
meta/classes/image-account-extension.bbclass | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/meta/classes/image-account-extension.bbclass b/meta/classes/image-account-extension.bbclass
index ea956cd5..8289db40 100644
--- a/meta/classes/image-account-extension.bbclass
+++ b/meta/classes/image-account-extension.bbclass
@@ -144,3 +144,7 @@ python image_postprocess_accounts() {
image_create_groups(d)
image_create_users(d)
}
+
+# rebuild rootfs on change of USERS as homes might be moved / created
+# no need to depend on GROUPS as they don't create directories
+do_rootfs_install[vardeps] += "USERS"
--
2.39.5

Jan Kiszka

unread,
Apr 11, 2025, 5:48:50 AM4/11/25
to Felix Moessbauer, isar-...@googlegroups.com, adriaan...@siemens.com, Clara Kowalsky
Means, we are not caching after rootfs_install so far?

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

MOESSBAUER, Felix

unread,
Apr 11, 2025, 5:52:26 AM4/11/25
to isar-...@googlegroups.com, Kiszka, Jan, Schmidt, Adriaan, Kowalsky, Clara
Exactly. We cache the do_rootfs_install task (which runs before
do_rootfs_postprocess). A long term solution would be to not pass the
extracted rootfs between do_rootfs_install and do_rootfs_postprocess
but instead pass the clean tarball which is then extracted in the
postprocess task.

This however would break an interface, as currently tasks that run
after do_rootfs_install assume that the rootfs is available as tree.

Felix


>
> Jan

--
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany

Clara Kowalsky

unread,
Apr 11, 2025, 6:09:09 AM4/11/25
to Moessbauer, Felix (FT RPD CED OES-DE), isar-...@googlegroups.com, Kiszka, Jan (FT RPD CED), Schmidt, Adriaan (FT RPD CED EDC-DE)
This is not enough. We also need to add the flags of the USER_foo to the
vardeps as done in the beginning of the image-account-extension.bbclass.

BR,
Clara

Clara Kowalsky

unread,
Apr 11, 2025, 6:16:07 AM4/11/25
to isar-...@googlegroups.com, adriaan...@siemens.com, felix.mo...@siemens.com, Clara Kowalsky
In case a change to the Isar created users is done, this currently
only re-triggers the do_rootfs_postprocess task. This task changes the
rootfs (e.g. home dirs are moved) and by that needs to operate on a
clean one. Otherwise old homedirs might still remain in the final rootfs
or move operations are not possible.

We fix this by ensuring that the do_rootfs_install task is executed
whenever a change to USERS is done. By that, we enter the
do_rootfs_postinstall with a clean rootfs.

Signed-off-by: Clara Kowalsky <clara.k...@siemens.com>
---
meta/classes/image-account-extension.bbclass | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/meta/classes/image-account-extension.bbclass b/meta/classes/image-account-extension.bbclass
index ea956cd5..1c664be0 100644
--- a/meta/classes/image-account-extension.bbclass
+++ b/meta/classes/image-account-extension.bbclass
@@ -11,11 +11,11 @@ GROUPS ??= ""
python() {
for entry in (d.getVar("GROUPS") or "").split():
group_entry = "GROUP_{}".format(entry)
- d.appendVarFlag("image_postprocess_accounts", "vardeps", " {}".format(group_entry))
+ d.appendVarFlag("image_postprocess_groups", "vardeps", " {}".format(group_entry))

for entry in (d.getVar("USERS") or "").split():
user_entry = "USER_{}".format(entry)
- d.appendVarFlag("image_postprocess_accounts", "vardeps", " {}".format(user_entry))
+ d.appendVarFlag("image_postprocess_users", "vardeps", " {}".format(user_entry))
}

def image_create_groups(d: "DataSmart") -> None:
@@ -137,10 +137,14 @@ def image_create_users(d: "DataSmart") -> None:
if "force-passwd-change" in flags:
bb.process.run([*chroot, "/usr/bin/passwd", "--expire", entry])

+ROOTFS_POSTPROCESS_COMMAND += "image_postprocess_groups"
+ROOTFS_INSTALL_COMMAND += "image_postprocess_users"
+image_postprocess_groups[vardeps] += "GROUPS"
+image_postprocess_users[vardeps] += "USERS"

-ROOTFS_POSTPROCESS_COMMAND += "image_postprocess_accounts"
-image_postprocess_accounts[vardeps] += "USERS GROUPS"
-python image_postprocess_accounts() {
+python image_postprocess_groups() {
image_create_groups(d)
+}
+python image_postprocess_users() {
image_create_users(d)
}
--
2.49.0

Clara Kowalsky

unread,
Apr 11, 2025, 6:18:57 AM4/11/25
to isar-...@googlegroups.com, adriaan...@siemens.com, felix.mo...@siemens.com
This is still not ideal, as old home directories are not removed when
removing the create-home flag or setting another directory via
USER_foo[home] = <x>.
BR,
Clara

MOESSBAUER, Felix

unread,
Apr 11, 2025, 7:05:04 AM4/11/25
to isar-...@googlegroups.com, Kowalsky, Clara, Schmidt, Adriaan
This moves the whole user creation to the rootfs_install task, which
also means that the result of the user creation is reflected in the
sstate cache (which might be ok, though). But I'm wondering if that is
logically correct, as IIRC the groups have to be created before the
users are created.

A more subtle change (based on my patch "fix: rebuild rootfs on change
of USERS") would be to just add USERS as well as all USERS_<x>
variables to the vardeps of do_rootfs_install. This should also solve
your case from below, as a removed user always means a change to the
USERS variable.

I'll try to come up with this in a v2 of my patch.

Felix

> >  
> > -ROOTFS_POSTPROCESS_COMMAND += "image_postprocess_accounts"
> > -image_postprocess_accounts[vardeps] += "USERS GROUPS"
> > -python image_postprocess_accounts() {
> > +python image_postprocess_groups() {
> >       image_create_groups(d)
> > +}
> > +python image_postprocess_users() {
> >       image_create_users(d)
> >   }
>
> This is still not ideal, as old home directories are not removed when
> removing the create-home flag or setting another directory via
> USER_foo[home] = <x>.
> BR,
> Clara

Felix Moessbauer

unread,
Apr 11, 2025, 7:26:33 AM4/11/25
to isar-...@googlegroups.com, adriaan...@siemens.com, Felix Moessbauer, Clara Kowalsky
In case a change to the Isar created users is done, this currently
only re-triggers the do_rootfs_postprocess task. This task changes the
rootfs (e.g. home dirs are moved) and by that needs to operate on a
clean one. Otherwise old homedirs might still remain in the final rootfs
or move operations are not possible.

We fix this by ensuring that the do_rootfs_install task is executed
whenever a change to USERS is done. By that, we enter the
do_rootfs_postinstall with a clean rootfs.

Reported-by: Clara Kowalsky <clara.k...@siemens.com>
Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---
Changes since v1:

- Also add dependency to USER_<x> for all x in USERS

meta/classes/image-account-extension.bbclass | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/meta/classes/image-account-extension.bbclass b/meta/classes/image-account-extension.bbclass
index ea956cd5..3c461b1a 100644
--- a/meta/classes/image-account-extension.bbclass
+++ b/meta/classes/image-account-extension.bbclass
@@ -8,6 +8,10 @@
USERS ??= ""
GROUPS ??= ""

+# rebuild rootfs on change of USERS as homes might be moved / created
+# no need to depend on GROUPS as they don't create directories
+# groups need to be created before users, hence do not move the user creation into
+# the do_rootfs_install task but only add a dependency
python() {
for entry in (d.getVar("GROUPS") or "").split():
group_entry = "GROUP_{}".format(entry)
@@ -16,7 +20,9 @@ python() {
for entry in (d.getVar("USERS") or "").split():
user_entry = "USER_{}".format(entry)
d.appendVarFlag("image_postprocess_accounts", "vardeps", " {}".format(user_entry))
+ d.appendVarFlag("do_rootfs_install", "vardeps", " {}".format(user_entry))
}
+do_rootfs_install[vardeps] += "USERS"

def image_create_groups(d: "DataSmart") -> None:
"""Creates the groups defined in the ``GROUPS`` bitbake variable.
--
2.39.5

Clara Kowalsky

unread,
Apr 11, 2025, 11:56:54 AM4/11/25
to Felix Moessbauer, isar-...@googlegroups.com, adriaan...@siemens.com
This works, at least for the case of adding / moving the home directory
of an existing user. Only removing an existing home dir when removing
all home flags of a user is not covered, but we can ignore this for now.
BR,
Clara

MOESSBAUER, Felix

unread,
Apr 29, 2025, 4:31:16 AM4/29/25
to isar-...@googlegroups.com, Kowalsky, Clara, Schmidt, Adriaan
Hi, this can only happen if a user is created by a package and then
transformed using ISAR, right?. IMHO this is simply not in scope, as we
have no way to express "remove-this-homedir".

Anyways, IMHO this patch is good to be merged.

Best regards,
Felix

Clara Kowalsky

unread,
May 7, 2025, 8:28:06 AM5/7/25
to Moessbauer, Felix (FT RPD CED OES-DE), isar-...@googlegroups.com, Schmidt, Adriaan (FT RPD CED EDC-DE)
Yes, removing a home dir is out of scope. The patch can be merged.
BR,
Clara

Baurzhan Ismagulov

unread,
May 7, 2025, 9:08:03 AM5/7/25
to isar-...@googlegroups.com
On 2025-04-11 13:26, 'Felix Moessbauer' via isar-users wrote:
> In case a change to the Isar created users is done, this currently
> only re-triggers the do_rootfs_postprocess task. This task changes the
> rootfs (e.g. home dirs are moved) and by that needs to operate on a
> clean one. Otherwise old homedirs might still remain in the final rootfs
> or move operations are not possible.
>
> We fix this by ensuring that the do_rootfs_install task is executed
> whenever a change to USERS is done. By that, we enter the
> do_rootfs_postinstall with a clean rootfs.
>
> Reported-by: Clara Kowalsky <clara.k...@siemens.com>
> Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>

Applied to next, thanks.

With kind regards,
Baurzhan

Jan Kiszka

unread,
Jun 17, 2025, 11:13:24 AM6/17/25
to Felix Moessbauer, isar-...@googlegroups.com, adriaan...@siemens.com, Clara Kowalsky, Quirin Gylstorff
Quirin and I do not yet buy why GROUPS should be excluded. They may also
need a clean baseline if the developer changed a recipe with impact on
groups.

We just had a case where someone changed the gid, and that failed to
rebuild. So, even if groups do not create directories, they influence
that. And some experiments I just did seem to confirm that.

Jan

> python() {
> for entry in (d.getVar("GROUPS") or "").split():
> group_entry = "GROUP_{}".format(entry)
> @@ -16,7 +20,9 @@ python() {
> for entry in (d.getVar("USERS") or "").split():
> user_entry = "USER_{}".format(entry)
> d.appendVarFlag("image_postprocess_accounts", "vardeps", " {}".format(user_entry))
> + d.appendVarFlag("do_rootfs_install", "vardeps", " {}".format(user_entry))
> }
> +do_rootfs_install[vardeps] += "USERS"
>
> def image_create_groups(d: "DataSmart") -> None:
> """Creates the groups defined in the ``GROUPS`` bitbake variable.

--
Reply all
Reply to author
Forward
0 new messages