[SoaS] [Sugar-devel] SOAS 2 problems
dmc.sugar at filteredperception.org
Sun Jan 24 16:41:46 EST 2010
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
> 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
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
More information about the SoaS