[SoaS] [Sugar-devel] SOAS 2 problems

[Douglas McClendon]

On 01/24/2010 02:07 PM, Bernie Innocenti wrote:
> On Sun, 2010-01-24 at 14:34 +1200, David Leeming wrote:
>> I am sorry that I am a little slow on the uptake.
>> Blueberry SOAS2 seems to work OK. I have used LiveUSBCreator
>> and it's installed on a flash drive. Is this what you are
>> recommending? We have done this on several PCs and notebooks
>> and it is fine, although I admit we haven't really pushed it.
>>
>> Are you saying that there is a risk that whilst in use,
>> there is a chance that they could render it inoperable?
>> If so, no worries as it can simply be re-flashed, we can
>> live with that.
>
> Have you tried writing to the journal until you fill up the overlay
> space?
>
> Unless I'm seriously misunderstanding how LVM snapshots work, this
> should systematically make the flash drive inoperable until reformatted,
> and all data inaccessible.
>
> This is not a random bug, it's the result of copy-on-write becoming
> read-only due to lack of spare blocks and the ext3 filesystem being
> unwilling to mount itself without first committing the journal. Each
> subsystem is doing the "right thing" individually, but the resulting
> interaction results in this very unfortunate behavior.

I would disagree that ext3 refusing to mount itself in read only mode 
without committing the journal is the 'right thing'.  I myself haven't 
run into this combination of events, but what you describe is plausible. 
  There are pretty easy ways to work around the 'unrecoverable' aspect. 
  I.e. easy to have a rescue mode where additional blocks can be made 
available to the overlay from ram.

...

>
> Hope I'm not being too technical :) The bottom line is: we shouldn't be
> doing this in SoaS, no matter what upstream is doing. Upstream is wrong
> in doing it.

...

That is quite a pronouncement, but you didn't bother to explain why 
things are the way they are as opposed to some alternate way that you 
didn't mention.

It is important to remember that the fedora _liveusb_ is the way it is, 
because it was an extension of the _livecd_.  Lots of reasons, many 
historically transient, contribute to the way things are, and you need 
to understand that history when discussing how to go forward.  For 
instance, the livecd was compressed, importantly fitting 1.5G of 
applications in .5G of filesystem.  A filesystem that had to be readonly.

Clearly moving the media from a 700MB read-only one, to a 1G slowly 
writable one, changed the game, opened new possibilites, and thus you 
have people enjoying the F7 liveusb on 1G stick experience.

To the point that SoaS grew from that useful experience.

Now, these days you have relatively cheap 8G sticks, that don't suffer 
nearly as badly from slow write performance.

Thus more possibilities are opened.

> My understanding is that Fedora would also like to get this problem
> fixed, but the live usb tools package is currently missing a full-time
> maintainer and, thus, the fix is not happening.

What 'fix' do you speak of?

Please note that this discussion came up on centos-devel.  It was noted 
that the only bulletproof way to use the overlay method without running 
into out-of-overlay problems, is for your overlay to be a little bit 
larger (say 105%) than the size of the uncompressed root filesystem. 
I.e. that may be 2G in SoaS-BB (haven't looked recently).

Another vast improvement that I posited to dm-devel, was to utilize the 
new discard request feature of the kernel to let devicemapper 
intelligently reuse overlay blocks that the filesystem no longer cares 
about.  No real reception to the idea to speak of.

>
> The fix for us is easier, because we don't really need any of the fancy
> things that livecd-iso-to-disk does. All we need to do is stop
> mentioning it in our wiki and switch to liveinst, as Peter Robinson
> suggests, or any other tool that does the (rather trivial) job of
> transferring an ext3 image onto a (flash) drive.

Due the the changing price/quality/size constraints of usb pluggable 
flash memory these days, it does make sense for liveusb-creator to have 
an alternate installation code path, that instead writes a normal 
installation, instead of a 'live' installation to the target stick.  If 
I had the time to spare, I'd love to write it, but sadly I don't.  I'm 
also quite willing to help guide anyone that wishes to do so, if in fact 
they need any help.  But of course, zyx-liveinstaller can already do 
this from a booted blueberry livecd burned from the .iso, or from the 
liveusb form that can also be created from the bb livecd booted.  And I 
honestly don't know how good an idea it is to focus on the 
installation/creation methods that depend on a proprietary OS.  I think 
it is much better to teach people an installation method that works, 
whether or not a proprietary OS is installed on their system.  (or a 
proprietary OS that may or may not already be loaded down with virii and 
malware)

-dmc