<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Bernie Innocenti wrote:
<blockquote cite="mid:1264600766.15430.349.camel@giskard" type="cite">
  <pre wrap="">On Wed, 2010-01-27 at 07:48 -0500, Xander Pirdy wrote:


  </pre>
  <blockquote type="cite">
    <pre wrap="">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?
    </pre>
  </blockquote>
  <pre wrap=""><!---->

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.
  </pre>
</blockquote>
FYI here is cyberorg's script to do this:<br>
<br>
createsecondpartition.sh <br>
---------------------------------------------------------------<br>
#!/bin/bash<br>
if [ x"$1" = x"" ]; then<br>
&nbsp;&nbsp;&nbsp; echo "run the script with /dev/sdX as arguement"<br>
&nbsp;&nbsp;&nbsp; exit<br>
fi<br>
fdisk $1 &lt;&lt; EOF<br>
n<br>
p<br>
2<br>
<br>
<br>
w<br>
EOF<br>
SECONDPART=$12<br>
dd if=/dev/zero of=$SECONDPART bs=4K count=2<br>
----------------------------------------------------------------<br>
<br>
<blockquote cite="mid:1264600766.15430.349.camel@giskard" type="cite">
  <pre wrap="">
Instead of making users run dd directly, Sebastian proposed this wrapper
script used by Intel for Moblin:

  <a class="moz-txt-link-freetext" href="http://mirrors.paraguayeduca.org/soas/releases/image-writer">http://mirrors.paraguayeduca.org/soas/releases/image-writer</a>

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

  </pre>
  <blockquote type="cite">
    <pre wrap="">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.

    </pre>
  </blockquote>
  <pre wrap=""><!---->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":

 <a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Union_mount">http://en.wikipedia.org/wiki/Union_mount</a>

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:

 <a class="moz-txt-link-freetext" href="http://lwn.net/Articles/324291/">http://lwn.net/Articles/324291/</a>
 <a class="moz-txt-link-freetext" href="http://lwn.net/Articles/325369/">http://lwn.net/Articles/325369/</a>
 <a class="moz-txt-link-freetext" href="http://lwn.net/Articles/327738/">http://lwn.net/Articles/327738/</a>

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.

  </pre>
</blockquote>
</body>
</html>