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...
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.
(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.
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.
Sounds good, that's the sort of thing I was thinking.
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
Verify fixed