[SoaS] [Sugar-devel] SOAS 2 problems /createsecondpartition.sh

[Thomas C Gilliard]

Bernie Innocenti wrote:
> 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.
>   
FYI here is cyberorg's script to do this:

createsecondpartition.sh
---------------------------------------------------------------
#!/bin/bash
if [ x"$1" = x"" ]; then
    echo "run the script with /dev/sdX as arguement"
    exit
fi
fdisk $1 << EOF
n
p
2


w
EOF
SECONDPART=$12
dd if=/dev/zero of=$SECONDPART bs=4K count=2
----------------------------------------------------------------

> 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.
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/soas/attachments/20100127/25887f96/attachment.htm