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/ _______________________________________________ SoaS mailing list [email protected] http://lists.sugarlabs.org/listinfo/soas
