<div class="gmail_quote">On Tue, Apr 14, 2009 at 4:16 AM, Tomeu Vizoso <<a href="mailto:tomeu@sugarlabs.org">tomeu@sugarlabs.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> [cc'ing fedora-olpc because we are using unmodified fedora tools] <div class="im"> On Mon, Apr 13, 2009 at 23:33, Walter Bender <<a href="mailto:walter.bender@gmail.com">walter.bender@gmail.com</a>> wrote: > Thanks. This is all helpful. I wonder what the Fedora USB Creator does > when it runs under Windows? </div>AFAIK, what Mitch says is what we currently do when using both livecd-iso-to-disk.sh and the Fedora Live USB creator. For flashing a big number of sticks with a port replicator, we could first use livecd-iso-to-disk.sh to copy the partition files to one stick and set the bootable flag, then use dd to read into an image and then dd again to write it to the rest of the sticks, provided they are actually identical inside. </blockquote><div> I don't think they are actually identical inside. They show up as all different sizes. I used dd to make an image then zcat to write it to new sticks. zcat ./SoaS-Beta-4-9.img.Z > /dev/disk2 I got a fairly high failure rate so I'm not saying this is a good method. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Regards, Tomeu <div><div></div><div class="h5"> > -walter > > On Mon, Apr 13, 2009 at 3:53 PM, Mitch Bradley <<a href="mailto:wmb@laptop.org">wmb@laptop.org</a>> wrote: >> My first order recommendation is "don't use dd to blast an image over the >> existing partition map". >> >> The problem with doing so is that it wrecks the factory partition layout. I >> strongly suspect that said factory layout is, on many sticks, optimized for >> the characteristics of the stick's internal firmware and the hardware block >> sizes of the NAND Flash chips. >> >> Unfortunately, the alternative is rather more complicated procedurally than >> "dd and pray". But given the indifferent results from dd&pray, I think it >> may be worthwhile to go for a more elaborate procedure. >> >> Here is an outline of what I think really should be done: >> >> a) Ensure that your filesystem image is somewhat smaller than 1G (or 2G or >> whatever your base size) so it will fit on "all" 1G devices. >> >> b) The image is just the partition contents, excluding the partition block >> and master boot record. >> >> c) The installation procedure involves >> >> c1) Editing (not replacing) the existing partition map, setting the first >> partition's "boot flag" byte and changing its filesystem type to ext2 or >> whatever. (Ideally it would better not to change the filesystem type, >> instead sticking with the factory FAT partition, but I understand what a >> hard nut that is to swallow for Linux enthusiasts.) >> >> c2) Copying the image into the partition >> >> c3) Installing your bootloader using an installation program instead of dd, >> thus replacing the first sector's Master Boot Record and doing whatever else >> is necessary to complete the bootloader's installation. I have had the best >> results with syslinux. >> >> There is, of course, a chicken-and-egg problem of how do you run the >> bootloader's installer. On the other hand, you have the same problem with >> "dd" - in principle, on any machine that can run "dd", you can also run >> syslinux. >> >> If you want to talk more about this issue, please feel free to keep the >> conversation going. It is a topic that has been much on mind recently. >> >> Mitch >> >> >> >> Walter Bender wrote: >>> >>> I was wondering if you have any words of wisdom to share with us re >>> USB stick compatibility, given your experience with the XO. There >>> seems to be a lot of variability in terms of which sticks boot which >>> machines in our Sugar-on-a-Stick experiments, e.g., using the same >>> machine (a Classmate running XP) to burn the same image (the Beta SoaS >>> iso) onto USB storage media from three different vendors, I cannot >>> predict which one(s) will be bootable on any particular piece of >>> hardware. Is there any deterministic way to proceed, or is trail and >>> error our only recourse? >>> >>> thanks. >>> >>> -walter >>> >>> >> > > > > -- > Walter Bender > Sugar Labs > <a href="http://www.sugarlabs.org" target="_blank">http://www.sugarlabs.org</a> > _______________________________________________ > Sugar-devel mailing list > <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> > <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> > _______________________________________________ Sugar-devel mailing list <a href="mailto:Sugar-devel@lists.sugarlabs.org">Sugar-devel@lists.sugarlabs.org</a> <a href="http://lists.sugarlabs.org/listinfo/sugar-devel" target="_blank">http://lists.sugarlabs.org/listinfo/sugar-devel</a> </div></div></blockquote></div> -- Caroline Meeks Solution Grove Caroline@SolutionGrove.com 617-500-3488 - Office 505-213-3268 - Fax