[SoaS] [Sugar-devel] SOAS 2 problems

[Thomas C Gilliard]

Bernie;

I downloaded your Soas-2-Blueberry.img and tested it:

http://people.sugarlabs.org/bernie/soas-2-blueberry-direct-2GB.img.xz

(Note Ubuntu 9.04 Archive Manager will not decompress .xz files
I then used F12 (Constantine) Edu Spin Archive Manager (usb HD install) 
to do it.)

In terminal:

#dd if=soas-2-blueberry-direct-2GB.img of=/dev/sd(b)   * check (b)  
before using this line.
4014080+0 records in
4013080+0 rocords out
2055208960 bytes (2.1GB) copied, 421.373 s, 4.9MB/s
#

Used 4GB Sandisk USB formatted Fat16 ( boot flag) using Fedora GParted 
(graphical)

Grub Boot Menu shows Strawberry on first line
It boots fine to Plymouth graphical screen
comes up to BernieSoaS name and green blue color
On CP shows Soas version 2 (Blueberry) 0.86.3
Did successful update of 13 activities
Has 43? Activities in F3 screen.
F1 Network connects to Jabber

Very Nice. : )

Tom Gilliard
satellit


Bernie Innocenti wrote:
> On Sun, 2010-01-24 at 22:08 -0700, Douglas McClendon wrote:
>   
>> Bernie, please file a bug with fedora against livecd-tools.  I will 
>> craft a fix that at boot time, upon detecting a filled overlay on usb 
>> storage, automatically adds a second overlay based in ram (as the livecd 
>> or nonpersistent liveusb do normally).
>>
>> In this way, you should always be able to boot.  I will add a text 
>> message displayed at the time, telling the user that the overlay is 
>> full, and that new changes will only be temporarily written to memory, 
>> and that they should copy any needed data to another device, and then 
>> reset their overlay at next boot by adding the kernel parameter 
>> 'reset_overlay' when they next boot.
>>     
>
> I'm glad you're willing to solve the issue, but the proposed solution
> seems too kludgy to be feasible. It brings even more corner cases and
> failure modes, such as: what if the USB stick is full? what if the user
> carelessly lets the second overlay fill up?
>
> I agree that I've been too quick in calling what liveusb is doing
> "wrong". There are certainly some use-cases where it makes sense to use
> a compressed filesystem with a writable overlay in order to reduce the
> image size and reduce data reads. (although, in my tests, the direct
> ext3 filesystem beats squashfs by a few seconds on regular 4GB USB
> sticks).
>
> All considered, I'm convinced that this entire squashfs + dm-snap
> approach is borked beyond any possibility of repair. If we really had to
> use compression, I'd go for a unionfs based approach instead. The
> downside is that, while there are plenty of unionfs implementations
> around for Linux, none of which has ever made it into the vanilla kernel
> due to unsolvable design issues. Since Fedora is (understandably)
> reluctant to rely on large patches not in Linus' tree, we're kind of
> stuck.
>
>
>   
>> Now, the closest thing livecd-tools has to a maintainer at the moment is 
>> I think someone who considers me an obnoxious <expletive deleted> due to 
>> a prior exchange we had about a 1 line reversion of a reversion to the 
>> code.  Of course the feeling is mutual, but hopefully it won't interfere 
>> with the adoption of the above solution/workaround to the problem you 
>> described.
>>     
>
> Ah, the joys of social interaction between engineers, where technical
> disagreement can quickly degenerate into personal issues! Fear, anger,
> hate... the dark side are they ;-)
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/soas/attachments/20100129/26b0689f/attachment-0001.htm