Re: WARNING: expand-on-first boot might shrink your partition on Debian bookworm

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

Am Thu, 7 Jul 2022 12:51:55 +0200
schrieb "Bezdeka, Florian (T CED SES-DE)" <florian.bezdeka@siemens.com>:

> 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.

Ok, i was assuming a minor shrinking of both partition and filesystem
can work as long as the filesystem has space left to shrink.

> > 
> > 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.

No problem! The script is set -e and we will fail without breaking
anything, unfortunately also without doing its job. If people want the
feature they can then dig out what they might be missing in their
configs. That is the price to pay when using weird configs ;).

Henning

> > 
> > 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
> > >   
> >   
>