[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

jigdo for olpc



The OLPC project http://laptop.org builds daily VM and live cd images that are about 128mb.

128mb isn't much, but it becomes inconvenient when you want to find what build caused a bug, and need to pull the last 5 or so files.

currently they are compressing everything using either bzip or squashfs. I realize jigdo won't work with that as is, but I am hoping it wont be too hard tweak the build scrips. given that the iso image using squishfs is only 128mb, I am hoping that a normal uncompressed iso version will be under 700mb. This iso could be built, run jigdo against it, then delete it. now if someone wants to use jigdo, they will end up with an uncompressed image, but it will be able to be assembled quickly from existing files plus the few small files jigdo downloads.

images and descriptions

http://olpc.download.redhat.com/olpc/streams/development/build190-20061129_1504/livecd/
http://olpc.download.redhat.com/olpc/streams/development/build190-20061129_1504/devel_jffs2/

http://wiki.laptop.org/go/OS_images_for_emulation
http://wiki.laptop.org/go/OS_images

Questions:

1. Will jigdo work with other fs images, like the ext3 ones?

2. If many versions (100) of the the squishfs iso is stored on the server, and it takes 3 mount -o loop's to get to the actual files:

$ mount
olpc-redhat-stream-development-livecd.iso on iso type iso9660 (rw,loop=/dev/loop/0)
iso/squashfs.img on squash type squashfs (ro,loop=/dev/loop2)

carl@vaio:/media/hdb1/home/juser/vmware/olpc$ sudo losetup /dev/loop7 -o 31744 squash/os.img

$ sudo mount -o loop squash/os.img img/
$ sudo mount /dev/loop7 os/
$ mount
/dev/loop7 on os type ext3 (ro)

Will the server have a problem with the 300 loopbacks? If so, is there some way to make apache bring them up and down automatically?

Carl Karsten



Reply to: