<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Bernie; I downloaded your Soas-2-Blueberry.img and tested it: <a class="moz-txt-link-freetext" href="http://people.sugarlabs.org/bernie/soas-2-blueberry-direct-2GB.img.xz">http://people.sugarlabs.org/bernie/soas-2-blueberry-direct-2GB.img.xz</a> (Note Ubuntu 9.04 Archive Manager will not decompress .xz files I then used F12 (Constantine) Edu Spin Archive Manager (usb HD install) to do it.) In terminal: #dd if=soas-2-blueberry-direct-2GB.img of=/dev/sd(b)   * check (b)  before using this line. 4014080+0 records in 4013080+0 rocords out 2055208960 bytes (2.1GB) copied, 421.373 s, 4.9MB/s # Used 4GB Sandisk USB formatted Fat16 ( boot flag) using Fedora GParted (graphical) Grub Boot Menu shows Strawberry on first line It boots fine to Plymouth graphical screen comes up to BernieSoaS name and green blue color On CP shows Soas version 2 (Blueberry) 0.86.3 Did successful update of 13 activities Has 43? Activities in F3 screen. F1 Network connects to Jabber Very Nice. : ) Tom Gilliard satellit Bernie Innocenti wrote: <blockquote cite="mid:1264432753.20904.168.camel@giskard" type="cite"> <pre wrap="">On Sun, 2010-01-24 at 22:08 -0700, Douglas McClendon wrote: </pre> <blockquote type="cite"> <pre wrap="">Bernie, please file a bug with fedora against livecd-tools. I will craft a fix that at boot time, upon detecting a filled overlay on usb storage, automatically adds a second overlay based in ram (as the livecd or nonpersistent liveusb do normally). In this way, you should always be able to boot. I will add a text message displayed at the time, telling the user that the overlay is full, and that new changes will only be temporarily written to memory, and that they should copy any needed data to another device, and then reset their overlay at next boot by adding the kernel parameter 'reset_overlay' when they next boot. </pre> </blockquote> <pre wrap=""> I'm glad you're willing to solve the issue, but the proposed solution seems too kludgy to be feasible. It brings even more corner cases and failure modes, such as: what if the USB stick is full? what if the user carelessly lets the second overlay fill up? I agree that I've been too quick in calling what liveusb is doing "wrong". There are certainly some use-cases where it makes sense to use a compressed filesystem with a writable overlay in order to reduce the image size and reduce data reads. (although, in my tests, the direct ext3 filesystem beats squashfs by a few seconds on regular 4GB USB sticks). All considered, I'm convinced that this entire squashfs + dm-snap approach is borked beyond any possibility of repair. If we really had to use compression, I'd go for a unionfs based approach instead. The downside is that, while there are plenty of unionfs implementations around for Linux, none of which has ever made it into the vanilla kernel due to unsolvable design issues. Since Fedora is (understandably) reluctant to rely on large patches not in Linus' tree, we're kind of stuck. </pre> <blockquote type="cite"> <pre wrap="">Now, the closest thing livecd-tools has to a maintainer at the moment is I think someone who considers me an obnoxious <expletive deleted> due to a prior exchange we had about a 1 line reversion of a reversion to the code. Of course the feeling is mutual, but hopefully it won't interfere with the adoption of the above solution/workaround to the problem you described. </pre> </blockquote> <pre wrap=""> Ah, the joys of social interaction between engineers, where technical disagreement can quickly degenerate into personal issues! Fear, anger, hate... the dark side are they ;-) </pre> </blockquote> </body> </html>