I am trying to decide what size to specify in our gadget yaml for the ubuntu-data section.
From what I understand, this section is always at the end of the image. And I understand that consequently on hardware the full “space” that is leftover is used for this section. Please correct me if I’m wrong.
Why would you not make it as small as possible? Since setting it bigger results in a bigger image without adding any value? It takes longer to write to the hardware and bigger to store (I guess you probably can get around the latter with compression).
When loading in QEMU the set ubuntu-data size is used. However, you can easily create more space when needed (see earlier question). In fact, I would prefer the user of my image to be aware of needing to grow the space, because having slightly too little space can lead to the image not booting with no feedback/errors. We spent days figuring out why a specific image didn’t boot on QEMU, which was apparently running out of space during first boot (with the default 1G that comes in the pc-gadget snap repository.
Regards,
Charlee
P.S. I read/heard that in the past a size for the ubuntu-data section was not mandatory, why did this change?
P.P.S. Reason for posting this is partly for others that might run in similar non-booting images due to running out of space with QEMU, and to increase information out there on how to use ubuntu-data section.
for qemu you should be able to use the -i option to ubuntu-image, that should create a big enough “disk” to grow that partition properly in install mode on first boot:
-i, --image-size=SIZE The suggested size of the generated disk image file. If this
size is smaller than the minimum calculated size of the image a
warning will be issued and --image-size will be ignored. The
value is the size in bytes, with allowable suffixes "M" for MiB
and "G" for GiB. Use an extended syntax to define the suggested
size for the disk images generated by a multi-volume gadget.yaml
spec
I personally prefer building 1 image and increasing the size if booting in qemu, like that the same image can be made for hardware and qemu and we don’t have to run ubuntu-image twice.
right, i was just referring to the need to adjust the volume size and have a separate gadget then …
we used to not need to specify the size of ubuntu-seed in the past and it would just be sized big enough to fit in all selected snaps, but with the addition of more partitons in UC20 onwards it was decided that ubuntu-seed needs specifying too (you might add the ubuntu-save partition to the end for example … before there was no such option)
Right, we have the ubuntu-save partition before the ubuntu-data partition. In fact, here it says this HAS to be the case: https://snapcraft.io/docs/the-gadget-snap (see second last section of volumes mapping).
Anyway, do you see any issues with specifying ubuntu-data as 32M and just always increasing size before booting it in QEMU?
