It doesn't make much sense to have an option that controls the generated
disk image size by itself. We have multiple volumes, multiple images, and
multiple partitions inside any given volume. What is the size referring to?
To make sense of it, ubuntu-image must necessarily learn more about what to
do with that value via the gadget.yaml itself.

On Oct 12, 2016 1:50 PM, "Barry Warsaw" <> wrote:

On Oct 11, 2016, at 10:54 AM, Steve Langasek wrote:

> - a --size option to ubuntu-image to specify the full image size (needs
>   some careful thought for the multiple-image case)
> - keep the 50% buffer on ext4 filesystem size as a floor (the '50%' can be
>   refined over time with investigation into the actual size requirements
>   for ext4 metadata, but this is not a high priority; highest priority is
>   that it works reliably)
> - if --size is smaller than the minimum size needed to accommodate the
>   contents, warn but build the image anyway - because all the expensive
>   work of ubuntu-image happens /before/ we're able to calculate the final
>   size, so throwing that all away at the end would be /very annoying/.

I want to clarify something here which (if I'm right ;) helped me reach a
decision on this.

The "size" that Ogra wants to control is the generated disk image file size,
not the size of any particular partition within that disk image.  IOW, it's
the size of the file that gets written to from the --output/-o option of

There is nothing in the gadget.yaml that describes this value.  It's
calculated by u-i.  More specifically, there is no 'size' option in the
<volume name> section.

If this is correct, then it's obvious (for now, without changes to the
gadget.yaml spec) that only a command line option will work.

I propose to add an option called --image-size (no shortcut) that takes a
parameter in bytes, with allowable suffixes 'M' for MiB and 'G' for GiB'.
Since u-i currently only supports a single volume gadget.yaml, an unindexed
size will apply to the one and only volume.  In the future, when we support
multiple volumes (i.e. disk images), we can extend the syntax.  See LP:
#1632085 for details.

Further, if --image-size is less than the calculated size, I propose that we
warn loudly and ignore --image-size.  That way, we don't throw away all the
work we have to do before we can calculate the image size, but we also don't
generate a corrupted image.

Let me know if this will work for you and/or feel free to comment on the
mentioned bug.


Devices mailing list
Modify settings or unsubscribe at:
Devices mailing list
Modify settings or unsubscribe at:

Reply via email to