Tim Nelson wrote: > ----- 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.
Does it _really_ make it easier? dd if=/path/to/rootfs.img of=/dev/mmcblk0 bs=1M vs partition mkfs mount tar -C /path/to/mount/point -jxf /path/to/rootfs.tar.bz2 The point is somewhat moot. I would very much like to think that those that stray from the primary arches and the hand-holding of Ubuntu would know enough to do the above. Then again, I can sort of see that dd-ing a minimal image (sized accordingly) to a suitable partition might actually be easier in some cases, e.g. AC100 where you could nvflash the rootfs image straight to the internal MMC and resize it to fill the available space once it has booted. >> 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. Thinking about it, this is not hard to achieve - make the partition the minimum possible size, e.g. rootfs + 10MB. Then alter the partition size and resize2fs once the device has booted. But that is no less complex and certainly more dangerous than just using the tar ball. As for leaving some flash cells unmolested - that is a valid point on proper SSDs, but SD/CF/USB flash media doesn't have sufficiently clever wear leveling to benefit from this. >> 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. Indeed - but very few ARM devices have uboot. My Kirkwood based *Plug devices do, but my Tegra2 based devices don't (not to mention that the AC100 doesn't actually have a wired network port at all, which also goes for the Genesi Efika Smartbook, and a lot of other similar machines). >> 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. I mean in the sense of using it as purely a "factory reset" option. >> 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. :) Indeed, and as the results in the article show, the speed classes and spec sheet information is at best useless and misleading. If you absolutely have to have SD media, there are no good options, but there are one or two that are not utterly atrocious. But if you have the option of using SATA (even via a SATA-USB adapter) SSD, do so - it'll be both several times cheaper and several orders of magnitude faster. And the media will last a lot longer. Gordan
