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

[Uladzimir Bely <ubely@ilbers.de>]

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


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

-- 
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/28a07330fe14dadcf82f32290671ea922ab7150e.camel%40ilbers.de.