size issue
Robert Schweikert
I think we have a size issue. I am fiddling around with building a
"complete" image, i.e. and image that contains all the packages I want.
This leads to an unpacked image tree of about 6.8 GB. When I use the
<size> of my image to be 10 GB the disk image creation fails with
basically and "out of space" message. I know that we apply a "safety"
factor to the disc image to allow additional data to be installed once
the system is up and running.
This "safety" free space is now crimping my style :( as it it making the
image much bigger than I want it to be. And I don't want or need the
"safety" free space.
I think we have logic error in the code somewhere, but have not
confirmed this yet. Based on my observation I think this is what's
happening.
We figure out how much space is actually needed by the image. We compare
this to the requested size (specified with <size>) and if it fits we go
on our merry way. We then use the specified size do create the partition
in the loop device that is later used to receive the image. However,
when we create the image we use required size + safety factor size. We
check how size + safety factor size compares to the requested size and
complain if there's not enough space. However, we go on and then
eventually dd fails when we try to dump the image (which was created too
large) onto the partition of the loop device.
I think if the size is requested and we confirm that the required image
fits within the requested size we should not apply the safety factor.
Then everything should work.
Thoughts?
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjsc...@suse.com
rsch...@ca.ibm.com
781-464-8147
Robert Schweikert
> Hi,
>
> I think we have a size issue. I am fiddling around with building a
> "complete" image, i.e. and image that contains all the packages I want.
> This leads to an unpacked image tree of about 6.8 GB. When I use the
> <size> of my image to be 10 GB the disk image creation fails with
> basically and "out of space" message. I know that we apply a "safety"
> factor to the disc image to allow additional data to be installed once
> the system is up and running.
>
> This "safety" free space is now crimping my style :( as it it making the
> image much bigger than I want it to be. And I don't want or need the
> "safety" free space.
>
> I think we have logic error in the code somewhere, but have not
> confirmed this yet.
Well here is some more information. I followed the steps KIWI executes
manually and, lo and behold reproduced the same error ;)
The config file contains <size>10240</size>, for my test I just have the
basic packages, thus this will definitely fit, the unpacked image tree is
# du -sh /work/tmp/mbStick32_unpacked
569M /work/tmp/mbStick32_unpacked
KIWI proceeds to create a raw disk with qemu of 10390M, then partition
such that the primary partition is around 10GB
# parted -m /dev/mapper/loop0p2 unit GB printError: /dev/mapper/loop0p2:
unrecognised disk label
BYT;
/dev/mapper/loop0p2:10.7GB:dm:512:512:unknown:Linux device-mapper (linear);
The image file that was created is:
-> ls -lh /work/tmp/mbStick32_img/suse-12.1-disk-image.i686-0.0.1
-rw-r--r-- 1 root root 10G Jan 14 07:38
/work/tmp/mbStick32_img/suse-12.1-disk-image.i686-0.0.1
Thus on the surface things should work, i.e. one should be able to dump
the image onto the partition, but it fails:
# dd if=/work/tmp/mbStick32_img/suse-12.1-disk-image.i686-0.0.1
of=/dev/mapper/loop0p2 bs=32k
dd: writing `/dev/mapper/loop0p2': No space left on device
327649+0 records in
327648+0 records out
10736369664 bytes (11 GB) copied, 82.8432 s, 130 MB/s
Taking a look at everything in bytes
partition size: 10736369664
image size: 10737418240
shows that yes, the dump must fail as the image in bytes is indeed
larger than the partition size :(
It appears that the calculation of sizes for the partitioning and the
image size, i.e. where we create
/work/tmp/mbStick32_img/suse-12.1-disk-image.i686-0.0.1, in inconsistent.
I'll try and find some time to poke at this some more.
Later,
Robert Schweikert
Found it => pull request #41
There is an "off by 1 error", where 1 is either 8K or 1M depending on
the size of image being built.
The error is only trigger, if I pieced everything together properly when
an XFS or Btrfs image is be built. Images with these file systems
require a boot partition.
Marcus Schäfer
> Found it => pull request #41
>
> There is an "off by 1 error", where 1 is either 8K or 1M depending
> on the size of image being built.
yes you are right getBlocks behaves wrong.
Thanks much for this one
Regards,
Marcus
--
Public Key available
gpg --keyserver gpg-keyserver.de --recv-keys 0xCCE3C6A2
-------------------------------------------------------
Marcus Schäfer (Res. & Dev.) SUSE LINUX Products GmbH
Tel: 0911-740 53 0 Maxfeldstrasse 5
FAX: 0911-740 53 479 D-90409 Nürnberg
GF: Jeff Hawn,Jennifer Guild, Felix Imendörffer
HRB: 21284 (AG Nürnberg) Germany
http://www.suse.de
-------------------------------------------------------