Introduction to a new SIG for creation of Live DVD

[John Reiser]

On 09/15/2009 10:29 AM, Andre Robatino wrote:
> I'm using the latest F11 version of squashfs-tools on a fully updated
> x86_64 F11 box.  Just discovered that it works on
> Fedora-11-i686-Live.iso, but fails with F10-i686-Live.iso.  So the new
> question is, why doesn't it work with the F10 image?

That's a bug, please file in bugzilla, with *specific* version info.
Include the checksum of each *.iso, just to be sure.

> Also, after expanding squashfs.img for F11, it gives me another single
> huge (over 3 GB) file ext3fs.img.

ext3fs.img is a complete, mountable filesystem.
     mount  -o  loop  ext3fs.img  /mnt/foo
All the files are there with their actual names, actual contents, etc.
So rsync will work on the tree /mnt/foo just as well as rsync works
on any actual file system tree.

The downside is each rsync session requires processor cycles on both ends.
The drawing card of the new zsync tool is that the rsync CPU time on the
"master" side need be done only once; the results are cached as a companion
file to each existing file.  The companion file contains the checksums
for chunks of the [new] file.  The master side http server just serves the
companion file like any other file.  The zsync tool retrieves the whole
companion file, does the rsync checksum computations for the local old file,
then asks the master for the appropriate partial content (HTTP code 206)
of the chunks that the local side does not have already.  The gain is
that the companion file is smaller.  The risk is that anybody who can
manufacture collisions for the checksum can pollute the result.

--