[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

Douglas McClendon dmc.sugar at filteredperception.org
Thu Sep 10 06:03:32 EDT 2009


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
>>
>>



More information about the Sugar-devel mailing list