public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "Bezdeka, Florian" <florian.bezdeka@siemens.com>
To: "Schild, Henning" <henning.schild@siemens.com>
Cc: "isar-users@googlegroups.com" <isar-users@googlegroups.com>,
	"jan.kiszka@siemens.com" <jan.kiszka@siemens.com>,
	"Moessbauer, Felix" <felix.moessbauer@siemens.com>,
	"Schmidl, Tobias" <tobiasschmidl@siemens.com>
Subject: Re: WARNING: expand-on-first boot might shrink your partition on Debian bookworm
Date: Thu, 7 Jul 2022 10:51:55 +0000	[thread overview]
Message-ID: <555a6a79f1ba0deb8e54cac6df7fa0dcb1b6ca40.camel@siemens.com> (raw)
In-Reply-To: <20220707105446.72db67c1@md1za8fc.ad001.siemens.net>

On Thu, 2022-07-07 at 10:54 +0200, Henning Schild wrote:
> Am Thu, 7 Jul 2022 09:48:22 +0200
> schrieb Florian Bezdeka <florian.bezdeka@siemens.com>:
> 
> > Hi all,
> > 
> > here comes another Debian bookworm related problem. This time related
> > to expand-on-first-boot, which destroys my image during the fist boot.
> > 
> > The linux-util packages has been updated and includes some changes
> > related to partition alignment. See [1]. (Thanks Henning for pointing
> > me here.) It might happen now that the last partition is shrinked
> > instead of expanded.
> > 
> > This is especially relevant for setups where the last partition is the
> > root partition and where no more space is available (e.g. booting up a
> > wic image with qemu where disk size = image size)
> > 
> > The original partition table looked like this:
> > 
> > label: gpt
> > label-id: 8CC4BCD4-F7B9-45F1-A066-DFB4068D6DFC
> > device: /dev/sda
> > unit: sectors
> > first-lba: 34
> > last-lba: 4554194
> > sector-size: 512
> > 
> > After expand-on-first-boot it looks like that:
> > (note the last-lba field)
> > 
> > label: gpt
> > label-id: 5305C98F-17AD-4B41-9388-7DC319741C9D
> > device: talker-debian-bookworm-qemuamd64.wic
> > unit: sectors
> > first-lba: 34
> > last-lba: 4554320
> > sector-size: 512
> > 
> > Booting up again stops in the initrd with the following error:
> > 
> > (initramfs) [    1.978569] EXT4-fs (sda2): bad geometry: block count
> > 550586 exceeds size of device (550400 blocks)
> > 
> > resize2fs called from expand-last-partition.sh already throws a
> > warning resize2fs: New size smaller than minimum (550586)
> > 
> > Ideas welcome...
> > Taking over even more...
> 
> I think one idea as a quick hack in an affected layer could be to add
> more EXTRA_SPACE, but i did not try that. With more space a slight
> shrinking might just work. Or put a large fixes size in your wks ... or
> play with alignment there to avoid shrinking.

I played around with that as well, the problem is that you have to find
a matching value for EXTRA_SPACE to avoid the alignment. Once found it
may break again with one more package added to the image.

> 
> And the good solution would probably to detect that the disk is already
> "close to full" and simply step out early.
> 
> if /sys/class/block/sda/size - sum(/sys/class/block/sda/sda*/size) < 32M
> echo "Nothing to do"; exit 0

I like the idea but keep in mind that such sysfs or procfs entries
might not exist in all cases. There might be custom kernel
configurations out there with such features disabled. Might not be a
real world problem, but if so we would break such setups. So far we
only had dependencies to user space components.

> 
> Where 32M is made up, one should look up what the maximum shrink could
> be. I think we could even say 4M. Or we could use percentage ... if sum
> > = 0.95*size
> 
> Henning
> 
> > Best regards,
> > Florian
> > 
> > 
> > [1]
> > https://github.com/util-linux/util-linux/commit/921c7da55ec78350e4067b3fd6b7de6f299106ee
> > 
> 


  reply	other threads:[~2022-07-07 10:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-07  7:48 Florian Bezdeka
2022-07-07  8:20 ` Schmidl, Tobias
2022-07-07  8:54 ` Henning Schild
2022-07-07 10:51   ` Bezdeka, Florian [this message]
2022-07-07 11:18     ` Henning Schild
2022-07-07  8:59 ` Henning Schild
2022-07-07  9:30   ` Schmidl, Tobias
2022-07-07  9:33     ` Henning Schild
2022-07-08  6:35 ` Schmidl, Tobias
2022-07-08  6:46   ` Jan Kiszka

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=555a6a79f1ba0deb8e54cac6df7fa0dcb1b6ca40.camel@siemens.com \
    --to=florian.bezdeka@siemens.com \
    --cc=felix.moessbauer@siemens.com \
    --cc=henning.schild@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=jan.kiszka@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