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