Tomeu Vizoso wrote: > 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.
It depends. When creating SoaS, you've several options. You can for example have a separate overlay file for /home. However, just having one big overlay file is the most common approach by now, as that's the one liveusb-creator supports and the one we've been talking about lately when it came to livecd-iso-to-disk. So in this case, our big overlay file would take all changes. --Sebastian > 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 _______________________________________________ SoaS mailing list [email protected] http://lists.sugarlabs.org/listinfo/soas
