Hi Gordan, The extra size of the CLI file came from 'yum-ing around' and not removing all the extra packages. I have now gone through them and saved quite a bit of space.
There is extra stuff over the original - most notably the rpi-update utility, which we need as we are not using a RedSleeve kernel and its getting updated pretty quickly on the Raspberry Pi at present. I ensured there is no overhead in the compressed file by mounting up the image and filling all free space from /dev/zero/ then delete before compressing. Something like: #dd if=/dev/zero of=/mnt/zero.bin bs=1M count=730; rm /mnt/zero.bin The new logo on the wiki looks lovely :) Finally I have upgraded the files to include the latest Raspberry Pi kernel/firmware as its been updated to improve quite a few things, and I've fixed an error where the image sizes were slightly too big for 2Gb cards. So updated links for version 0.3 are listed on the usual place http://opensource.wrenhill.com/?p=123 John On 09/06/12 19:10, Gordan Bobic wrote: > On 09/06/2012 17:48, John Cooper wrote: >> Hi Gordan, >> >> I'll go through my yum listings and see if I can spot where the extra >> space has gone :) > > I have a suspicion where it's coming from. Did you tar up the rootfs > contents, re-make a sparse image container from scratch, mkfs it, mount and > untar the rootfs tar ball from > earlier? > > If you just yum-ed around the previous rootfs there will be a lot of dirty > blocks in the image which will affect the compression. > >> I've updated the block size as you recommended and I've aligned the name >> of my files with yours, and fixed a small typo on the wiki page. > > Incidentally, when you mkfs, assuming a 4MB erase block size (it's a guess, > but seems the most common case given Linaro's SD card research: > https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey), you > might want to mkfs the rootfs with the following: > > mkfs.ext4 -O ^has_journal -E stripe-width=1024 > > Journal increases random writes because the metadata gets written twice, > hence why I normally disable it on flash media, since fsck is just lots of > reads (unless something needs > fixing) and random reads are extremely fast even on the worst of SD cards. > > Anyway, you might find Linaro list above useful when it comes to finding good > SD cards to use. Take it all with a bucket of salt, though, until you do your > own SD card benchmarks. > > Preferably using the same methods I used in my benchmarks here: > <http://www.altechnative.net/2012/01/25/flash-module-benchmark-collection-sd-cards-cf-cards-usb-sticks/> > > and email me the results so I can add them to the list. :) > >> Also, could you set the logo on the wiki page to make it look a bit >> nicer :) > > I've just changed it. Better? :) > >> I guess you have decent artwork, but in case its a hassle, here is one >> the right size (155x155) cropped from the website, if you want to add it. > > Check the contents of the red-hat-logos package in the distro. :) > All the artwork Giles created is in there. > > Gordan > _______________________________________________ > users mailing list > users at lists.redsleeve.org > http://lists.redsleeve.org/mailman/listinfo/users >
