[SoaS] [Sugar-devel] SOAS 2 problems

[Tomeu Vizoso]

On Mon, Jan 25, 2010 at 20:21, Sebastian Dziallas <sebastian at when.com> wrote:
> 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.

But the journal writes in $HOME which is in a separate partition?

The overlay getting filled up is a real problem because its
consequences, but would only affect users which write to root-owned
places, unless I'm missing something?

I think that in many SoaS scenarios, we don't need an overlay file of
more than a hundred KBs for whatever config files daemons may write.

Regards,

Tomeu

> 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
> _______________________________________________
> SoaS mailing list
> SoaS at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/soas
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning