qcow2 cloud image filesystem not resized to full
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-images |
Fix Released
|
Medium
|
Dan Watkins |
Bug Description
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-
-rw-r--r-- 1 ubuntu ubuntu 2361393152 Jun 10 19:02 trusty-
-rw-rw-r-- 1 ubuntu ubuntu 268370432 Jun 8 17:08 utopic-
-rw-r--r-- 1 ubuntu ubuntu 2361393152 Jun 10 19:02 utopic-
-rw-rw-r-- 1 ubuntu ubuntu 285344256 Jun 9 07:50 vivid-server-
-rw-r--r-- 1 ubuntu ubuntu 2361393152 Jun 10 19:03 vivid-server-
-rw-rw-r-- 1 ubuntu ubuntu 285540864 Jun 8 23:50 wily-server-
-rw-r--r-- 1 ubuntu ubuntu 2361393152 Jun 10 19:03 wily-server-
==== filesystem usage info ===
== trusty-
- 1.4G 767M 501M 61% /
Block count: 360448
Block size: 4096
== utopic-
- 1.4G 791M 477M 63% /
Block count: 360448
Block size: 4096
== vivid-server-
- 912M 839M 58M 94% /
Block count: 245248
Block size: 4096
== wily-server-
- 911M 837M 58M 94% /
Block count: 244736
Block size: 4096
==== growpart info ====
== trusty-
CHANGE: partition=1 start=2048 old: size=4192256 end=4194304 new: size=4610048,
== utopic-
CHANGE: partition=1 start=2048 old: size=4192256 end=4194304 new: size=4610048,
== vivid-server-
CHANGE: partition=1 start=2048 old: size=4192256 end=4194304 new: size=4610048,
== wily-server-
CHANGE: partition=1 start=2048 old: size=4192256 end=4194304 new: size=4610048,
--
Related bugs:
* bug 1795512: images should be sized as a whole GB
Changed in ubuntu: | |
assignee: | Ben Howard (utlemming) → Dan Watkins (daniel-thewatkins) |
Changed in ubuntu: | |
status: | Confirmed → In Progress |
affects: | ubuntu → cloud-images |
tags: |
added: cloud-images-build removed: cloud-image-build |
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 -- \ $(lsb_release -sc); archive. ubuntu. com/ubuntu $rel-proposed main" | sources. list.d/ proposed. list && apt-get update &&
chroot _MOUNTPOINT_ sh -c '
rel=
echo "deb http://
tee /etc/apt/
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.