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

[Henning Schild <henning.schild@siemens.com>]

Hi,

we have patches to use systemd-growfs instead of our manual way. They
might just solve your problem. So please give them a try.

 [PATCH v5 0/1] expand-on-first-boot: Switch from resize2fs to
 systemd-growfs

All that was missing last time was a way to deal with stretch.

And we really should test all that in CI.

Henning

Am Fri, 21 Oct 2022 09:48:14 +0200
schrieb Raphael Lisicki <raphael.lisicki@siemens.com>:

> 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".
> 
> My gut feeling is that after expand-on-first boot finishes, the kernel
> still processes block device events, which systemd gets after /data
> has already been mounted and then cause it to be umounted, as systemd
> was already picky with umounting stuff in the past [1]. Unfortunately
> I have no idea how to test this hypothesis.
> 
> Did anyone already experience something like this? The racy-ness of
> the issue makes creating a minimal reproduction hard.
> 
> 
> 
> [1] https://github.com/systemd/systemd/issues/9869
> 
> 
> 
> best regards
> raphael
>