[Sugar-devel] Hello, was Re: Hack to get a USB/SD to autologin to only "Sugar-desktop on a stick". from a F12-alpha live CD

[David Farning]

Thanks for taking the time to respond.

I started running the tests last week to see if we could generate some
data from which we could make some predictions on the reliability of
various lots (model, size, firmwre....) of USB memory sticks.  The
original idea was that name brand sticks might last longer then 'the
cheapest we could find' stick I have been working with.

I was thinking that different lot/filesytem combinations would
gracefully degrade at consistent predictable rates.  Instead, I got a
rather unexpected result.  Rapid failure of a lot/filesystem
combination.

Now I am just scrambling for an explanation..... Before anyone goes
out and buys a couple hundred sticks for a deployment, pilot, or pr
event.

With the feedback you, Tom, and Martin have provided, I'll try to
refine the tests to get better data.

david



On Thu, Sep 10, 2009 at 5:03 AM, Douglas McClendon
<dmc.sugar at filteredperception.org> wrote:
> David Farning wrote:
>>
>> Thanks for joining us Douglas.
>>
>> I would like to point out that there are two separate yet interlinked
>> issues at hand:
>> 1. Easy and fast install.
>> 2. Running OS natively on removable solid state media.
>
> understood.
>
>>
>> Douglas' Liveos solved the first issue.  It is very fast and easy to
>> install an OS to a hard drive by dd'ing the contents of the overlay to
>> the hard drive.
>
> To be clear, zyx-liveinstaller dds the contents of the combination of the
> overlay and the base.  Alternately if you wanted to use the traditional
> anaconda-liveinst installer, that would copy just the base.  (unless you
> tried it with a combination of the base and a shapshotted(frozen) version of
> the overlay.  Something I told Sebastion I could try out, but am lazily
> biased to let zyx-liveinstaller work as long as people find it to be
> sufficiently qualified to the task).
>
>> I am suggesting that ease of installation to another medium is not
>> longer the primary usecase for SoaS.
>
> Agreed.
>
>>
>> The primary use case is now running Sugar and the underlying OS as
>> natively as possible on the removable solid state media.  The primary
>> goals are now reliability and speed.
>>
>> The issue is not that overlays are bad/good or real file systems.  The
>> issue is, can SoaS improve stick reliable  and speed by eliminating
>> the overlays and writing the _contents_ of the overlay directly onto
>> the solid state device using a file systems which is aware of the
>> design characteristics of current generations of USB keys.
>
> One would certainly expect this to be the case at some point if not already,
> and it looks like you are deep into the task of figuring out exactly when
> that point is and what it looks like.
>
>>
>> I have been conducting some very initial tests using WAD's SD card test
>> tools.
>> #1. Standard SOAS.
>> #2. Install the contents of the SoaS overlay to a usb key using ext2.
>
> I don't actually use LiveUSB overlays in all variation.  In this case is the
> base(squashed ext3/4 base) also on the ext2, or is the ext2 a seperate
> partition for just the overlay?  Not that it matters too much, but as above
> I just want to clarify things so I know we are on the same page.
>
>>
>> I am just running various methods of installing soas on USB sticks in
>> qemu directly from usb sticks using
>>
>> qemu  -hda /dev/sd*
>>
>> My initial runs using the cheapest drives I could find at best buy
>> indicate that #2 has at least 10X the lifetime as #1.
>
> Again, I'm a bit confused by your wording of #2.  I.e. 'the contents'.  Does
> that mean just the small overlay, or the overlay combined with the base?
> Because it also factors into your 1. and 2. at the top.  I.e. do you
> consider the result of #2 to fall into the category of 2."Running OS
> natively on removable solid state media."?
>
> I see (at least) 3 scenarios (and I don't follow OLPC that closely even
> though I own one and still intend to put it to good use ... 'one day')
>
> a) LiveOS(CD/USB/nand?) with nonpersistent ram overlay
> b) LiveOS with persistent overlay living on vfat with the squashed base
> c) LiveOS with persistent overlay living on ext alongside squashed base on
> vfat partition
> d) LiveOS with persistent overlay living on ext(2/3/4) with the squashed
> base
> e) installed (non-liveos) on ext2/3/4(/ubifs?/btrfs?) on a usb/flash/nand
> partition
>
> I take your 2.) to be e).  Your #1 to be b) (or do you guys do d) already?).
> And your #2 to be either c) d) or e), i.e. not sure.
>
> I'll also reply to your other email.
>
> In any event, if distributing soas _as_ e) results in the lack of need for
> zyx-liveinstaller to be part of it, maybe I'll have to reprioritize the
> already roadmapped feature for zyx-liveinstaller to be able to run from an
> already installed system to fork/clone a copy of the running 'StickOS' (as
> opposed to LiveOS) to another diskpartition/stick.  Nothing a majority of
> users would use, but perhaps amusing enough to justify inclusion.
>
> -dmc
>
>
>>
>> david
>>
>>
>> On Wed, Sep 9, 2009 at 10:27 AM, Martin Dengler<martin at martindengler.com>
>> wrote:
>>>
>>> On Wed, Sep 09, 2009 at 06:48:53AM -0600, Douglas McClendon wrote:
>>>>
>>>> Douglas McClendon wrote:
>>>>>
>>>>> Martin Langhoff wrote:
>>>>>>
>>>>>> On Wed, Sep 9, 2009 at 4:26 AM, Douglas
>>>>>> McClendon<dmc.sugar at filteredperception.org> wrote:
>>>>>>>
>>>>>>> My name is Douglas McClendon, and I created the ZyX-LiveInstaller
>>>>>>> which appears
>>>>>>>  on track to becoming part of SoaS.  I also can accept praise and
>>>>>>> blame for
>>>>>>> the LiveUSB persistence feature I implemented for fedora a couple
>>>>>>> years back,
>>>>>>
>>>>>> Good to have you on board! One thing we've found is that the overlay
>>>>>> fs trick is neat but somewhat fragile. In brief - unclean shutdowns
>>>>>> and "oops, I pulled out the stick" cases very often leave the USB
>>>>>> stick unbootable.
>>>>>>
>>>>>> Of course, first step is fsck.vfat, but after that, we're completely
>>>>>> lost. Hints would be more than welcome. Ideally, something smarter can
>>>>>> be done during the boot itself or otherwise with a "repair" script.
>>>>>
>>>>> Unfortunately I don't have any easy answers.  As someone who works on
>>>>> NDS
>>>>
>>>> Ok, more hints as various vague theories start percolating through
>>>> my memory.
>>>
>>> If people care to take advantage of your expertise, I hope they can
>>> provide the filesystems that have failed as examples.  "overlay is
>>> fragile" is about the level of FUD, AFAICS.  Nothing better has been
>>> proposed.  No broken filesystems have been made available.  I don't
>>> doubt the "some sticks 'broke' when yanked out before fs's were
>>> sync'ed" reports in and of themselves, but when this meme continues it
>>> makes potential contributors / onlookers think there is some obvious /
>>> neglected problem.
>>>
>>>> -dmc
>>>
>>> Martin
>>>
>>> _______________________________________________
>>> Sugar-devel mailing list
>>> Sugar-devel at lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>
>