Size of system-data partition is not respected when specified

[Alfonso Sanchez-Beato]

When the size of the system data partition is specified in the gadget snap, like in:

https://github.com/alfonsosanchezbeato/pc-amd64-gadget-cpc/blob/master/gadget.yaml

It turns out that this is not fully respected: "parted" actually shows the right size, but when mounting the partition, "df -h ." reveals that the size is much less.

This is because the partition is properly created, but the filesystem inside the partition is not filling the partition.

A workaround for this is running these commands on the partition:

# e2fsck -fy <part>
# resize2fs <part>

But this should not be necessary indeed.

This is for 17.04, I am under the impression of this being relevant.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

Fix for this (Gary's branch); https://github.com/adglkh/ubuntu-image/pull/1

[Steve Langasek (vorlon)]

On Fri, Sep 22, 2017 at 07:25:12AM -0000, Alfonso Sanchez-Beato wrote:
> Public bug reported:
>
> When the size of the system data partition is specified in the gadget
> snap, like in:
>
> https://github.com/alfonsosanchezbeato/pc-amd64-gadget-
> cpc/blob/master/gadget.yaml
>
> It turns out that this is really respected: "parted" actually shows the
> right size, but when mounting the partition, "df -h ." reveals that the
> size is much less.
>
> This is because the partition is properly created, but the filesystem
> inside the partition is not filling the partition.
>
> A workaround for this is running these commands on the partition:
>
> # e2fsck -fy <part>
> # resize2fs <part>
>
> But this should not be necessary indeed.

It already shouldn't be necessary because the ubuntu-core initramfs resizes
the root filesystem at first boot. Is this not the behavior you're seeing?

Expanding the filesystem at creation time will decrease the sparseness of
the image. We want to keep the disk images that we ship as small as
possible; the first boot penalty for expanding the filesystem with resize2fs
is small enough that I think this is the right tradeoff (and, we still need
that code anyway because in the non-VM case, the target disk size may be
larger than our image).

So the current behavior is by design, and I don't think we should change it.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

The additional space is useful if you want to chroot into the partition and add stuff, like new packages, before first boot. This is a real use case when creating customized images on top of ubuntu-image output.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

Besides, not sure if I agree on whether not expanding the partition/fs helps with the size. If it is the raw dd image, it does not. If we are talking about the compressed image, I am not sure if there is a great impact, as regardless of whether the extra size is included in the partition or not, it should be mostly a bunch of zeros if unused.