Re: [PATCH v3] expand-on-first-boot: Ensure that /tmp is writable

["'MOESSBAUER, Felix' via isar-users" <isar-users@googlegroups.com>]

On Thu, 2024-08-15 at 07:07 +0300, Uladzimir Bely wrote:
> On Tue, 2024-08-13 at 13:32 +0300, Uladzimir Bely wrote:
> > On Tue, 2024-08-13 at 09:24 +0000, MOESSBAUER, Felix wrote:
> > > On Tue, 2024-08-13 at 12:17 +0300, Uladzimir Bely wrote:
> > > > On Thu, 2024-07-25 at 16:17 +0200, 'Clara Kowalsky' via isar-
> > > > users
> > > > wrote:
> > > > > By setting PrivateTmp, a new file system namespace is created
> > > > > for
> > > > > this
> > > > > service and private /tmp/<service>/tmp and
> > > > > /var/tmp/<service>/tmp
> > > > > subdirectories are mounted, which are only used for processes
> > > > > of
> > > > > this
> > > > > namespace. The service unit receives a mount unit dependency
> > > > > for
> > > > > all
> > > > > mounts required to access /tmp and /var/tmp.
> > > > > This ensures that the /tmp directory is writable for the
> > > > > service,
> > > > > as
> > > > > mktemp is used in expand-last-partition.sh and creates a
> > > > > temporary
> > > > > file.
> > > > > 
> > > > > Signed-off-by: Clara Kowalsky <clara.kowalsky@siemens.com>
> > > > > ---
> > > > >  .../expand-on-first-boot/files/expand-on-first-
> > > > > boot.service     
> > > > > > 
> > > > > 1
> > > > > +
> > > > >  1 file changed, 1 insertion(+)
> > > > > 
> > > > > 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 90c92a39..8e76998b 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
> > > > > @@ -16,6 +16,7 @@ Type=oneshot
> > > > >  ExecStart=/usr/share/expand-on-first-boot/expand-last-
> > > > > partition.sh
> > > > >  ExecStartPost=-/bin/systemctl disable expand-on-first-
> > > > > boot.service
> > > > >  ExecStopPost=-/bin/systemctl disable expand-on-first-
> > > > > boot.service
> > > > > +PrivateTmp=true
> > > > >  
> > > > >  [Install]
> > > > >  WantedBy=sysinit.target
> > > > > -- 
> > > > > 2.45.2
> > > > > 
> > > > 
> > > > Hello all.
> > > > 
> > > > After few days having this patch merged we at least twice faced
> > > > the
> > > > issue in CI with running qemuamd64 machine, probably related to
> > > > the
> > > > applied patch.
> > > > 
> > > > Error message is "ERROR| No resize output while expected".
> > > > E.g.,
> > > > there
> > > > is no btrfs resize output in VM boot log.
> > > > 
> > > > The reason of non-running expand-on-first-boot serivce is:
> > > > 
> > > > ```
> > > > [    5.578636] systemd[1]: local-fs-pre.target: Job expand-on-
> > > > first-
> > > > boot.service/start deleted to break ordering cycle starting
> > > > with
> > > > local-
> > > > fs-pre.target/start
> > > > ```
> > > 
> > > Interesting, I observed this same issue as well, but thought it
> > > comes
> > > from a downstream part. You're right, this cannot work:
> > > 
> > > Citing systemd.exec:
> > > 
> > > Similarly, units with PrivateTmp= enabled automatically get mount
> > > unit
> > > dependencies for all mounts required to access /tmp/ and
> > > /var/tmp/.
> > > They will also gain an automatic After= dependency on systemd-
> > > tmpfiles-
> > > setup.service(8). 
> > > 
> > > If /var is the partition to be resized, this will break.
> > > 
> > > Felix
> > > 
> > 
> > The dependency conflict seems to be here:
> > 
> > - expand-on-first-boot.service
> > Before=local-fs-pre.target
> > PrivateTmp=true # This means implicit "After=systemd-tmpfiles-
> > setup.service" dependency0, according to 
> > https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
> > 
> > - systemd-tmpfiles-setup.service 
> > After=local-fs.target
> > 
> > - local-fs.target
> > After=local-fs-pre.target
> > 
> > 
> 
> Finally, does this all mean we need to revert this v3 patch and get
> back to "[PATCH v2] expand-on-first-boot: Add /tmp to
> ConditionPathIsReadWrite" variant?

The conditions are evaluated right before the service starts. By that,
we might have non-deterministic behavior, depending on which service
mounts /tmp (if at all) and when it is started relative to the expand-
on-first-boot.

I'm wondering if we should better create our own tmpfs in combination
with TMPDIR, just for that service (and drop it after execution). For
obvious reasons, the expanding needs to happen VERY early, but at that
point in time not much can be assumed about the rootfs.

CC'ing Florian.

Felix

> 
> > > > 
> > > > I'm currently debugging the issue, but for now I'll attach two
> > > > logs
> > > > when the same image was run twice - with and without an error.
> > > > 
> > > > Maybe someone have some ideas about the issue.
> > > > 
> > > > Actually, in case expand-on-first-boot runs OK, there is
> > > > another
> > > > target
> > > > systemd disables:
> > > > 
> > > > ```
> > > > [    5.507289] systemd[1]: local-fs.target: Job local-fs-
> > > > pre.target/start deleted to break ordering cycle starting with
> > > > local-
> > > > fs.target/start
> > > > ```
> > > > 
> > > > -- 
> > > > Best regards,
> > > > Uladzimir.
> > > > 
> > > 
> > > -- 
> > > Siemens AG, Technology
> > > Linux Expert Center
> > > 
> > > 
> > 
> > -- 
> > Best regards,
> > Uladzimir.
> > 
> 

-- 
Siemens AG, Technology
Linux Expert Center


-- 
You received this message because you are subscribed to the Google Groups "isar-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/isar-users/7009e44f4fb7730435f5f0d726f11448a94407d2.camel%40siemens.com.