qcow2 cloud image filesystem not resized to full

[Scott Moser]

The cloud image qcow filesystems require resizing before use.
This is really just silly.

Additionally, growpart can grow them. We should distribute them with the filesystem grown to the full size.

In summary of below, what I see is:
  * all images are 2.2G disks (seems like 2.0 might be a better choice)
  * filesystem on partition 1 is:
    1.4G in trusty and utopic
    ~900M in vivid and wily
  * While the partition sizes are consistent (which is good), in all cases
    there is > 200M of unallocated space at the end of the disk.
  * i failed to show it well, but in each case, the fs doesnt even take up all space it could inside the partition. In vivid, there is *plenty* of room in the image, but not in the filesystem.

cloud-init and growpart fix all of these before a booted system finds them, but it is pointless to distribute them like this and require that additional IO.
Additionally, the user who is trying to modify the image outside of booting it has complexity added as they have to grow the partition and resize the filesystem.

$ ./image-info get
...

$ ./image-info trusty* utopic* vivid* wily* 2>/dev/null
==== file size info ===
-rw-rw-r-- 1 ubuntu ubuntu 257360384 Jun 9 05:28 trusty-server-cloudimg-amd64-disk1.img
-rw-r--r-- 1 ubuntu ubuntu 2361393152 Jun 10 19:02 trusty-server-cloudimg-amd64-disk1.img.raw
-rw-rw-r-- 1 ubuntu ubuntu 268370432 Jun 8 17:08 utopic-server-cloudimg-amd64-disk1.img
-rw-r--r-- 1 ubuntu ubuntu 2361393152 Jun 10 19:02 utopic-server-cloudimg-amd64-disk1.img.raw
-rw-rw-r-- 1 ubuntu ubuntu 285344256 Jun 9 07:50 vivid-server-cloudimg-amd64-disk1.img
-rw-r--r-- 1 ubuntu ubuntu 2361393152 Jun 10 19:03 vivid-server-cloudimg-amd64-disk1.img.raw
-rw-rw-r-- 1 ubuntu ubuntu 285540864 Jun 8 23:50 wily-server-cloudimg-amd64-disk1.img
-rw-r--r-- 1 ubuntu ubuntu 2361393152 Jun 10 19:03 wily-server-cloudimg-amd64-disk1.img.raw
==== filesystem usage info ===
== trusty-server-cloudimg-amd64-disk1.img.raw ==
- 1.4G 767M 501M 61% /
Block count: 360448
Block size: 4096
== utopic-server-cloudimg-amd64-disk1.img.raw ==
- 1.4G 791M 477M 63% /
Block count: 360448
Block size: 4096
== vivid-server-cloudimg-amd64-disk1.img.raw ==
- 912M 839M 58M 94% /
Block count: 245248
Block size: 4096
== wily-server-cloudimg-amd64-disk1.img.raw ==
- 911M 837M 58M 94% /
Block count: 244736
Block size: 4096
==== growpart info ====
== trusty-server-cloudimg-amd64-disk1.img.raw ==
CHANGE: partition=1 start=2048 old: size=4192256 end=4194304 new: size=4610048,end=4612096
== utopic-server-cloudimg-amd64-disk1.img.raw ==
CHANGE: partition=1 start=2048 old: size=4192256 end=4194304 new: size=4610048,end=4612096
== vivid-server-cloudimg-amd64-disk1.img.raw ==
CHANGE: partition=1 start=2048 old: size=4192256 end=4194304 new: size=4610048,end=4612096
== wily-server-cloudimg-amd64-disk1.img.raw ==
CHANGE: partition=1 start=2048 old: size=4192256 end=4194304 new: size=4610048,end=4612096

--
Related bugs:
 * bug 1795512: images should be sized as a whole GB

[Scott Moser (smoser)]

Note, I found this in real-world usage scenario, when trying to verify the fix for bug 1455233
I was unable to just do:

sudo mount-image-callback --system-resolvconf --system-mounts vivid-server-cloudimg-amd64-disk1.qcow2 -- \
   chroot _MOUNTPOINT_ sh -c '
     rel=$(lsb_release -sc);
     echo "deb http://archive.ubuntu.com/ubuntu $rel-proposed main" |
       tee /etc/apt/sources.list.d/proposed.list && apt-get update &&
      apt-get install cloud-init grub-legacy-ec2 && apt-cache policy cloud-init'

As I got a filesystem full.
That doesn't seem like a terribly unreasonable thing to want to do.

[Scott Moser (smoser)]

example resize info with vivid:
$ qemu-img create -f qcow2 -b vivid-server-cloudimg-amd64-disk1.qcow2.dist vivid-server-cloudimg-amd64-disk1.qcow2
Formatting 'vivid-server-cloudimg-amd64-disk1.qcow2', fmt=qcow2 size=2361393152 backing_file='vivid-server-cloudimg-amd64-disk1.qcow2.dist' encryption=off cluster_size=65536 lazy_refcounts=off

