[Server-devel] Customizing build 703 for mass deployment

[Bryan Berry]

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