From: Henning Schild <henning.schild@siemens.com>
To: Tobias Schmidl <tobiasschmidl@siemens.com>
Cc: <isar-users@googlegroups.com>, Joe MacDonald <joe.macdonald@siemens.com>
Subject: Re: [PATCH v4 1/1] expand-on-first-boot: Switch from resize2fs to systemd-growfs
Date: Wed, 29 Jun 2022 18:33:33 +0200 [thread overview]
Message-ID: <20220629183333.4443bd8e@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <20220629120144.507398-2-tobiasschmidl@siemens.com>
Am Wed, 29 Jun 2022 14:01:44 +0200
schrieb Tobias Schmidl <tobiasschmidl@siemens.com>:
> We want to be more versatile in our approach of resizing the last
> partition. Therefore we switch from resize2fs to systemd-growfs.
>
> This allows for ext4, btrfs, xfs, and dm-crypt partitions to be
> resized.
>
> Since systemd-growfs landed in v236, this obsoletes
> expand-on-first-boot on stretch (v232).
>
> Signed-off-by: Tobias Schmidl <tobiasschmidl@siemens.com>
> ---
> ...oot_1.1.bb => expand-on-first-boot_1.2.bb} | 5 +++--
> .../files/expand-last-partition.sh | 21
> +++++++++++++++++-- 2 files changed, 22 insertions(+), 4 deletions(-)
> rename
> meta/recipes-support/expand-on-first-boot/{expand-on-first-boot_1.1.bb
> => expand-on-first-boot_1.2.bb} (78%)
>
> diff --git
> a/meta/recipes-support/expand-on-first-boot/expand-on-first-boot_1.1.bb
> b/meta/recipes-support/expand-on-first-boot/expand-on-first-boot_1.2.bb
> similarity index 78% rename from
> meta/recipes-support/expand-on-first-boot/expand-on-first-boot_1.1.bb
> rename to
> meta/recipes-support/expand-on-first-boot/expand-on-first-boot_1.2.bb
> index 1703a64..48d30d3 100644 ---
> a/meta/recipes-support/expand-on-first-boot/expand-on-first-boot_1.1.bb
> +++
> b/meta/recipes-support/expand-on-first-boot/expand-on-first-boot_1.2.bb
> @@ -1,15 +1,16 @@ # Resize last partition to full medium size on fist
> boot # # This software is a part of ISAR. -# Copyright (c) Siemens
> AG, 2018 +# Copyright (c) Siemens AG, 2018-2022 #
> # SPDX-License-Identifier: MIT
>
> inherit dpkg-raw
>
> DESCRIPTION = "This service grows the last partition to the full
> medium during first boot" +MAINTAINER = "isar-users
> <isar-users@googlegroups.com>"
> -DEBIAN_DEPENDS = "systemd, sed, grep, coreutils, mount, e2fsprogs,
> fdisk, util-linux" +DEBIAN_DEPENDS = "systemd (>=236), sed, grep,
> coreutils, mount, fdisk, util-linux"
> SRC_URI = " \
> file://expand-on-first-boot.service \
> 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 c0edde7..1743890 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,21 @@ partx -u "${LAST_PART}"
> # when using systemd mount units.
> export EXT2FS_NO_MTAB_OK=1
>
> -resize2fs "${LAST_PART}"
> +if grep -q x-systemd.growfs /etc/fstab; then
> + echo "Found x-systemd.growfs option in /etc/fstab, won't
> call it explicitly." >&2
> + exit 0
> +fi
> +
> +MOUNT_POINT=$(findmnt -o target -n "${LAST_PART}")
> +UNMOUNT_AFTERWORDS=0
> +if [ -z "${MOUNT_POINT}" ]; then
> + MOUNT_POINT=$(findmnt -o target -n --fstab "{$LAST_PART}")
> + if [ -z "${MOUNT_POINT}" ]; then
> + echo "Cannot find mount point for ${LAST_PART}" >&2
> + exit 1
> + else
> + UNMOUNT_AFTERWORDS=1
> + fi
> +fi
> +/lib/systemd/systemd-growfs "${MOUNT_POINT}"
> +[ $UNMOUNT_AFTERWORDS -eq 1 ] && umount "${MOUNT_POINT}"
where did the mount go? i would assume a mount to be here somewhere
which happens in the context where we remember that we have to umount
Here a "noauto" in the fstab line of that last partition should help to
put that script into the role of the mounter and actually test that
path.
So the problem is that the partition needs to be mounted to get
resized. And now we have the problem to sync up with other mounters and
potentially having to umount ... not as easy as it sounds. We need to
get the order right and know things like "noauto" or other fun
exceptions.
I suggest to try and --bind mount it to /tmp/partition-to-expand ... if
we are lucky we can grow it when mounted twice and unconditionally
mount/umount without ever having to findmnt. But i am kind of afraid of
an EBUSY ...
Henning
next prev parent reply other threads:[~2022-06-29 16:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-29 12:01 [PATCH v4 0/1] " Tobias Schmidl
2022-06-29 12:01 ` [PATCH v4 1/1] " Tobias Schmidl
2022-06-29 12:13 ` Jan Kiszka
2022-06-29 16:33 ` Henning Schild [this message]
2022-06-29 17:00 ` Henning Schild
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220629183333.4443bd8e@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=joe.macdonald@siemens.com \
--cc=tobiasschmidl@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox