On Mon, Jan 25, 2010 at 20:21, Sebastian Dziallas <[email protected]> wrote: > 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.
But the journal writes in $HOME which is in a separate partition? The overlay getting filled up is a real problem because its consequences, but would only affect users which write to root-owned places, unless I'm missing something? I think that in many SoaS scenarios, we don't need an overlay file of more than a hundred KBs for whatever config files daemons may write. Regards, Tomeu > 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 > -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning _______________________________________________ SoaS mailing list [email protected] http://lists.sugarlabs.org/listinfo/soas
