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. 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 [email protected] http://lists.sugarlabs.org/listinfo/soas
