[SoaS] [Sugar-devel] SOAS 2 problems

[Thomas C Gilliard]

Bernie Innocenti wrote:
> I'll skip over the parts that we've already discussed on #sugar.
>
>
> On Wed, 2010-01-27 at 07:30 +0100, Sebastian Dziallas wrote:
>   
>>>   1. write normally to the filesystem (dd if=/dev/random of=foobar)
>>>   2. boom!
>>>       
>> Admittedly, randomly dd'ing stuff the filesystem is not the usual 
>> use-case for the average Sugar user, right? As I said, others did 
>> testing over the time, resulting in the assumption of the overlay being 
>> the issue.
>>     
>
> Here's a usecase that triggers the corruption:
>
>    yum update
>
> If there are sufficient updates, the overlay will fill up. Another
> interesting way to trigger the corruption is waiting for the prelink
> cronjob to trigger.
>
> A possible counter-argument is that users aren't supposed to run
> updates, install new software, or alter the base system in any way.
> Well, if this were the case, why are we making the root writable in the
> first place?
>
> In fact, I lied when I said that it is *impossible* to prevent the
> overlay from getting corrupted at some point. If the overlay were the
> same size or bigger than the ext3 filesystem itself (2GB), then it would
> never run out of pages.
>
>   
If you use a larger USB 4, 8, 16GB updates work fine. It seems to only 
corrupt when the overlay fills up.

> But then, why waste the extra 580MB of disk space for the squashfs
> image?
>
> Choosing any intermediate size for the overlay is like betting that our
> users (and their applications) will be responsible in not abusing their
> writable USB stick. Wouldn't you rather switch to a scheme that doesn't
> require warning users against such a pitfall?
>
> Also, the squashfs compression becomes less and less attractive as we
> shave stuff from it. On IRC, we determined that documentation and
> languages are taking up *huge* amounts of space in SoaS.
>
> This might explain why the the SoaS filesystem contains a whopping 1.6GB
> of files, while F11-XO1 is just about 550MB with Gnome included!
>
> If we agree that the main purpose of SoaS is to showcase Sugar rather
> than the underlying Linux console, we may conclude that manpages and
> system documentation can be safely shaved off from the installation
> (the rpm macro is "%_installdocs 0", iirc).
>
> Since users are going to interact with activities rather than cli tools,
> we may also get rid of all the locale catalogs ("%_install_langs en" or
> something like that).
>
> This would make squashfs much less attractive, because documentation and
> locale are probably the only things that compress well.
>
>
>   
>> [...]
>>
>> The current implementation has undeniably probably a lot more users than 
>> Sugar on a Stick will ever have.
>>
>> So it might be that the current livecd-tools lacks a full-time 
>> maintainer. This doesn't make all the work that happens naturally 
>> upstream for testing and verifying go away, though.
>>     
>
> Upstream offers many different installation options, with different
> levels of support and testing.
>
> We picked one that seemed reasonable for our usecase, but it turned out
> that it has a number of unsolved/unsolvable issues. My point is that we
> should switch to another option *also supported by upstream*, but
> simpler and more reliable.
>
>
>   
>> So the image literally beams itself onto the USB key? That's what I call 
>> a feature! Yay. :)
>>
>> What I'm saying is: You certainly don't want users to have to boot a 
>> Fedora LiveCD to start a simple liveinst. But somehow your image needs 
>> to get onto the USB key, if I'm not misinformed.
>>     
>
> I think we agreed that livecd-iso-to-disk is harder to use than dd, and
> requires a PC with Fedora to use.
>
> The Intel Moblin wrapper script which you suggested would make a better
> compromise between simplicity, safety and compatibility with other UNIX
> variants.
>
>
>   
>> Not yet. It looks like it totally went unnoticed that we actually 
>> /created/ these image files (which was by the way possible by the 
>> awesome work of Martin Dengler). When being compressed with LZMA, they 
>> came somewhat close to the .iso size, but took quite some time to 
>> extract (on my pretty decent 3 GHz Dual Core, even).
>>     
>
> I used xz, which is pretty much the finalized standard format of lzma.
> Compression is dog slow, but decompression should be a lot faster than
> bzip2.
>
>   
I was unable to get the xz compression to decompress using tools in 
Ubuntu 9.10
> My compressed images came out a lot smaller than the ISO: 416MB vs
> 589MB. Which, by itself, would make it the preferred distribution format
> for many users with limited bandwidth.
>
>
>   
>> Basically, we went this way you're proposing for Blueberry already. And 
>> I haven't heard back from anybody concerning the use of those files. 
>> Instead, I was running around, trying to work out why it wouldn't boot 
>> on my machine when the old layout would.
>>     
>
> Oh! How could this possibly happen?
>
> The build scripts might have partitioned your USB stick with the wrong
> number of heads/sectors, or failed to install the MBR...
>
> It's worth investigating, because I believe the combination of grub +
> ext3 to be actually the *most compatible* with existing BIOSes, although
> isolinux is also quite safe.
>
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/soas/attachments/20100129/bed47ffb/attachment.htm