The OLPC XO computer has a meagre 1 GB internal storage. However, this can be supplemented by an SD card. Here are instructions on how to put the /home directory onto an SD card, based on a post I made to olpcnews.com. Follow these directions at your own risk.
First, an executive summary:
I first tried this on a cheap 1 GB SD card, and when it worked, splurged on a SanDisk Ultra II with 8 GB of space. This SD card is fast (for an SD card), and while 8 GB isn't a lot compared to the size of hard drives these days, it is 8 times the space the XO comes with (note, this card also comes with a USB reader, handy for the first steps below).
But it isn't just a question of having the space, but also of where stuff gets put by default. Programs, most notably that ever growing Journal, use the /home/olpc directory. It would be nice if we had so much space on /home that we didn't have to worry too much about that.
Note, I'm using Linux. If you're a Windows user you'll need to figure out a way to get an ext2 filesystem onto the SD, possibly using a live cd like Knoppix and following the directions below. In the far past when I was a Windows user, the super partitioning program of the day was called Partition Magic and it supported ext2. There may be more options today (http://en.wikipedia.org/wiki/List_of_partition_utilities).
All we really want to do is replace the windows file system on the partition on the card with an ext2 file system. However, the XO mounts the SD on boot and you may have the devil's time of it getting it to let go. That's why it's easier just to use a usb card reader connected to a workstation to change the file system. If the OS on the workstation offers to open it or whatever, just say no. We don't want it mounted.
With card in card reader, and card reader connected by USB to the computer, I issue an fdisk -l from the command line to see my devices:
root@bast:~# fdisk -l Disk /dev/sda: 320.0 GB, 320072933376 bytes 255 heads, 63 sectors/track, 38913 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000dfb70 Device Boot Start End Blocks Id System /dev/sda1 * 1 38156 306488038+ 83 Linux /dev/sda2 38157 38913 6080602+ 5 Extended /dev/sda5 38157 38913 6080571 82 Linux swap / Solaris Disk /dev/sdb: 8168 MB, 8168931328 bytes 39 heads, 5 sectors/track, 81820 cylinders Units = cylinders of 195 * 512 = 99840 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System /dev/sdb1 1 81820 7977447+ c W95 FAT32 (LBA)
Clearly /dev/sda is my SATA hard drive, and /dev/sdb has to be the SD card, since I don't have any other devices connected that could be /dev/sdb. fdisk is a spartan old thing. If you're using something nice and gui it might be more explicit. And it's important to know what you're doing, since we're messing with partitions and file systems, things where your data lives, places where if things go wrong, it can really ruin your day. In fact, you probably shouldn't even mess with these things unless you have all the data you value on your workstation backed up. The difference of a single letter in a command can really, really screw things up
That said, lets rush in where angels fear to tread. I would type mkfs.ext2 /dev/sdb1
because I know that's the SD card in my machine. What you need to type may be different, and if you have a second hard drive that's identified as /dev/sdb, you really don't want to be reformatting the first partition on it, so be very sure of your device. . If you have a user friendly linux distribution that puts a nice icon for the device on the desktop for you, right click on it and check its properties to see if its device name is listed there.
fdisk /dev/sdb can be used to check out the partitions on that device, or any other you think a likely candidate for the SD card. Once you've got fdisk up and running, type the p command to print the partition table for this device. I don't think there's an SD card out there which comes from the store partitioned with more than one partition. If you're looking at a partition table with more than one partition, something is likely very wrong. This will be even more explicit and be presented much more attractively in a partitioning tool like Partition Magic. The main advantage to fdisk is that it is small, fast, and so dangerous that it really focusses the mind.
I think the the mkfs.ext2 command should work to rewrite the file system on the SD card's partition, but if necessary, fdisk can be used to totally delete and recreate the partition --
Hit d for delete.
Hit n for new.
Hit p for primary.
Hit 1 for partition number
Then just accept the defaults for first and last cylinders since we're just creating the one partition.
The next command is really the destructive one:
Hit w to write.
No going back once that's done. No big deal, of course, if you've done it to the SD card, and not something else that used to have data on it. Then add the ext2 file system as above.
Finally, while we're still working on the work station, do a
tune2fs -c 0 /dev/sdb1
(substituting your device, obviously, if not /dev/sdb1). This just keeps the partition checker from running every 32 mounts or so.
Now, on to the XO. Before you do anything, have you got your developer's key? If you're going to be messing around with stuff like this I would recommend it. You may need to boot from an OS on a USB memory stick to recover from a mistake or something. If you haven't, you can start the process by going to browse activity->other link->about your XO link->apply for a developer key link (way at the bottom of the page).
Plug the SD card into the XO. The slot is on the right bottom edge of the screen (you will have to rotate the screen to get at it).
Now open the Terminal Activity and prepare to do some work at the command line.
type su
By default, the XO doesn't have a password on the root account, so just typing su should do it (You may wish to add a password by using the passwd command as root, for example, if you want to be able to connect via ssh from another computer on your network).
Since the XO will mount the SD as soon as it sees it, we can discover what device it is by typing the mount command. Provided you have no USB storage devices plugged in, the SD card should be the last item listed, mounted on some mount point under the /media directory. On my XO the SD card shows up as /dev/mmcblk0p1 and the mount point under /media is some long, meaning less hexadecimal string. I'm going to make a new mount point that's a little easier to work with by typing
mkdir /mnt/newhome
Now I will mount the SD card on this newly created mount point by typing
mount /dev/mmcblk0p1 /mnt/newhome
Now lets change to the /home directory by typing
cd /home
It's rather important for the next step that we be in the /home directory, so lets be extra cautious and confirm by typing
pwd
(that stands for 'present working directory').
Now, to copy the contents of our home directory to the the SD we have mounted on /mnt/newhome, we are going to do a tar copy. For simple copy operations you would normally use the cp command (with the -r tag if copying directories), but I've found when copying entire directory trees with sub-directories and perhaps some symbolic links that a tar copy is more reliable. Type
tar cpf - . | tar xvf - -C /mnt/newhome
(that vertical straight line character (the 'pipe') is produced with a shift+back slash, or is on most keyboards I have seen)
For the curious, what we're doing is on the left side of the pipe tarring up the directory contents and sending them to not to a file but to standard out. On the right side of the pipe tar receives the data on standard in, and copies it to the location we specify with the -C flag. v stands for 'verbose' so we'll get to see it all flash by on the screen as it gets put into place.
When that's done you could double check by listing the contents of the copied olpc home directory:
ls /mnt/newhome/olpc
or to see it all scroll by, try
ls -halR /mnt/newhome/olpc
Now, this whole process is reversible (provided there's enough space on the internal storage to accommodate what you have on the /home directory on the SD), but it can be a pain in the ass, so I wouldn't do this unless you're considering the SD to be more or less a permanent feature now of the XO. That makes sense, because of how the slot is tucked away, and how the USB slots are so much more convenient for removable storage. The XO will not be able to boot into graphical mode for the olpc user if it can't find the olpc user's home directory.
Now we will edit a configuration file so that the SD will get mounted on /home when we reboot. I usually use vi because I'm a terribly butch sysadmin, but for this exercise I will try out the nano editor. vi has a small learning curve that you are unlikely to want to deal with right at this moment. I've never used nano, I just googled for an olpc text editor and that's what came up, so I'm a complete nano n00b. I suspect what I want is
nano /etc/fstab
What comes up looks promising. I'm going to go to the bottom of this file, and add the line
/dev/mmcblk0p1 /home ext2 defaults,noatime 0 0
Breaking that down, what we are telling the XO to do on boot is to mount the SD device on the /home directory. We let it know that the partition is formatted for the ext2 file system, add a couple of options, and a couple of numbers. I have yet to figure out what those numbers mean. How many tabs/spaces to put between the terms doesn't really matter. There will be other entries in the file, so bonus points for neatness and making everything line up in columns.
Now, how do we save in nano... If I go CTRL+x to exit it asks if I want to save changes. I type "y". It asks for the filename, guessing correctly /etc/fstab, so I hit enter, and it closes. Just to be sure, type
cat /etc/fstab
Yup, looks good.
We are going to proceed with an abundance of caution here. Be sure that your SD device name (that's your SD device name, not mine, though they may very well be the same) is spelled correctly in the entry in /etc/fstab. I've seen flawed fstab entries prevent booting, so be sure it is correct. You may want to run the mount command again to confirm.
We are not going to delete the contents of the /home directory just yet. If our /etc/fstab entry is correct, on reboot the SD card will be mounted on the /home directory completely hiding the old contents. In fact, if you don't need to recover the space you might consider not deleting the contents of the /home directory just in case you need it down the road for some reason, probably to do with the loss of the SD card.
Ok, reboot the XO.
In the even of horrible troubles, remember that you should be able to get a command line by hitting CTRL+ALT+the function key with the 3 dots on it and logging in as root. From the command line you can use nano to edit /etc/fstab and put a hash mark (#) in front of the line we added to mount the SD card. Reboot, and because we left the original /home directory alone, you should be back in business, no harm done.
However, mine booted up no problem. Lets open the terminal program again, and check some stuff.
Type
mount
You should see the SD card device mounted on /home. Yup.
Type
df -h
This shows space used by devices. I now have 7 GB of free space in my home directory! Now that's an improvement.
Now I am going to clear out the old /home directory to free up some space. So I will need to stop the SD card from mounting on boot. As mentioned above, what we do is edit /etc/fstab. su , then type
nano /etc/fstab
Scroll down to the line we added, and put a hash mark in front of it, so that it looks something like this.
# /dev/mmcblk0p1 /home ext2 defaults,noatime 0 0
Thus 'commented out', it won't be processed on boot. CTRL+X to exit out, saving on the way as before.
Reboot.
Okay, in the Terminal Activity, type mount and this time we should not see the SD mounted on /home, though we will likely see it mounted on some mount point under the /media directory. This means everything under /home now are the original files, files I want to delete. BUT FIRST, su, and
nano /etc/fstab
REMOVE the hash mark before the line we added to mount the SD card, so once again it appears as:
/dev/mmcblk0p1 /home ext2 defaults,noatime 0 0
For the deleting of the contents of the home directory, I'm going to switch out of the graphical Sugar environment, and to a pure command line one by holding down ALT+CTRL+three dot function key.
Deleting the content of the /home directory might work done from the Terminal Activity, but it just seems wrong, since we su'd to root from olpc whose home we are about to nuke! Whenever nuking someone's home, some distance is wise.
So now I have logged in directly as root in the non-graphical environment, and I issue the command
cat /etc/fstab
because I'm really, really insecure and want to be sure I'll have a home to return to on reboot.
Thus reassured I type:
rm -rf /home/*
Now if we do an
ls /home
We should see nothing. Spooky. I type
reboot
to flee this cold and homeless environment.
It comes back up flawlessly.
Now that I have all this extra space, lets also add a swap file. Grown up Linux distributions typically have a swap partition that can be used by the system as a sort of virtual RAM. According to long time kernel developer Andrew Morton, to the 2.6 series Linux kernel, swap files are just as good as swap partitions ( see http://lkml.org/lkml/2005/7/7/326 ), so lets just wip one up right now with the following commands (in Terminal Activity after su to root):
dd if=/dev/zero of=/home/swapfile bs=1024 count=524288
(this could take some time, we're creating a half GB size file)
mkswap /home/swapfile
(just for fun, type top (q to exit top), see 0 swap reported)
swapon /home/swapfile
(try top again. That's more like it!)
And to make the swap file active on boot, we edit /etc/fstab again (use nano as before), this time adding the line:
/home/swapfile swap swap defaults 0 0
Note, there are those who believe that flash memory can only survive a limited number of writes, and that swap file writing may dramatically reduce the life of the SD card. This could very well be true, so think twice before adding swap, or put it on its own little usb stick, one that contains no data and is cheap enough to replace.