Re: expand-on-first-boot and surprising umounts

["Bezdeka, Florian" <florian.bezdeka@siemens.com>]

On Fri, 2022-10-21 at 17:41 +0200, Roberto A. Foglietta wrote:
> Il giorno ven 21 ott 2022 alle ore 09:48 Raphael Lisicki
> <raphael.lisicki@siemens.com> ha scritto:
> > 
> > Hi everybody,
> > 
> > I am using a debian bullseye based system and use expand-on-first-boot
> > to expand the last partition. It is not the root file system but an
> > extra ext4 partition to be mounted under /data. The mounting happens
> > after expand-on-first boot has succeeded.
> > 
> > Sometimes, on some builds more often than others, /data gets (attempted
> > to be) umounted immediately after being mounted and subsequent units
> > will fail.
> > 
> > Removing expand-on-first-boot resolves the issue, so does adding
> > "ExecStartPost=/usr/bin/udevadm settle" to expand-on-first-boot but I am
> > not sure if this is only a sophisticated way of solving a race condition
> > with "sleep".
> 
> Hi Raphael,
> 
> this trick should resolve the problem (untested, after the first boot
> nothing happens anymore)
> 
>  echo 'echo "exit 0" >$0'
> > > isar/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
> 
> It is equivalent to apply this patch and obviously it is just a work around
> 
> diff --git a/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
> b/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
> index 759ff8b..09f5cd4 100755
> --- a/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
> +++ b/meta/recipes-support/expand-on-first-boot/files/expand-last-partition.sh
> @@ -62,3 +62,4 @@ partx -u "${LAST_PART}"
>  export EXT2FS_NO_MTAB_OK=1
> 
>  resize2fs "${LAST_PART}"
> +echo "exit 0" >$0

Why should we destroy the expand-last-partition.sh script? We disable
the systemd service after the first run...

And how should that fix the race that Raphael has reported?

> 
> Best regards, R-
>