here is what i have I tried this afternoon bunzip xo-1....tar.bz2 mkdir os703 tar xvf xo-1..tar -C os703/
then mkfs.jffs2 -n -e128KiB -r os703 -o testpre.img sumtool -n -p -e 128KiB -i testpre.img -o testpost.img ../pilgrim/crcimg/crcimg testpost.img copyied testpost.img and testpost.crc to my usb key On the XO: copy-nand u:\testpost.img /usr/bin/startx/: line 144: cannot create temp file for here document : Permission denied fatal server error: Could not create lock file in /tmp/.tX0-lock I don't have any more time to work on this today. Perhaps I can look at it next week. I took a look at Puritan but couldn't figure out how to build it. Again time is a constraint. > * bootUSB -> edit -> savenand, and I have tried to boot the XO from a USB key but couldn't figure it out after half a day's work. Perhaps this owes to my own inexperience rather than this particular method. Michael, sorry if I have been rude in my mails. I have been quite stressed this week leading up to Friday's launch. I do appreciate your help. On Tue, 2008-04-22 at 00:40 -0400, Michael Stone wrote: > Bryan, > > > not very elegant. Would like a better solution but time is short. > > I've already suggested three more elegant mechanisms: > > * tarball -> edit -> mkfs.jffs2, > > * bootUSB -> edit -> savenand, and > > * puritan. > > > We don't expect the kids to run olpc-update do we? Running OLPC-Update > > on 170 XO's would be a headache for me to do manually. Also, I would > > have to set up my olpc-update server here in Kathmandu because we don't > > have the international bandwidth to update against servers in the US > > I don't really have expectations one way or the other. (Incidentally, > update-servers are just rsync servers with some special modules. The 1cc > version is fancy because it loads builds on demand and caches them.) > > > Anna Schoolfield of the Birmingham School District has asked me how to > > customize an xo image. Lacking a more elegant method, I will have to > > point her to my current one. > > I'm rapidly starting to think that we ought to refine the > > * tarball -> edit -> mkfs.jffs2 > > into a > > clone -> hack -> publish -> export-to-jffs2 > > workflow. After all - what's really gained by rebuilding images from > packages each time you want to make a change? > > (Don't get me wrong - packages should still be the default method for > hacking. I just see no reason to _require_ people to rebuild the > filesystem tree from scratch every time they need to change it.) > > Michael _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel