public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "Schaffner, Tobias" <tobias.schaffner@siemens.com>
To: "Schild, Henning" <henning.schild@siemens.com>
Cc: isar-users <isar-users@googlegroups.com>
Subject: Re: [PATCH 2/2] Always try resizing the fs in expand on first boot
Date: Wed, 9 Nov 2022 10:11:29 +0000	[thread overview]
Message-ID: <c0cdb9af-6352-63e8-6089-0cceaf0c1053@siemens.com> (raw)
In-Reply-To: <20221109105227.1ebe06b1@md1za8fc.ad001.siemens.net>

On 09.11.22 09:52, Schild, Henning (T CED SES-DE) wrote:
> Hi,
> 
> if the scripts runs into a problem that is likely severe and should not
> have happened in the first place. Making it more robust and so that it
> can be run multiple times still does not hurt.
> 
> But really what one would need to do is make a copy of the original
> partition table and restore that when the fs resize fails, in some exit
> hook.
> 
> What you are doing here would only skip the partition resize on a
> second call and maybe run into the same error again later on. Whatever
> that error might have been. So we better understand the nature of such
> errors instead of making that script so that we try over and over ...
> and maybe always fail.
> 
> In fact the longer term plan was to move this to use systemds
> first-boot semantics instead of that self-disabling trick.
> 
> Henning

I like the idea of restoring the partition table after a failed resize. 
That covers the usecase that sfdisk did something wrong which I have not 
considered yet.

What this patch tried to fix in the first place where these two scenarios:
* The script gets interrupted for e.g. because of power cycle after 
repartitioning.
* The uevent after the partx -u takes longer than expected and the 
resize resizes to the old partition size or fails because of that.

Rare cases but may happen with many devices in the field.

> Am Tue, 8 Nov 2022 12:28:37 +0100
> schrieb "T. Schaffner" <tobias.schaffner@siemens.com>:
> 
>> From: Tobias Schaffner <tobias.schaffner@siemens.com>
>>
>> If the filesystem resize fails or gets interrupted we have no way to
>> recover from this as the script always exits if the partition was
>> already resized.
>>
>> Check if we have to resize the partition but alway run the chosen fs
>> resize tool. Leave the decision if the filesystem has to be resized
>> to resize2fs / systemd-growfs.
>> If the filesystem was already expanded the resize2fs / systemd-growfs
>> call is a noop.
>>
>> Signed-off-by: Tobias Schaffner <tobias.schaffner@siemens.com>
>> ---
>>   .../files/expand-last-partition.sh            | 35
>> +++++++++---------- 1 file changed, 16 insertions(+), 19 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 0d662cc..b21b958 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
>> @@ -35,26 +35,23 @@ LAST_PART_START="$(cat
>> /sys/class/block/"${LAST_PART_NAME}"/start)" GPT_BACKUP_SIZE=33 if [
>> $((LAST_PART_START + LAST_PART_SIZE + GPT_BACKUP_SIZE)) -lt
>> "${DISK_SIZE}" ]; then
>> -	echo "Disk is practically already full, doing nothing." >&2
>> -	exit 0
>> -fi
>> +	# Transform the partition table as follows:
>> +	#
>> +	# - Remove any 'last-lba' header so sfdisk uses the entire
>> available space.
>> +	# - If this partition table is MBR and an extended partition
>> container (EBR)
>> +	#   exists, we assume this needs to be expanded as well;
>> remove its size
>> +	#   field so sfdisk expands it.
>> +	# - For the previously fetched last partition, also remove
>> the size field so
>> +	#   sfdisk expands it.
>> +	sfdisk -d "${BOOT_DEV}" 2>/dev/null | \
>> +		grep -v last-lba | \
>> +		sed 's|^\(.*, \)size=[^,]*, \(type=[f5]\)$|\1\2|' | \
>> +		sed 's|^\('"${LAST_PART}"' .*, \)size=[^,]*, |\1|' |
>> \
>> +		sfdisk --force "${BOOT_DEV}"
>>   
>> -# Transform the partition table as follows:
>> -#
>> -# - Remove any 'last-lba' header so sfdisk uses the entire available
>> space. -# - If this partition table is MBR and an extended partition
>> container (EBR) -#   exists, we assume this needs to be expanded as
>> well; remove its size -#   field so sfdisk expands it.
>> -# - For the previously fetched last partition, also remove the size
>> field so -#   sfdisk expands it.
>> -sfdisk -d "${BOOT_DEV}" 2>/dev/null | \
>> -	grep -v last-lba | \
>> -	sed 's|^\(.*, \)size=[^,]*, \(type=[f5]\)$|\1\2|' | \
>> -	sed 's|^\('"${LAST_PART}"' .*, \)size=[^,]*, |\1|' | \
>> -	sfdisk --force "${BOOT_DEV}"
>> -
>> -# Inform the kernel about the partitioning change
>> -partx -u "${LAST_PART}"
>> +	# Inform the kernel about the partitioning change
>> +	partx -u "${LAST_PART}"
>> +fi
>>   
>>   # this is for debian stretch or systemd < 236
>>   if [ ! -x /lib/systemd/systemd-growfs ]; then
> 

      reply	other threads:[~2022-11-09 10:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-08 11:28 [PATCH 0/2] expand-on-first-boot: try fs resize on expanded partitions T. Schaffner
2022-11-08 11:28 ` [PATCH 1/2] Check if last partition ends at GPT backup header T. Schaffner
2022-11-09  8:26   ` Henning Schild
2022-11-09  9:40     ` Schaffner, Tobias
2022-11-09 14:54       ` Henning Schild
2022-11-08 11:28 ` [PATCH 2/2] Always try resizing the fs in expand on first boot T. Schaffner
2022-11-09  8:52   ` Henning Schild
2022-11-09 10:11     ` Schaffner, Tobias [this message]

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=c0cdb9af-6352-63e8-6089-0cceaf0c1053@siemens.com \
    --to=tobias.schaffner@siemens.com \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.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