On 01/24/2010 02:07 PM, 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? > > Unless I'm seriously misunderstanding how LVM snapshots work, this > should systematically make the flash drive inoperable until reformatted, > and all data inaccessible. > > This is not a random bug, it's the result of copy-on-write becoming > read-only due to lack of spare blocks and the ext3 filesystem being > unwilling to mount itself without first committing the journal. Each > subsystem is doing the "right thing" individually, but the resulting > interaction results in this very unfortunate behavior.
I would disagree that ext3 refusing to mount itself in read only mode without committing the journal is the 'right thing'. I myself haven't run into this combination of events, but what you describe is plausible. There are pretty easy ways to work around the 'unrecoverable' aspect. I.e. easy to have a rescue mode where additional blocks can be made available to the overlay from ram. ... > > 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. ... That is quite a pronouncement, but you didn't bother to explain why things are the way they are as opposed to some alternate way that you didn't mention. It is important to remember that the fedora _liveusb_ is the way it is, because it was an extension of the _livecd_. Lots of reasons, many historically transient, contribute to the way things are, and you need to understand that history when discussing how to go forward. For instance, the livecd was compressed, importantly fitting 1.5G of applications in .5G of filesystem. A filesystem that had to be readonly. Clearly moving the media from a 700MB read-only one, to a 1G slowly writable one, changed the game, opened new possibilites, and thus you have people enjoying the F7 liveusb on 1G stick experience. To the point that SoaS grew from that useful experience. Now, these days you have relatively cheap 8G sticks, that don't suffer nearly as badly from slow write performance. Thus more possibilities are opened. > 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. What 'fix' do you speak of? Please note that this discussion came up on centos-devel. It was noted that the only bulletproof way to use the overlay method without running into out-of-overlay problems, is for your overlay to be a little bit larger (say 105%) than the size of the uncompressed root filesystem. I.e. that may be 2G in SoaS-BB (haven't looked recently). Another vast improvement that I posited to dm-devel, was to utilize the new discard request feature of the kernel to let devicemapper intelligently reuse overlay blocks that the filesystem no longer cares about. No real reception to the idea to speak of. > > 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. Due the the changing price/quality/size constraints of usb pluggable flash memory these days, it does make sense for liveusb-creator to have an alternate installation code path, that instead writes a normal installation, instead of a 'live' installation to the target stick. If I had the time to spare, I'd love to write it, but sadly I don't. I'm also quite willing to help guide anyone that wishes to do so, if in fact they need any help. But of course, zyx-liveinstaller can already do this from a booted blueberry livecd burned from the .iso, or from the liveusb form that can also be created from the bb livecd booted. And I honestly don't know how good an idea it is to focus on the installation/creation methods that depend on a proprietary OS. I think it is much better to teach people an installation method that works, whether or not a proprietary OS is installed on their system. (or a proprietary OS that may or may not already be loaded down with virii and malware) -dmc _______________________________________________ SoaS mailing list [email protected] http://lists.sugarlabs.org/listinfo/soas