$ sudo mount-image-callback --system-resolvconf --system-mounts \
   vivid-server-cloudimg-amd64-disk1.qcow2 -- chroot _MOUNTPOINT_ \
    bash -ec 'set -o pipefail;
      dev=$(awk "\$2 == \"/\" { d=\$1 }; END { print d }" "mp=$MOUNTPOINT" /proc/mounts);
      df -k /; resize2fs $dev; df -k /; ' 2>/dev/null
Filesystem 1K-blocks Used Available Use% Mounted on
- 933848 859096 58368 94% /
Filesystem at /dev/nbd0p1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 1
The filesystem on /dev/nbd0p1 is now 524032 (4k) blocks long.

Filesystem 1K-blocks Used Available Use% Mounted on
- 2018256 859604 1142268 43% /

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1463963/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Scott Moser (smoser)]

I ran the updated 'image-info.sh' today and see that this appears to be fixed in xenial, bionic, and cosmic.

The 'growpart --dry-run' output is essentially what indicates fixed.
the image should have NOCHANGE as the existing partition should be grown
as large as it can be. It should fill the disk size we ship.

A separate oddity is that we ship am image of 2361393152 bytes.
That is close to 2.2GB. I suspect that that what got us here was a desire
for about a 2G root filesystem + EFI partition and bios boot partition.
It probably would have made more sense to start at 2G and removed the
needed space for bios boot and EFI system partition. The reason for that
would be that when someone adds a virtual disk, they're quite likely
to do it in even GB rather. So we do not fit in 2G (even though we could).

$ sudo ../image-info.sh *.raw
==== file size info ===
-rw-r--r-- 1 smoser smoser 2361393152 Oct 1 20:48 bionic-server-cloudimg-amd64.raw
-rw-r--r-- 1 smoser smoser 2361393152 Oct 1 20:49 cosmic-server-cloudimg-amd64.raw
-rw-r--r-- 1 smoser smoser 2361393152 Oct 1 20:48 trusty-server-cloudimg-amd64-disk1.raw
-rw-r--r-- 1 smoser smoser 2361393152 Oct 1 20:48 xenial-server-cloudimg-amd64-disk1.raw
==== filesystem usage info ===
== bionic-server-cloudimg-amd64.raw ==
- 2.0G 945M 1.1G 48% /
dumpe2fs 1.44.4 (18-Aug-2018)
Block count: 548091
Block size: 4096
== cosmic-server-cloudimg-amd64.raw ==
- 2.0G 932M 1.1G 47% /
dumpe2fs 1.44.4 (18-Aug-2018)
Block count: 548091
Block size: 4096
== trusty-server-cloudimg-amd64-disk1.raw ==
- 1.4G 798M 471M 63% /
dumpe2fs 1.44.4 (18-Aug-2018)
Block count: 360448
Block size: 4096
== xenial-server-cloudimg-amd64-disk1.raw ==
- 2.1G 857M 1.3G 41% /
dumpe2fs 1.44.4 (18-Aug-2018)
Block count: 576000
Block size: 4096
==== growpart info ====
== bionic-server-cloudimg-amd64.raw ==
NOCHANGE: partition 1 is size 4384735. it cannot be grown
== cosmic-server-cloudimg-amd64.raw ==
NOCHANGE: partition 1 is size 4384735. it cannot be grown
== trusty-server-cloudimg-amd64-disk1.raw ==
CHANGE: partition=1 start=2048 old: size=4192256 end=4194304 new: size=4610015 end=4612063
# === old sfdisk -d ===
label: dos
label-id: 0x000a6fbe
device: trusty-server-cloudimg-amd64-disk1.raw
unit: sectors

trusty-server-cloudimg-amd64-disk1.raw1 : start= 2048, size= 4192256, type=83, bootable
# === new sfdisk -d ===
label: dos
label-id: 0x000a6fbe
device: trusty-server-cloudimg-amd64-disk1.raw
unit: sectors

trusty-server-cloudimg-amd64-disk1.raw1 : start= 2048, size= 4610015, type=83, bootable
== xenial-server-cloudimg-amd64-disk1.raw ==
NOCHANGE: partition 1 could only be grown by 2015 [fudge=2048]

[Scott Moser (smoser)]

So we're in much better shape now than we were several years ago.
But I've filed bug 1795512 to track the idea/request for whole-GB sized images.

[Dan Watkins (oddbloke)]

Thanks for the confirmation, Scott! As this is fixed in the two most recent LTSes (and going forward), I'm going to mark this as Fix Released.

(Given where trusty is in its lifecycle, anyone for whom this might cause problems there has already worked around it, so I think we'll leave it as-is unless we get a compelling reason to change. The way image building in trusty works means that we can't just make changes to the download images, so we would have to do validation across the cloud platforms we support, which makes it less trivial than it might otherwise sound.)