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

["Roberto A. Foglietta" <roberto.foglietta@gmail.com>]

Il giorno ven 21 ott 2022 alle ore 18:15 Bezdeka, Florian
<florian.bezdeka@siemens.com> ha scritto:
>
> 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?

Hi Florian,

because Raphael wrote: "Removing expand-on-first-boot resolves the issue"

> We disable
> the systemd service after the first run...

Then why removing (so destroying) the script would fix the problem?

[Service]
Type=oneshot
ExecStart=/usr/share/expand-on-first-boot/expand-last-partition.sh
ExecStartPost=-/bin/systemctl disable expand-on-first-boot.service

I am not an expert of systemd but I have the sensation that
ExecStartPost will run ONLY IF ExecStart script returns true. It is a
"oneshot" service - and in my mind - one successful shot. Where "in my
mind" means if I were written systemd.

Another reason is: because systemd could have a bug in some {past,
present, future} version that affects the disabling. So, having a
double way to obtain the same result is not a work-around but a
redundant safe path for a mission critical system that cannot fail.

However, the workaround may fail because the script runs with "set
-e". So, every failure in the script will prevent it from arriving at
the last command.

So, if the workaround solves the problem then the problem is a bug in
systemd that does not disable the service (probable) or something that
re-enables it (unlikely).

Instead, if the workaround does not work - and it is easy to check
because after the first boot the script still exists in its original
form - then "set -e" did its job and "set -x" + logging in a file
would help for debugging.

In brief: the workaround solves otherwise helps us to define the
perimeter of the unexpected behaviour.

Best regards, R-