[SoaS] [Sugar-devel] SOAS 2 problems

[Bernie Innocenti]

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.

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.

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.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/