Re: [PATCH] expand-on-first-boot: Switch from resize2fs to systemd-growfs

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

On Wed, 2022-05-25 at 14:57 +0200, Florian Bezdeka wrote:
> Hi all,
> 
> On Wed, 2022-05-25 at 14:47 +0200, Jan Kiszka wrote:
> > On 25.05.22 14:32, Tobias Schmidl wrote:
> > > We want to be more versatile in our approach of resizing the root
> 
> Here your talking about the root partition, but when looking at the
> lines below I feel we're talking about the "last" partition which might
> be the root partition (in your case) but there is no guarantee for
> that. 
> 
> > > partition. Therefore we switch from resize2fs to systemd-growfs (on
> > > systems with systemd-growfs).
> > 
> > Just for the sake of completeness: Since which Debian version is this
> > the case? I assume buster is fine, right? But stretch was not.
> > 
> > > 
> > > This allows for ext4, btrfs, xfs, and dm-crypt partitions to be resized.
> > > 
> > > Signed-off-by: Tobias Schmidl <tobiasschmidl@siemens.com>
> > > ---
> > >  .../files/expand-last-partition.sh                | 15 +++++++++++++--
> > >  1 file changed, 13 insertions(+), 2 deletions(-)
> > > 
> > > 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 bb371e9..f0dc66d 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
> > > @@ -3,7 +3,7 @@
> > >  # Resize last partition to full medium size
> > >  #
> > >  # This software is a part of ISAR.
> > > -# Copyright (c) Siemens AG, 2018
> > > +# Copyright (c) Siemens AG, 2018-2022
> > >  #
> > >  # SPDX-License-Identifier: MIT
> > >  
> > > @@ -45,4 +45,15 @@ partx -u "${LAST_PART}"
> > >  # when using systemd mount units.
> > >  export EXT2FS_NO_MTAB_OK=1
> > >  
> > > -resize2fs "${LAST_PART}"
> > > +# If we are on a systemd system, we call systemd-growfs, otherwise resize2fs
> > > +if [ -x /lib/systemd/systemd-growfs ]; then
> > > +	MOUNT_POINT=$(findmnt "${LAST_PART}" -o target -n)
> > > +	if [ -z "$MOUNT_POINT" ]; then
> > > +		echo "Cannot find mount point for ${LAST_PART}"
> > > +		exit 1
> > > +	fi
> > > +	mount "${MOUNT_POINT}" || true
> > > +	/lib/systemd/systemd-growfs "${MOUNT_POINT}"
> > > +else
> > > +	resize2fs "${LAST_PART}"
> > > +fi
> > 
> > I wonder if / how long we should keep the two paths...
> 
> Same here. Quite sure that stretch would not be OK, but it's unclear to
> me if we (should) still care...

Sorry, forgot something:

Is systemd-growfs able to handle the typical "resize boundary
problems"? While looking at the y2038 stuff last time we figured out
that inode size is calculated at file system creation time. So it is
quite dangerous to enlarge a quite small file system to a huge one. The
inode size can not be changed again during resize operation. So they
might "run out of space" / curious things can happen.

That was at least a problem for ext3/4 in the past. Don't know about
the others...

There should be an internal issue for that topic, but I was unable to
find it within a few seconds.

> 
> Florian
> 
> > 
> > Jan
> > 
> > -- 
> > Siemens AG, Technology
> > Competence Center Embedded Linux
> > 
>