On Tue, Oct 11, 2016 at 06:12:06PM +0200, Oliver Grawert wrote: > Am Dienstag, den 11.10.2016, 11:55 -0400 schrieb Barry Warsaw: > > On Oct 11, 2016, at 05:01 PM, Oliver Grawert wrote:
> > > defining it in the gadget would be rather awful since that means if we > > > use an identical image for cloud, VM and "normal PC install" we would > > > need a gadget per image just for that one difference ... (the pc > > > image that you can use for all three consists of: pc (gadget, > > > pc-kernel (obviously kernel) and core (rootfs). > > That's the data point I was looking for, thanks! > > Can you explain in more detail why kvm images need some extra space, but > > other images do not? > on VMs the img file defines the "physical VM disk" while for an actual > install you write the img file to a pyhsical disk device ... the resize > code will find that the partition table does not cover all of the disk > before first boot and start the resize process so here the img size > wont be taken into account at all. > on a VM, all the resize code will see is the img file that pretends to > be a harddisk and it will find there is nothing to resize to. > > Also, if you specify a fudge factor via cli/envar, should that be > > applied in addition to, or instead of, any built-in compensation for > > file system overhead? > i dont mind either, whatever is easier to implement (as long as the > help documents the right behaviour) ;) I don't think a 'fudge factor' option is particularly clean or intuitive. I think what you actually want is to be able to declare the overall size of the image that you're building. It's a waste of mental energy to think about VM image sizes in increments less than 1G, especially given that these are all still going to be sparse files. So I would suggest: - 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/. How does that sound? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [email protected] [email protected]
signature.asc
Description: PGP signature
-- Devices mailing list [email protected] Modify settings or unsubscribe at: https://lists.snapcraft.io/mailman/listinfo/devices
