On Sun, 2010-01-24 at 22:08 -0700, Douglas McClendon wrote: > 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.
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. > 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. 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 ;-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ _______________________________________________ SoaS mailing list [email protected] http://lists.sugarlabs.org/listinfo/soas
