Bug 886

Summary: Consider allowing images to request a set amount of free space be available in the generated image
Product: [Build System, Metadata & Runtime] Meta-yocto Reporter: Joshua Lock - Disabled <josh>
Component: configurationAssignee: Saul Wold <sgw>
Status: VERIFIED FIXED QA Contact:
Severity: enhancement    
Priority: Low CC: bluelightning, poky.bs.watcher, poky.watcher
Version: unspecified   
Target Milestone: 1.1   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Joshua Lock - Disabled 2011-03-16 08:30:01 UTC 
When preparing a demo against Bernard my sato based images where filling the disk before the post-install's had even finished running on first boot.

The purpose of this bug is two fold, first I'd suggest that the default IMAGE_OVERHEAD_FACTOR of 1.2 is probably too low for anything other than minimal. A Sato image for emenlow has only 5% free disk space by the time it has finished first boot.

Secondly I wonder if we can introduce a new variable to specify a certain amount of space be available on the image, or even that the image be created to match a certain size.

For example is there a reason why an image which a user knows will always be installed onto a 3GB disk couldn't be created to fill that entire 3GB?

I'm purposefully trying to start a discussion here, I don't know the answer...
Comment 1 Saul Wold 2011-04-14 16:15:56 UTC 
Is setting an IMAGE_ROOTFS_SIZE or ROOTFS_SIZE override not sufficient (I have not experimented with this yet).  It seems like you should be able to change the ROOTFS_SIZE to a ?= instead of = and that will all you to override the computation.

If we are having a discussion here, then the another way might be to change the meaning of IMAGE_ROOTFS_SIZE to maximum size and not minimum when the actual size is greater than the IMAGE_ROOTFS_SIZE.
Comment 2 Joshua Lock - Disabled 2011-04-14 19:53:32 UTC 
(In reply to comment #1)
> Is setting an IMAGE_ROOTFS_SIZE or ROOTFS_SIZE override not sufficient (I have
> not experimented with this yet).  It seems like you should be able to change
> the ROOTFS_SIZE to a ?= instead of = and that will all you to override the
> computation.

The problem here is that I do not know how large the rootfs is going to be before creating the image.

> If we are having a discussion here, then the another way might be to change the
> meaning of IMAGE_ROOTFS_SIZE to maximum size and not minimum when the actual
> size is greater than the IMAGE_ROOTFS_SIZE.

I'm not convinced about this. Changing behaviour based on a factor the user can't easily determine seems like a bad idea.
Comment 3 Saul Wold 2011-04-15 10:59:21 UTC 
Ok then, maybe back to adding a variable such as ROOTFS_EXTRA_SIZE or EXTRA_IMAGE_SIZE (or some concoction) that adds that amount of space to the ROOTFS_SIZE when it's computed via the du.
Comment 4 Joshua Lock - Disabled 2011-04-15 11:55:42 UTC 
Sounds good, that's the sort of thing I was thinking.
Comment 5 Saul Wold 2011-05-25 10:25:18 UTC 
The following commit adds IMAGE_ROOTFS_EXTRA_SPACE which is given in Kilobytes. There are also chances now in place that allow for the proper over ride of IMAGE_ROOTFS_SIZE to allow an arbitrary size, if that size is too small the IMAGE_OVERHEAD_FACTOR will kick in. 

http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=a3d6defd6365b6eae717bcf3568916306650db8a
Comment 6 Joshua Lock - Disabled 2011-07-25 08:21:40 UTC 
Verify fixed