[SoaS] [Sugar-devel] SOAS 2 problems

[Bernie Innocenti]

On Wed, 2010-01-27 at 07:48 -0500, Xander Pirdy wrote:


> Correct me if I am wrong, this tutorial seems to be a bit ambiguous on
> the point, but would you loose persistence if you simply dd the iso?
> If not  where is the 
> storage for this located, or is it just a full-type of installation?


Yep, there would be no permanent storage. My original idea was to boot
this image only for the purpose of producing other USB sticks with a
live installer.

However, the method used by OpenSuSE-edu which Thomas described also
sounds like a nice alternative: it could be automated by an initscript.

Instead of making users run dd directly, Sebastian proposed this wrapper
script used by Intel for Moblin:

  http://mirrors.paraguayeduca.org/soas/releases/image-writer

It reduced the potential for shooting yourself in the foot by choosing
the wrong /dev file.

> 
> I may just not be understanding you correctly, in which case my
> apologies. I do 
> think that a full installation has more drawbacks than it seems
> initially. For 
> example wouldn't it be very easy to upgrade the current overlay
> method, by just 
> replacing the iso? This could also make it very easy for teachers to
> customize the
> activities of the students.
> 
No, it wouldn't work, because the overlay file contains a bunch of
blocks that were changed relative to the read-only ext3 image contained
in the iso. The technique is called copy-on-write.

Replacing the iso file and keeping the changes would work if the overlay
were a nice high-level thing which stores entire files. Such a thing
would actually be possible, and is called a "union mount" or "union
filesystem":

 http://en.wikipedia.org/wiki/Union_mount

Of all the possibilities examined in this thread, this would be by far
the most flexible and robust.

Unfortunately, is not yet viable for us because none of the existing
unionfs implementations for Linux made it into the official kernel yet.

It turns out that the semantic details of union filesystems are very
hard to get right, and all existing implementations seem to have
outstanding design issues:

 http://lwn.net/Articles/324291/
 http://lwn.net/Articles/325369/
 http://lwn.net/Articles/327738/

This did not stop certain live distros from going on and patching the
kernel to add the required functionality. This is just not going to
happen anytime soon in Fedora, because of its (admirable) policy of not
diverging excessively from upstream.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/