This will take a while to download the two isos and then at least another 3 minutes for the processing.
If that seems too hard for you, you can just download the finished iso and try it with qemu-kvm -m 1000 -cdrom xxx.iso

Do not let the debian logo in the bootloader confuse you. Just press enter there.
When running in KVM from RAM, this boots up in 18 seconds, while the original iso took 33 (measured from pressing enter in bootloader to the time the CPU load goes down). However, with physical media the difference will be less pronounced. Some of the difference comes from the faster gzip decompression. Unfortunately debian’s kernel does not support squashfs-xz, so I could not try that.

I hope in the future, we will have aufs patches in our normal openSUSE kernels and add an aufs-live mode to kiwi. That would help with the problems we hit with clicfs when memory runs out (and it can not be freed by deleting files either).

But first some broader overview. To make a LiveCD, the biggest problem is that CDs are not writeable (and even modern Flash devices do not want to be written too much). Embedded devices using flash had the same problem. Various approaches have been used in the past to solve this:

• adapt all software to write into ram-disks e.g. by having symlinks (hard to create and maintain)
• load all software into RAM (only for small distributions)
• use file-based overlaying such as unionfs or aufs to have software write into RAM (lsof, pwd, and hardlinks can be tricky)
• use block-based overlaying (problem: can not easily free disk space again)

Also compression is used to fit more onto a CD. And interestingly, this usually also speeds up booting because it is faster to read 10MB off a CD and decompress it into the original 30MB than to read 30MB from such a slow medium.

Now, to the distributions.

• openSUSE has the classic DVD installs that use special installation-images and run in RAM and then there are the real LiveCDs that are created by our kiwi tool, use block-based overlaying and LZMA compression of a ext3 by means of our FUSE-based clicfs.
• All of the other distributions use squashfs for compression. Mageia employs dracut for initrd and unionfs for file-based overlaying
• Debian uses aufs for file-based overlaying
• Ubuntu uses overlayfs for file-based overlaying
• Fedora uses an ext4 filesystem image contained in a squashfs with dm-snapshot for block-based overlaying, thus being most similar to openSUSE

I also spent some time benchmarking (on my AMD A10-5800K) the various technologies with a simple script using Debians uncompressed rootfs of 495132 KiB as data.
squashfs supports three different compression methods: lzo, gzip and xz (aka LZMA).

• squashfs-lzo: size:220992 compression:11.1MB/s decompression:134.4MB/s
• squashfs-gzip: size:203328 compression:15.5MB/s decompression:88.9MB/s
• squashfs-xz: size:176064 compression:6.5MB/s decompression:22.5MB/s
• cloop(gzip): size:213348 compression:16.2MB/s decompression:49.6MB/s
• clicfs(xz): size:185300 compression:16.7MB/s decompression:18.2MB/s

This has some surprises: even when using the same compression method, sizes can differ by 5% and speed can differ even more.

If you want to compare numbers on your system, memory throughput is also interesting:
# dd if=/dev/zero of=/dev/null bs=1M count=100000
104857600000 bytes (105 GB) copied, 12.4499 s, 8.4 GB/s

Overall, clicfs is performing OK, considering that it already takes care of the overlaying, but for my own LiveCD I would prefer Debian’s method and I am wondering how it would work.

Ok, that was a bit exagerated.

But the truth is that I am enjoying the new SUSE Studio suite. And that’s because it is facilitating my job as an educator. I work with the Nicaraguan Amateur Astronomers Society (ANASA) in teaching basic astronomy to the public. Obviously, my workhorse is an openSUSE laptop, loaded with Stellarium, Celestia, KStars and Xephem (and many other tools for my personal job as an astronomer).

For a long time, I’ve been advocating the use of openSUSE as the reliable, user-friendly and safe Linux distribution that it is, but I face a big barrier: the big majority of people attending our astronomy lessons does not have the needed technical skill and knowledge to install a new operative system, specially one like Linux.

So, I’ve decided to build a Live CD using SUSE Studio, focused entirely in provide the same basic tools for learning the sky and their basic steps in Amateur Astronomy.

The name of the Project: AstroGarrobo

Garrobo is the Nicaraguan name for a male Iguana. The Nicaraguan Linux community have nicknamed our openSUSE mascot as Garrobo instead of the familiar Chameleon, because a Chameleon is a rare species here in my Nation.

So far, there is a Beta version available for download at SourceForge. I have received many valuable reports from Beta Testers from different parts o the world.

My goal here is to obtain a stable LiveCD, for free distribution, that may help others to obtain the tools needed to inspire, feed and motivate their love for Space.

I’ve written a more detailed explanation of this project in my Blog (in Spanish). I would appreciate any comments, insights and recommendations about AstroGarrobo.

Clear skies!

• clicfs: 637MB ISO Image booting in 1:28 min (0:24 min from RAM)
• squashfs-rw: 751M ISO Image booting in 1:50 min (0:28 min from RAM)

The difference in the sizes of the ISO images are due to the fact that clicfs is using LZMA compression while SquashFS is still using the in-kernel GZIP implementation. Surprisingly the clicfs image isn’t only smaller but is also faster booting on real media and from RAM (using KVM). So even if we ignore the fact that clicfs is optimized for limiting the number of seeks on disk the SquashFS implementation is still slower. It would be interesting to see if it is just the LZMA compression that is making the difference or something completely different.

The patches for the SquashFS fake write support are here: http://git.infradead.org/users/jblunck/linux-2.6.git?a=shortlog;h=refs/heads/squashfs-rw-v1.