[SoaS] [Sugar-devel] SOAS 2 problems

[Sebastian Dziallas]

Tomeu Vizoso wrote:
> 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.

It depends. When creating SoaS, you've several options. You can for 
example have a separate overlay file for /home. However, just having one 
big overlay file is the most common approach by now, as that's the one 
liveusb-creator supports and the one we've been talking about lately 
when it came to livecd-iso-to-disk. So in this case, our big overlay 
file would take all changes.

--Sebastian

> 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