[SoaS] [Sugar-devel] SOAS 2 problems

[Sebastian Dziallas]

Hi all,

sorry for jumping in here so late. Comments inline.

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?

On a reasonably big usb stick (with prices dropping all day long), this 
problem will probably not be solved, but rather appear less and less.

Note that I'm not saying that we don't need to investigate here.

> Unless I'm seriously misunderstanding how LVM snapshots work, this
> should systematically make the flash drive inoperable until reformatted,
> and all data inaccessible.

Walter, Dave and others have been doing tests concerning the reliability 
of our current layout in the post-Strawberry time, if I recall 
correctly. It turned out that the compressed read-only squashfs was not 
at all the root of the issues some people were seeing.

Rather, those were directly related to a corrupted overlay file, whether 
it was caused by unplugging the usb stick too early or filling up the 
overlay file quickly. Resetting the overlay file took away all these 
issues, though.

[...]

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

As much as it might be wrong: Upstream has a reason in doing so. And 
we're going to stick with what upstream is doing. I used to explain a 
major goal for this release to be increasing the sustainability of the 
whole process. Diverging from upstream is not going to achieve this.

OLPC went through this. And so did I. The final Blueberry build was 
created late in the night before I was having another school exam in the 
morning and directly afterwards rushing to the airport to catch a plane 
to Toronto.

Anything that diverges from upstream (let it be Fedora, Sugar, or any 
other project) leaves us with a gap. Everything we hack up ourselves 
will return to us when it comes to support. And we don't want our users 
to download either a 4 GB image (or a 700 MB one, which takes them half 
a day to uncompress), right?

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

Bruno Wolff has proposed a feature to use a better compression for the 
live images in Fedora. This isn't going to happen for F13, but rather 
F14, it seems [1].

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

I don't think there's an "us" and "them" there. People from Fedora 
contribute to Sugar on a Stick, in the same way as people from Sugar 
Labs do. It's somehow what makes this project so cool, too.

So. I was talking to Sascha yesterday on IRC and we came up with some 
ideas how to proceed here. I don't think that the we should stop using 
squashfs images. Because I don't see a reason to stop doing so.

On the overlay, an approach that we came up with introduced a new 
partition (possibly ext4) for the overlay only. That would mean that the 
bootloader and the squashfs file would stay on a fat32 partition, 
allowing users even to exchange data with their windows machines. On the 
other hand, we'd reference the new overlay partition (instead of the 
overlay file) in the syslinux.cfg.

I don't know whether this is possible. But now is the time to work it 
out. It would allow us to continue to use the existing infrastructure, 
while working on the roots of relevant issues directly.

--Sebastian

[1] https://fedoraproject.org/wiki/Features/LZMA_for_Live_Images