livecd-iso-to-disk reworked for self-replication of user customized LiveOS images was: Re: [SoaS] Call for Testing: Duplicating SoaS via CMD

[Frederick Grose]

On Tue, Apr 6, 2010 at 1:38 PM, Frederick Grose <fgrose(a)gmail.com&gt; wrote:

>  On Mon, Mar 29, 2010 at 4:16 PM, Peter Robinson
> <pbrobinson(a)gmail.com&gt;wrote:
>
> >
> > {...}
>
>  * 
*
*
*
*This post reopens the discussion of end user customization of LiveOS spins,
like **Sugar on a Stick.*
*
*
Ticket: https://bugzilla.redhat.com/show_bug.cgi?id=448030

(There is earlier discussion at
http://lists.sugarlabs.org/archive/soas/2010-April/000998.html.)

I've attached several patches to the bugzilla ticket, which breakdown the
changes for somewhat easier review:

1. One each, for the new --copy-overlay and --copy-home options and
   update to livecd-iso-to-disk.pod for help on usage.
2. Another pair for the --builder-message <message> and
   --releasefile <filepath> options with .pod changes for help.
3. And finally a pair that addresses the new to have usage help within
   the livecd-iso-to-disk shell script.

The --copy-overlay and --copy-home additions extend the utility of the
script to allow the user/learner to replicate their personally modified
image.

The --builder-message and --releasefile options label the remixed image to
prevent confusion with the pristine versions, and to credit the builder for
their changes.

Because the livecd-iso-to-disk script is so often redistributed in
standalone fashion, it is worth the space and effort to include usage
documentation and help in the script itself.  This should help the general
understanding of the script and its methods, given its presently-limited
documentation.

In the 1st and 3rd patches, there are many white-space changes that I
couldn't avoid in order to clarify the local variable name changes made to
match the broader scope of the script (for example, $ISO to $SRC and $USBDEV
to $TGTDEV). In addition, there are some block order changes that make use
and documentation easier to follow.

I also standardized the Bash conditional expression and list pipeline style
to the more modern, [[ Expression ]] && [[ Expression ]] format. (See
http://wiki.bash-hackers.org/syntax/ccmd/conditional_expression.)
This means that variables within the special double brackets need not be
quoted and the old test-type operators -a -o should not be used.

I'm sorry that all the changes may make review more critical, but it was
practically necessary.

  Thank you for taking the time to review these proposed changes.


This is not the complete solution for end-user/learner customization of
Sugar on a Stick.  Some of the missing pieces might be listed:

1. Graphical interface support
   (See http://wiki.sugarlabs.org/go/Activities/Toaster for a project
   that may provide this.)
2. An option to install a traditional filesystem on devices with
   sufficient storage capacity.
3. Overlay space consumption monitoring. (Sugar Cellar, in
   http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Sugar_Clone, provides
   a basic, command-line report.)
3. An option to write LiveOS .iso files for quick and inexpensive
   mass distribution.
4. Support for Macintosh compatible booting and replication.

The 'More robust iso', http://wiki.sugarlabs.org/go/More_robust_iso, feature
proposal can be aided by some of the installation options available in
livecd-iso-to-disk.  In particular, using the --home-size-mb <size> option
creates a non-compressed (but loop mounted) filesystem for the home
directory.

SoaS deployments in schools may want to configure images without any
operating system overlay (providing consistency and stability) and use the
extra, persistent storage space for recoverable home directory storage that
can be easily backed up, shared, or swapped (by remounting the /home
folder).  This would allow convenient and rapid sharing of limited
workstations in a classroom, library, or clubhouse all without the need to
reboot the workstation.

We can work to add a Sugar Frame or Journal feature to restart X with a new,
Sugar-usable Journal within attached filesystems.  I expect there will be
some confusion as plug-in or wireless Journals allow Learners to appropriate
more computing devices in a way previously not possible.

      --Fred