| Message ID | 20250411094412.3921975-1-felix.moessbauer@siemens.com |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | [1/1] fix: rebuild rootfs on change of USERS | expand |
On 11.04.25 11:44, '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.kowalsky@siemens.com> > Signed-off-by: Felix Moessbauer <felix.moessbauer@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" Means, we are not caching after rootfs_install so far? Jan
On Fri, 2025-04-11 at 11:48 +0200, Jan Kiszka wrote: > On 11.04.25 11:44, '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.kowalsky@siemens.com> > > Signed-off-by: Felix Moessbauer <felix.moessbauer@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" > > Means, we are not caching after rootfs_install so far? 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
On 11.04.25 11:52, Moessbauer, Felix (FT RPD CED OES-DE) wrote: > On Fri, 2025-04-11 at 11:48 +0200, Jan Kiszka wrote: >> On 11.04.25 11:44, '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.kowalsky@siemens.com> >>> Signed-off-by: Felix Moessbauer <felix.moessbauer@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" 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 >> >> Means, we are not caching after rootfs_install so far? > > 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 >
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"
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.kowalsky@siemens.com> Signed-off-by: Felix Moessbauer <felix.moessbauer@siemens.com> --- meta/classes/image-account-extension.bbclass | 4 ++++ 1 file changed, 4 insertions(+)