On Mon, 2014-09-29 at 14:38 -0500, Dennis Gilmore wrote:
Hi All,
We have some bugs filed
https://bugzilla.redhat.com/show_bug.cgi?id=1142516 and
https://bugzilla.redhat.com/show_bug.cgi?id=1142512 to do with ARM
images being over size. They do not make any sense because the size of
the download is really not relevant to anything at all.
The media are a compressed disk image that you have to uncompress to
deploy onto a disk/sdcard/usb stick and boot a preinstalled system
from. The target media size is defined by the size of the partitions in
the kickstart. we (the arm team) have a maximum size of media of 8G
right now the actual sizes are as follows:
Mate and Workstation have partitioning that is 6G total 512M /boot,
512M swap and 5000M /
KDE has partitioning that is 5G Total 512M /boot, 512M swap, and 4000M /
LXDE and SoaS have partitioning that is 4G total 512M /boot, 512M swap
and 3000M /
Minimal has partitioning that is 2G total 512M /boot, 128M swap and
1400M /
The ARM disk image that roughly matches a live image iso for a spin
that fits on a 1G usb stick, will never fit on a 1G stick as
it has to be uncompressed to be usable and it will need 4G or bigger
media.
We should do a much better job of getting the message out there on
what size media you need.
OK, I kinda see what you're saying now - the way the images work, the
size of the compressed image we ship is more or less irrelevant.
I believe in the case where the bits in the image are too large for the
filesystems, compose fails, right? So there is basically no purpose to
running size checks on those images. Sorry I didn't quite grok that
earlier (in the bug report).
If that's the case, we can write a note into the size check test case
(and the criteria, if it looks necessary) that size checks are not
necessary for the disk image media.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net