886 2011-03-16 08:30:01 +0000 Consider allowing images to request a set amount of free space be available in the generated image 2011-07-25 08:21:40 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto configuration unspecified x86 Multiple VERIFIED FIXED Low enhancement 1.1 1 josh sgw bluelightning poky.bs.watcher poky.watcher --- --- --- oldest_to_newest 12699 0 josh 2011-03-16 08:30:01 +0000 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... 13283 1 sgw 2011-04-14 16:15:56 +0000 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. 13291 2 josh 2011-04-14 19:53:32 +0000 (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. 13301 3 sgw 2011-04-15 10:59:21 +0000 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. 13303 4 josh 2011-04-15 11:55:42 +0000 Sounds good, that's the sort of thing I was thinking. 13978 5 sgw 2011-05-25 10:25:18 +0000 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 14975 6 josh 2011-07-25 08:21:40 +0000 Verify fixed