<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
<div>Hi...</div><div><br></div>I've been following your discussion with interest, especially since I set it off... and I am meeting with the folks in Buenos Aires tomorrow evening. One thing I should have mentioned in one of my earlier emails is that when I created the usb stick for Blueberry with the live usb creator, I forgot to allot storage space on the stick... it was my first time using the tool and didn't realize I had to do it. Therefore, I suspect the journal filled quickly (it was working fine at first). The end result was that everything froze and when we finally did a hard shut down, we were unable to get Windows to load again. I think it was XP, but I'm not sure. It was my daughter-in-law's machine.<div><br></div><div>As an aside, we seemed to have the "reverse midas touch" at their house. We put our clothes in their computerized washing machine to wash them before going to the airport. The machine froze! Our clothes were locked in! Our son came home from work to liberate them. Evidently it has happened before. He had to open the machine and keep plugging and unplugging various wires. Seems that some things are better not computerized!</div><div><br></div><div>But for SoaS, I'm looking forward to using the wonderful new easy to use version that you folks are working on!</div><div><br></div><div>Caryl<br><br>> Date: Sun, 24 Jan 2010 14:41:46 -0700<br>> From: dmc.sugar@filteredperception.org<br>> To: soas@lists.sugarlabs.org<br>> Subject: Re: [SoaS] [Sugar-devel] SOAS 2 problems<br>> <br>> On 01/24/2010 02:07 PM, Bernie Innocenti wrote:<br>> > On Sun, 2010-01-24 at 14:34 +1200, David Leeming wrote:<br>> >> I am sorry that I am a little slow on the uptake.<br>> >> Blueberry SOAS2 seems to work OK. I have used LiveUSBCreator<br>> >> and it's installed on a flash drive. Is this what you are<br>> >> recommending? We have done this on several PCs and notebooks<br>> >> and it is fine, although I admit we haven't really pushed it.<br>> >><br>> >> Are you saying that there is a risk that whilst in use,<br>> >> there is a chance that they could render it inoperable?<br>> >> If so, no worries as it can simply be re-flashed, we can<br>> >> live with that.<br>> ><br>> > Have you tried writing to the journal until you fill up the overlay<br>> > space?<br>> ><br>> > Unless I'm seriously misunderstanding how LVM snapshots work, this<br>> > should systematically make the flash drive inoperable until reformatted,<br>> > and all data inaccessible.<br>> ><br>> > This is not a random bug, it's the result of copy-on-write becoming<br>> > read-only due to lack of spare blocks and the ext3 filesystem being<br>> > unwilling to mount itself without first committing the journal. Each<br>> > subsystem is doing the "right thing" individually, but the resulting<br>> > interaction results in this very unfortunate behavior.<br>> <br>> I would disagree that ext3 refusing to mount itself in read only mode <br>> without committing the journal is the 'right thing'. I myself haven't <br>> run into this combination of events, but what you describe is plausible. <br>> There are pretty easy ways to work around the 'unrecoverable' aspect. <br>> I.e. easy to have a rescue mode where additional blocks can be made <br>> available to the overlay from ram.<br>> <br>> ...<br>> <br>> ><br>> > Hope I'm not being too technical :) The bottom line is: we shouldn't be<br>> > doing this in SoaS, no matter what upstream is doing. Upstream is wrong<br>> > in doing it.<br>> <br>> ...<br>> <br>> That is quite a pronouncement, but you didn't bother to explain why <br>> things are the way they are as opposed to some alternate way that you <br>> didn't mention.<br>> <br>> It is important to remember that the fedora _liveusb_ is the way it is, <br>> because it was an extension of the _livecd_. Lots of reasons, many <br>> historically transient, contribute to the way things are, and you need <br>> to understand that history when discussing how to go forward. For <br>> instance, the livecd was compressed, importantly fitting 1.5G of <br>> applications in .5G of filesystem. A filesystem that had to be readonly.<br>> <br>> Clearly moving the media from a 700MB read-only one, to a 1G slowly <br>> writable one, changed the game, opened new possibilites, and thus you <br>> have people enjoying the F7 liveusb on 1G stick experience.<br>> <br>> To the point that SoaS grew from that useful experience.<br>> <br>> Now, these days you have relatively cheap 8G sticks, that don't suffer <br>> nearly as badly from slow write performance.<br>> <br>> Thus more possibilities are opened.<br>> <br>> > My understanding is that Fedora would also like to get this problem<br>> > fixed, but the live usb tools package is currently missing a full-time<br>> > maintainer and, thus, the fix is not happening.<br>> <br>> What 'fix' do you speak of?<br>> <br>> Please note that this discussion came up on centos-devel. It was noted <br>> that the only bulletproof way to use the overlay method without running <br>> into out-of-overlay problems, is for your overlay to be a little bit <br>> larger (say 105%) than the size of the uncompressed root filesystem. <br>> I.e. that may be 2G in SoaS-BB (haven't looked recently).<br>> <br>> Another vast improvement that I posited to dm-devel, was to utilize the <br>> new discard request feature of the kernel to let devicemapper <br>> intelligently reuse overlay blocks that the filesystem no longer cares <br>> about. No real reception to the idea to speak of.<br>> <br>> ><br>> > The fix for us is easier, because we don't really need any of the fancy<br>> > things that livecd-iso-to-disk does. All we need to do is stop<br>> > mentioning it in our wiki and switch to liveinst, as Peter Robinson<br>> > suggests, or any other tool that does the (rather trivial) job of<br>> > transferring an ext3 image onto a (flash) drive.<br>> <br>> Due the the changing price/quality/size constraints of usb pluggable <br>> flash memory these days, it does make sense for liveusb-creator to have <br>> an alternate installation code path, that instead writes a normal <br>> installation, instead of a 'live' installation to the target stick. If <br>> I had the time to spare, I'd love to write it, but sadly I don't. I'm <br>> also quite willing to help guide anyone that wishes to do so, if in fact <br>> they need any help. But of course, zyx-liveinstaller can already do <br>> this from a booted blueberry livecd burned from the .iso, or from the <br>> liveusb form that can also be created from the bb livecd booted. And I <br>> honestly don't know how good an idea it is to focus on the <br>> installation/creation methods that depend on a proprietary OS. I think <br>> it is much better to teach people an installation method that works, <br>> whether or not a proprietary OS is installed on their system. (or a <br>> proprietary OS that may or may not already be loaded down with virii and <br>> malware)<br>> <br>> -dmc<br>> _______________________________________________<br>> SoaS mailing list<br>> SoaS@lists.sugarlabs.org<br>> http://lists.sugarlabs.org/listinfo/soas<br></div>                                            </body>
</html>