[Bug 1905990] Re: UC20 amd64 images are unnecessarily big

[Łukasz Zemczak]

Pushed a modified version to focal-proposed. We decided to hardcode the
previous, smaller size (3.7 GB) instead. The same change has been pushed
to the hirsute master branch - not released, as we do not really build
any real images on hirsute (there's the test UC22 images, but oh well).
The change will be released with the next batch of livecd-rootfs
changes.

** Description changed:

  [Impact]
  
  To work-around a bug in ubuntu-image, we hard-coded a `--image-size 8G` in livecd-rootfs for UC20 image builds. The reason for that was that ubuntu-image, in its initial UC20 image build implementation, was skipping yet-to-be-created partitions while calculating the final image size. This was fixed in ubuntu-image 1.10, and now the workaround is no longer required.
  Additionally, the HWE team asked if it would be possible for the amd64 images to be smaller than 8GB as they need them to fit on 4GB storage. Without the hard-coded image size the UC20 images are around 3.1GB in size - which would be perfect for their needs.
+ 
+ That being said, after some additional discussion, we decided to still
+ hard-code the size, but to a smaller value - same as we do for UC18 and
+ UC16. This is to make sure there's enough writable disk space for normal
+ usage.
  
  [Test case]
  
  Build a -proposed based UC20 focal amd64 image via live-build. Download
  the image, decompress it and run `parted <imagefile>`. Print the
  partition table and make sure that the image is now big enough for all
  the contents (so at least 3GB) but smaller than the previous hard-coded
  size (8GB).
  
  [What could go wrong]
  
- The only parts I could see regressing is the thing we want to actually
- fix: so ultimately ubuntu-image not calculating the size properly. But
- this was already verified before pushing this SRU. The change only
- affects ubuntu-core focal+ builds, so the regression risk is really
- minimal.
+ Right now there's no real places where things could go wrong. If
+ anything, the size wouldn't be modified, but this is something we test
+ for in the test case. Image build failures in case of busted bash
+ syntax, but we'd see that instantly as well.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to livecd-rootfs in Ubuntu.
https://bugs.launchpad.net/bugs/1905990

Title:
  UC20 amd64 images are unnecessarily big

Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in livecd-rootfs source package in Focal:
  In Progress
Status in livecd-rootfs source package in Groovy:
  Invalid

Bug description:
  [Impact]

  To work-around a bug in ubuntu-image, we hard-coded a `--image-size 8G` in livecd-rootfs for UC20 image builds. The reason for that was that ubuntu-image, in its initial UC20 image build implementation, was skipping yet-to-be-created partitions while calculating the final image size. This was fixed in ubuntu-image 1.10, and now the workaround is no longer required.
  Additionally, the HWE team asked if it would be possible for the amd64 images to be smaller than 8GB as they need them to fit on 4GB storage. Without the hard-coded image size the UC20 images are around 3.1GB in size - which would be perfect for their needs.

  That being said, after some additional discussion, we decided to still
  hard-code the size, but to a smaller value - same as we do for UC18
  and UC16. This is to make sure there's enough writable disk space for
  normal usage.

  [Test case]

  Build a -proposed based UC20 focal amd64 image via live-build.
  Download the image, decompress it and run `parted <imagefile>`. Print
  the partition table and make sure that the image is now big enough for
  all the contents (so at least 3GB) but smaller than the previous hard-
  coded size (8GB).

  [What could go wrong]

  Right now there's no real places where things could go wrong. If
  anything, the size wouldn't be modified, but this is something we test
  for in the test case. Image build failures in case of busted bash
  syntax, but we'd see that instantly as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1905990/+subscriptions