Someone forwarded me a slashdot article with a link to an IBM article on how to design an application for the OLPC. I haven’t gone to far into it, but it has goes into how to set up QEMU (at least in the simple case), why python was a good language for OLPC to have chosen and then what you need to do. I figured if I didn’t post it here, I’ll be looking for it later, and it might help someone else out so here it is: IBM: Application development for the OLPC laptop.

While using the OLPC under QEMU, I immediately started installing a bunch of development tools into the image. This quickly filled up the 1GB image, and so I wanted increase the size of it.

Originally I tried to dd some space onto the end of it and use parted to expand the image but it gave me an error saying: “Error: File system has an incompatible feature enabled.” And so this is how I got it to work:

1. Make the newimage:
   

   dd if=/dev/zero of=newimage bs=1GB count=5

2. Start up QEMU with your OLPC image with this newimage as a 2nd drive:
   

   qemu -m 256 -soundhw es1370 -serial /dev/pts/1 -net user -net nic,model=rtl8139 -hda laptop-orig.img -hdb newimg

3. From inside the image I then tried to dd /dev/hda to /dev/hdb, but that didn’t work exactly, though I forget now exactly why. It could have been that I needed to re-read the partition table on disk B, but I’m not sure. We still need to do this however for at least the first part of the disk so we get the MBR. (Note: I’m fudging this step to be what I think it should have been, if it doesn’t work, try copying the whole disk)
   

   dd if=/dev/hda of=/dev/hdb bs=4k count=1

4. Still within the image we want to fdisk the new disk, delete the partition that’s there and make it larger. Technically speaking, if we do this and the partition has the same starting block, I thought that I would be able to still use it (since I had copied the whole disk), but that didn’t seem to be the case.
   

   -bash-3.2# fdisk /dev/hdb

   The number of cylinders for this disk is set to 9844.
   There is nothing wrong with that, but this is larger than 1024,
   and could in certain setups cause problems with:
   1) software that runs at boot time (e.g., old versions of LILO)
   2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

   Command (m for help): p

   Disk /dev/hdb: 5000 MB, 5000000000 bytes
   16 heads, 62 sectors/track, 9844 cylinders
   Units = cylinders of 992 * 512 = 507904 bytes

   Device Boot Start End Blocks Id System
   /dev/hdb1 1 9844 4882623+ 83 Linux

   Command (m for help): d
   Selected partition 1

   Command (m for help): n
   Command action
   e extended
   p primary partition (1-4)
   p
   Partition number (1-4): 1
   First cylinder (1-9844, default 1):
   Using default value 1
   Last cylinder or +size or +sizeM or +sizeK (1-9844, default 9844):
   Using default value 9844

   Command (m for help): w
   The partition table has been altered!

   Calling ioctl() to re-read partition table.
   Syncing disks.

5. So now we have our new disk with the MBR and a good partition table. Now its time to copy over our original image:
   

   -bash-3.2# dd if=/dev/hda1 of=/dev/hdb1 bs=4k
   237452+1 records in
   237452+1 records out
   972604416 bytes (973 MB) copied, 114.234 s, 8.5 MB/s

6. Now lets make sure that it works:
   

   -bash-3.2# mkdir t
   -bash-3.2# mount /dev/hdb1 t -t ext3
   -bash-3.2# ls t
   activities dev lib mnt proc security sys var
   bin etc lost+found ofw root selinux tmp
   boot home media opt sbin srv usr
   -bash-3.2# df -h
   Filesystem Size Used Avail Use% Mounted on
   /dev/hda1 913M 716M 189M 80% /
   tmpfs 38M 0 38M 0% /dev/shm
   /dev/hdb1 913M 716M 189M 80% /root/t
   -bash-3.2# umount t

   Notice its mounted, and has the same stats as our real system.

7. Now expand the filesystem to the length of the partition. resize2fs requires that we do an fsck first, so lets do that too:
   

   -bash-3.2# e2fsck -f /dev/hdb1 && !!
   e2fsck -f /dev/hdb1 && resize2fs -p /dev/hdb1
   e2fsck 1.40.2 (12-Jul-2007)
   Pass 1: Checking inodes, blocks, and sizes
   Pass 2: Checking directory structure
   Pass 3: Checking directory connectivity
   Pass 4: Checking reference counts
   Pass 5: Checking group summary information
   OLPCRoot: 22509/118784 files (0.9% non-contiguous), 186946/237452 blocks
   resize2fs 1.40.2 (12-Jul-2007)
   Resizing the filesystem on /dev/hdb1 to 1220648 (4k) blocks.
   Begin pass 1 (max = 30)
   Extending the inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   The filesystem on /dev/hdb1 is now 1220648 blocks long.

8. That should be it. Let’s mount it and see what it thinks!
   

   -bash-3.2# mount /dev/hdb1 t -t ext3
   -bash-3.2# df -h
   Filesystem Size Used Avail Use% Mounted on
   /dev/hda1 913M 716M 189M 80% /
   tmpfs 38M 0 38M 0% /dev/shm
   /dev/hdb1 4.6G 717M 3.9G 16% /root/t
   -bash-3.2# umount t
   -bash-3.2# rmdir t

And there we have it! Now we have a 5GB image to play with. I loaded this into QEMU just as I would any other image:

qemu -m 256 -soundhw es1370 -serial /dev/pts/1 -net user -net nic,model=rtl8139 -hda newimg

It booted up just fine! Feel free to download and install away, realizing of course that you won’t be able to ever apply this image directly to your OLPC, but it will at least allow you to develop first and worry about the size of things later on.