----- Original Message ----- > On 25/04/2012 20:21, Tim Nelson wrote: > > ----- Original Message ----- > >> One thing that I would like to ask the people on this list is > >> regarding > >> the installers. Are you happy with the minimal rootfs tarball and > >> taking > >> it from there with yum? Or are you just lurking on this list until > >> an > >> installer of some sort becomes available? What hardware are you > >> running > >> RedSleeve Linux on and how are you finding it? I can see there are > >> quite > >> a few people on this list but nobody has posted any reports of bugs > >> or > >> other issues and I'm not sure whether that is a good thing (no bugs > >> found) or a bad thing (nobody is using it). > >> > > > > Unfortunately, I've not tried RedSleeve yet as I'm awaiting arrival > > of > > my RaspberryPi (like many others). I'm perfectly comfortable with a > > rootfs/kernel, but I could see less experienced folks wanting > > something > > more 'point and click' type distro, much like the RaspberryPi > > official > > downloads (2GB SD images). > > Thanks for responding, Tim. I have been thinking about putting > together > something based on this: > http://fedoraproject.org/wiki/Fedora_ARM_Installer > > There are several problems with using images, however: > > 1) Download is large even with a carefully prepared image - even if > you > create a virtual image by dd-ing zeroes or formating the media with > discard-supporting version of e2fsprogs, untar the rootfs and image > it, > the download is still going to be considerably bigger than the tar > ball. >
Agreed. This isn't more efficient than the current rootfs tarball, but does make it easier for some users. > 2) Image isn't necessarily the same size as the card. SD cards of any > given advertised size differ in actual size by +/-5% or more, which > means the 2GB image may not fit on a 2GB card. > Most projects get around this by purposely making the image up to 10% smaller than the target device, providing for 'cushion', and allowing some of the flash cells to remain unmolested. > 3) Writing an image means hammering the SD card for the full size of > the > image, whereas the tar ball is much kinder on those limited erase > cycles. > Yep, see above. > > Anaconda has recently been made to work on ARM, so that may be an > option > in the near future, but the problem there is booting - having to > create > a SD card image of the installer in order to install onto the device > (usually onto the same SD card the installer is booting from in a lot > of > cases) seems like a really bizzare self-defeating way to do things. Agreed. > Having said that, it might work reasonably well on devices that can > boot > off the network, using DHCP and TFTP (Sheeva/Guru/DreamPlug and > probably > many other devices). It might also be reasonable in cases like the Most ARM devices can boot via TFTP/NFS, at least the ones I've used with uBoot or Redboot. > DreamPlug where there is an internal uSD slot. You could ship the > device > with a bootable installer image on the internal card that starts on > the > first boot (or when you want to do a "factory reset") and installs > onto > external SD card, USB or SATA disk. This seems overly complicated, and prone to problems. > > The downside of the Anaconda approach (installing all the RPM packages > individually) is that there would be a HUGE churn on the flash media > from updating the RPM database during the installation. Installing > onto > a USB or SATA disk would be fine, but installing to an average SD card > would take hours. Here is the benchmark I did on a wide array of flash > media, and the random-write performance on most SD/CF cards and USB > sticks (with one spectacular notable exception) is truly dire: > > http://www.altechnative.net/2012/01/25/flash-module-benchmark-collection-sd-cards-cf-cards-usb-sticks/ > VERY interesting! This is the kind of data I've been looking for recently to compare various flash devices based upon a real testing scenario, not just what the vendor claims on the spec sheet. :) Thanks! --Tim
