[SoaS] [Sugar-devel] SOAS 2 problems

[Bernie Innocenti]

Cc'ing Warren Togami, who has been filling-in as a temporary maintainer
for livecd-iso-to-disk. The rest of the thread, to fill him in, is here:

 http://lists.sugarlabs.org/archive/soas/2010-January/thread.html#683


On Tue, 2010-01-26 at 14:00 +0000, Peter Robinson wrote:

> I think your trivialising your solution way too much, and the issues
> in general. If your proposal is so easy and so risk free don't you
> think that most of the Live Media projects would have gone this route.

Good question. My guess is that all those live distros were initially
designed for read-only media and was incrementally evolved to work also
with USB/SD flash drives. If you google for "live usb distro" you get
this kind of stuff.

On the other hand, most Linux distros also support traditional
installation to hard drives which works with flash drives. These don't
show up if you search for "live usb distro" because they don't contain
any special-casing for USB flash drives.


>  Also who is going to do all the QA and testing on this on dozens of
> various sticks and various other media to see what the issues are with
> different formats, USB keys, memory cards and what ever other media or
> formats that are used.

You seem to be assuming that a standard filesystem layout with a
standard bootloader would be less compatible with existing hardware than
a perverse succession of filesystems nested within each other.

I would rather reverse the question upon you: who will do all the QA and
testing work to ensure that the current layout actually works?

So far, nobody had even tested this russian-doll thing hard enough to
discover a severe data loss issue which shows systematically on any
brand and make of flash drives! There may be several other, less
obvious, data corruption issues. For example: device mapper did not
support I/O barriers until very recently (2.6.32? or 2.6.33?), and I
seriously doubt that the copy-on-write snapshot can ever support the
data ordering semantics required by ext3/ext4... especially when this
snapshot lives on a separate file stored on top of a fat filesystem.

How long has livecd-tools been around? Either we are the first users
attempting to use the permanent storage feature for something more than
a quick demo, or the maintainers are all dead.


> The advantages of the current way we do things are as follows:
> - Works, tried and tested in Fedora across a lot of releases, 4
> platforms, and 1000s of media types

...with just this one tiny unsolvable issue of becoming unmountable
after some use :-)


> - Can be installed to a proper install as your proposing using
> liveinst (this just needs to be documented as a procedure).

This is also true of the original Live ISO image and, I suspect, of the
direct to disk filesystem image.

But I'm not proposing to stop distributing the ISO image.


> - Can be used on CDs as well if desired (your solution won't work
> here)

Right, but do we really want to push Sugar on a CD-ROM? Is this a
use-case we even care about, given that all laser media is going extinct
at the speed of light?

But anyway, I'm not proposing to drop the ISO image, if someone likes
it.


> - Can be easily booted on all Virtualisation solutions
> (KVM/Zen/VMWare/Virtualbox/Fusion/Hyper-V etc) with no changes as they
> all support booting off a CD iso image (your proposal would need the
> VM drivers for at least storage to work properly for all of them)

They also all support booting off a hard drive image, right? Which is
what we'd do.

> - The QA that happens as part of all the upstream Fedora releases for
> Live Media.

...which is rather unimpressive, given the hole we could find in 20
minutes of normal operation.


> The disadvantages of your proposal (as I see it) are:
> - Some one needs to do the coding to produce the images

I've alread produced an image, and described how to do it. Others
pointed out that there's already a rule in the Makefile.

> - No upstream QA
> - Doesn't work in all environments that we currently support so we'd
> need to have Yet Another Image
> - No wide spread testing
> - Lots of corner cases that would need to be documented or developed
> around

All the above items seem to disregard that what I've proposed is the
most common filesystem layout used by upstream on all sort of writable
block media.

No more, no less... The very same stuff you have on your hard drive.
Perhaps I'm not good at making this point very clear, because people
keep asking me to do QA/testing and even write new code :-)


> I personally believe that the best way to get both capabilities would
> be to continue to ship the Live Media as we do now and document how to
> use liveinst to have a 'proper install' onto a USB key that is
> bootable. This is supported upstream and is hence very well tested and
> is known to work well.

I personally think you're largely overestimating upstream's dedication
and commitment in supporting the live USB corner case which, I'd like to
stress one more time, currently sits unmaintained.


>  It shouldn't be too hard to even add an Activity icon or Control
> Panel icon to start the liveinst off (does Sugar support something the
> equivalent of a .desktop file) like Fedora puts a "Install to your
> harddisk" icon on their Live Media desktops.

This would be indeed a great feature to have, regardless of how we solve
the present data corruption problem.

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