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

[Uladzimir Bely <ubely@ilbers.de>]

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?

> > > 
> > > 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.
> 

-- 
Best regards,
Uladzimir.

-- 
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/5d23fe9e9adda350f5596f00d7b8bd1eb3c67ed6.camel%40ilbers.de.