<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Bernie Innocenti wrote: <blockquote cite="mid:1264772878.10230.536.camel@giskard" type="cite"> <pre wrap="">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: </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap=""> 1. write normally to the filesystem (dd if=/dev/random of=foobar) 2. boom! </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> If you use a larger USB 4, 8, 16GB updates work fine. It seems to only corrupt when the overlay fills up. <blockquote cite="mid:1264772878.10230.536.camel@giskard" type="cite"> <pre wrap="">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. </pre> <blockquote type="cite"> <pre wrap="">[...] 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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> <blockquote type="cite"> <pre wrap="">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). </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> I was unable to get the xz compression to decompress using tools in Ubuntu 9.10 <blockquote cite="mid:1264772878.10230.536.camel@giskard" type="cite"> <pre wrap="">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. </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> </body> </html>