OS images for emulation

Basic emulation options are listed here. For Windows emulation, see Using QEMU on Windows XP.

You can find the latest stable build here.

One way to run oplc software is using an emulator on your pc. See Software for other options. Compared to using a LiveCd, it might be harder to set up, but easier to development on. Compared to installing sugar, easier, but harder.

OLPC OS performance under emulation

Running OLPC in emulation is generally much slower than on the laptop.

But if you use qemu for emulation, and have an x86-like cpu, and use qemu's kqemu backend rather than the default one (several 100% speedup), performance is quite usable.

User Feedback on Images may be helpful in judging particular image/emulator/operating-system/cpu combinations.

If you have severe performance problems, so poor activities fail to load, you might look at Coping with Slowness, But in this case you might be better off using a Live CD.

QEMU

The easiest way to test the images is to use qemu or some similar emulator. It is available for various host systems:

• Linux
• FreeBSD
• Windows
• Mac OS X

QEMU on Linux

On Fedora Core 5, QEMU is included in extras and is very easy to install. As root just type

yum install qemu

and it should be installed. You may have to start the service for it. As root run:

service qemu start

On Debian/Ubuntu, QEMU is included in the repository.

apt-get install qemu

Once you have an image downloaded, it is very easy to use qemu to launch the OLPC environment:

qemu -soundhw es1370 -serial `tty` -hda \
  olpc-stream-development-7-20060609_1600-ext3.img

If qemu complains about insufficient space in /dev/shm then

mount -t tmpfs -o remount,size=144m none /dev/shm

If you want to use kqemu to speed up the emulation (on x86 and related cpus) then

modprobe kqemu major=0

and add the -kernel-kqemu option. See Using QEMU for Troubleshooting for tips.

We have heard multiple people say that QEMU doesn't work with these images on the debian-derived distributions. The symptom is that the kernel hangs during boot. There's a problem with bochsbios version 2.2, version 2.3 works. As a quick fix, apm=off can be added to OLPC kernel arguments. (For more info, see the discussion.)

If you have network problems through Qemu and OLPC, try this.

QEMU Development Strategies

For those who would like to use QEMU for developing Python software (Sugar software) for the OLPC, it's convenient to set up a connection between the host and the Laptop image. Under QEMU the Laptop image can see the host as IP address 10.0.2.2 . If you create an SSH server on your host and install a key on your Laptop image that has logon rights for that server, you can ssh from the OLPC to your host.

QEMU on FreeBSD

Install qemu from ports:

cd /usr/ports/emulators/qemu && make install clean

or as a package

pkg_add -r qemu

Once installed, load kqemu and aio kernel modules:

kldload kqemu
kldload aio

and launch the image you want:

qemu -hda olpc-stream-development-7-20060609_1600-ext3.img

QEMU on Windows

See Using QEMU on Windows XP

QEMU on Mac OS X

Bert: I successfully ran OLPC on OS X using the following method on a Powerbook G4 (867 MHz), albeit very slowly.

Justin: Likewise, I successfully ran the latest disk image (Build 385) through QEMU on OS X (10.4) on and Intel Apple using the instructions below.

• Download and install Q.app (kju-app.org , I got 0.8.1a35, the builds are here: kberg.ch/q/builds/ (previous link broken / server down))
• Download a disk image (build 59 worked, 73 did not), double-click to unzip. (Note: See point (1) in Section "Enabling SSH" below before choosing an image.)
• Double-click Q.app Example
• Click (+) to add a new PC Example
  • Name: OLPC
  • Operating System: Q Standard Guest
  • Click (Create PC)
• Configure Settings:
  • General: No file sharing Example
  • Hardware - Hard disk: Select your unzipped disk image Example
  • Advanced - QEMU Arguments: type "-redir tcp:2222::22" (without quotes) Example
  • Click (Create PC)
• Double-click "OLPC" to run:
  • press space to get into GRUB, Example
  • choose "OLPC for Qemu Target", Example
  • press "e" to edit commands,
  • select "kernel" line, and press "e", Example
  • add "single" option at the end of the line, Example
  • hit return, then "b" to boot
  • set some root password (necessary for SSH), sync (Note: See point (2) in Section "Enabling SSH" below)
  • reboot (power-off button or run "init 6")
• once it's up, from a terminal, log into OLPC using "ssh -p 2222 root@localhost" (Note: See point (3) in Section "Enabling SSH" below)

Jonb: I had trouble running this using Q.app. I guess Q.app doesn't have USB 1.1 support for "real" USB devices yet http://www.kju-app.org/proj/wiki/KjuUSBSupport. Their documentation says something about using the USB Tablet to emulate the mouse, no idea what this is about. The result is that I do not get a keyboard in OLPC on my G4 Mac (USB Keyboard, obviously). I assume User:bert got it to work using his PowerBook because PCMCIA emulation works?

Shekay: I was able to run Q.app from the command line. for example:

$ /Applications/Q.app/Contents/MacOS/i386-softmmu.app/Contents/MacOS/i386-softmmu -hda olpc/olpc-redhat-stream-development-devel_ext3.img -serial stdio

Sending Ctrl-Alt combos in Qemu (or Q.app)

According to Sugar Instructions you need to "hold down Ctrl+Alt+F1 to leave the Sugar screen and return to the login prompt" and then "you can return to Sugar with Ctrl+Alt+F7". Unfortunately for me the "Ctrl+Alt" action seems to be grabbed by the Q.app "mouse pointer ungrab" functionality.

Under Linux, this will be grabbed by the X server running on your computer, and not the one running in the emulator, and will switch your own computer to a terminal.

The other method(s) suggested for opening a terminal activity didn't work for me either (OLPC build 239). I eventually discovered that Q.app actually has a "Monitor" accessible by "ctrl-alt-2". When in this monitor mode you can send key-presses directly to the OLPC emulation by using the "sendkey" command.

e.g. to switch to the shell:

  sendkey ctrl-alt-f1

to return to Sugar:

  sendkey ctrl-alt-f7

Note: you will need to exit the monitor mode and return to the emulated machine by pressing "ctrl-alt-1" once you type either of the above commands.

Note: you type the name of the keys to send, you don't actually press the keys.

Enabling SSH

Follower needed to perform the following additional steps to successfully enable the use of SSH (with build 239):

1. Ensure you have a "*-devel*.img" image, as the standard (non-devel) images appear to not include sshd.
2. At the same time as enabling the root password you will probably also want to enable the network to start automatically. I followed the instructions from Alternative #1 here.
3. To avoid a "man in the middle attack" warning you might want to use:

ssh -o NoHostAuthenticationForLocalhost=yes -p 2222 root@localhost

VMware Player

Linux / Windows

Warning

For easy-to-use operation, you probably want to use Qemu, which is known to work on all of Linux, Win32 and Mac. Most recent builds do not support VMWare due to the lack of a pcnet32 network driver. See [[1]]. There are Developer Images available which are built on top of regular desktop environments and provide basically all drivers as well as a reasonable development environment, but in a much larger download (900MB+).

VMware Player is another convenient way to test the image on your Linux / Windows machine. You can convert an image to a VMware virtual disk file with the qemu-img command from the QEMU distribution.

$ qemu-img convert olpc-stream-development-59-20060808_1153-rpm-ext3.img  -O vmdk olpc.vmdk

Additionally, you need a config file to run the virtual disk. Here is an example (save it as olpc.vmx).

#!/usr/bin/vmware
config.version = "8"
virtualHW.version = "3"
memsize = "128"
ide0:0.present = "TRUE"
ide0:0.fileName = "olpc.vmdk"
ide1:0.present = "TRUE"
ide1:0.fileName = "/dev/cdrom"
ide1:0.deviceType = "atapi-cdrom"
floppy0.fileName = "A:"
ethernet0.present = "TRUE"
ethernet0.connectionType = "nat"
usb.present = "TRUE"
sound.present = "TRUE"
sound.virtualDev = "es1371"
displayName = "OLPC"
guestOS = "other26xlinux"

ethernet0.addressType = "generated"
uuid.location = "56 4d d1 99 5c 64 a3 6f-ef c7 aa 86 a8 cc ed 46"
uuid.bios = "56 4d d1 99 5c 64 a3 6f-ef c7 aa 86 a8 cc ed 46"
tools.remindInstall = "TRUE"
ethernet0.generatedAddress = "00:0c:29:cc:ed:46"
ethernet0.generatedAddressOffset = "0"

checkpoint.vmState = "olpc.vmss"

ide0:0.redo = ""

Start VMWare Player, open this .vmx file. Allow VMWare to create a new UUID.

Note: Make sure the emulator starts the 'OLPC for qemu target'.

Mac OSX

• Unzip the package and double click OLPC.VDMK

• More at http://www.edgargonzalez.com/2006/11/21/emulating-the-olpc-xo-on-a-mac-osx/

This package seems to be gone. Suggestions?

• It should worked with the livecd sdk. Download it from the downloads section. No need for the OLPC.VDMK if you run the livecd.

Windows

• Tuttle on VMWare on Windows

Parallels Desktop on Mac OS X

Bert: First, install a regular Linux in Parallels - I used Fedora Core 5. To use an OS image directly, add a second hard disk (size 512 MB) to the VM. Boot the VM, download an OS image (ending in ext3.img.bz2), then copy it to the second hard disk (hdc for me, hdb is the CD):

bzcat ...ext3.img.bz2 | dd of=/dev/hdc bs=1M
sync

Then shut down that Linux, and change the VM (or make another one) to boot from the second hard disk image. Start that VM - should work :) I have not yet made sound work, though, please let me know if you find out anything.

BruceB: It can be a bit easier than that, no need to load a Linux system if you don't already happen to have one. This worked for me, though it may be simplified further still.

• Launch Parallels, create a new VM (I user "other Linux"
• Set the hard drive to be 512MB, OK when it says it already exists.
• Note the Hard drive file name, for me it was:

 /Users/bruce/Library/Parallels/otherlin/otherlin.hdd

• Download the image (as bert says, ending in ext3.img.bz2) from this page:

 http://olpc.download.redhat.com/olpc/streams/development/latest/devel_ext3/

• Drop into the Apple Terminal and type: (replacing "..." with the right file name you downloaded and your username. Check to see if "otherlin.hdd" is what you are using too.)

 bzcat ~/Desktop/olpc...ext3.img.bz2 | dd of=/Users/.../Library/Parallels/otherlin/otherlin.hdd

• Re-launch Parallels and run!

Bert: Oh, so Parallel's hdd is nothing more than a plain disk image? How interesting! Thanks, that's a lot easier!

Wooky: The dd-ing worked allright under OS X, but with a caveat: both images I tried (206 and 193) were only 480MB after dd, even though they originally had 512MB. I used Parallel's image utility to resize them back to 512MB and all went fine (almost, couldn't start GUI. Guess it is something between fbdev and Parallel's video).

MartinDolphin: I managed to get this working following the shorter method suggested by BruceB - the OLPC software starts with the initial screen, I can enter my name, but can't get any further.

George: I have the same problem with MartinDolphin

ScottSwanson: To avoid the 480MB "autoshrink" when running dd in Terminal.app, try using the following (remember to explicitly enter the correct paths for your system instead of "..."):

 bzcat ...ext3.img.bz2 | dd of=...otherlin.hdd bs=1024 conv=notrunc,noerror,sync

I was informed on #Sugar that there was a known issue with the file selection dialog box where you had to type in the filename with full path by hand. The newest build (298 as I write this) obviates this need. (This addresses MartinDolphin and George's issue.)

StarKruzr: I get so far as the Sugar splash screen. Never get to type in a name, it crashes shortly after telling Grub to boot from the QEMU target.

SRiggins: Parallels Build 3188 now stores vm hard disk images in /Users/{USERNAME}/Documents/Parallels/{VMNAME}/

Virtual PC on Mac OS X (PowerPC)

Akauppi: The instructions above on preparing a 512MB boot disk, based on ...img.bz2 file apply. However, create a 1GB disk image in VPC, since it does not allow precisely 512MB.

TODO: system boots nicely, but the mouse remains unresponsive. Ideas???

John Palmieri advised:

Add this to /etc/X11/qemu-Xorg.conf and then copy qemu-Xorg.conf to Xorg.conf:

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "yes"
EndSection

Startup Failure

VirtualPC 7.0.1 (041022) on a Quad G5 (PowerMac11,2) fails to boot from the LiveCD, neither as disk or from image. The following output post-bootloader was copied verbatim from the (virtual) screen:

  Booting 'OLPC Operating System SDK'

root (cd)
 Filesystem type is iso9660, using whole disk
kernel /boot/vmlinuz ro quiet root=CDLABEL=OLPCRoot_build385_CD rootfstype=iso9
660 fastboot livecd selinux=0
   [Linux-bzImage, setup=0x1e00, size=0x1e2474]
initrd /boot/initrd
   [Linux-initrd @ 0x1fd37000, 0x2a888d bytes]

Uncompressing Linux... Ok, booting the kernel.














Int 14: CR2 ffffbe47  err 00000002  EIP c0427b06  CS 00000060  flags 00000047
Stack: c0745fdc 00000000 00000000 00000000 00000000 00000000 00000000 00000000

▪ NeoAmsterdam^Talk_Edits 23:07, 18 May 2007 (EDT)

Instructions

See Sugar Instructions.

Limitations

The XO system is designed specifically to run on 'foo'. Some of the components are unlike any off the shelf product (example, the camera) so you won't be able to get 100% emulation of the OLPC. See Emulation Limitations for details .

Coping with Slowness

It is possible for the OLPC image to boot successfully and load the Sugar UI in the emulator but then be too slow to successfully load any activities.

For example, between build 239 and build 303 activity loading slowed enough for me (Qemu / 1.6GHz G4 PPC / OS X) that no activities loaded successfully. Symptons include messages in /home/olpc/.sugar/default/logs/shell.log like this:

DEBUG - Shell.start_activity
DEBUG - Activity f4a9f5322b49dcc3364a4eca9b13633c0ce1868e (org.laptop.ChatActivity) launching...
DEBUG - Activity f4a9f5322b49dcc3364a4eca9b13633c0ce1868e (org.laptop.ChatActivity) launch timed out
STDERR - Introspect error: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

DEBUG - Couldn't create activity f4a9f5322b49dcc3364a4eca9b13633c0ce1868e (org.laptop.ChatActivity): Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
ERROR - Model for activity id f4a9f5322b49dcc3364a4eca9b13633c0ce1868e does not exist.
DEBUG - Activity f4a9f5322b49dcc3364a4eca9b13633c0ce1868e (org.laptop.ChatActivity) launching...
DEBUG - Activity f4a9f5322b49dcc3364a4eca9b13633c0ce1868e (org.laptop.ChatActivity) finished launching

Another sympton is the flashing activity load icon appearing in the donut for a length of time and then disappearing without the activity loading. (Although this can also be caused by other issues such as uncaught programming errors.)

These failures are due to two timeouts values configured in the system, one in Sugar and one in D-Bus. If you're more patient than OLPC/Sugar is by default then it's possible to tweak these values to enable activities to eventually load:

D-Bus

Insert the following line in /etc/dbus-1/session.conf below the </policy> tag:

  <limit name="service_start_timeout">120000</limit>

This means D-Bus will wait 120 seconds before giving up--the icon will still disappear from the donut but eventually the activity will load. (Strictly speaking this setting might really need to be in session-local.conf. See man dbus-daemon.)

Sugar

To ensure the flashing activity load icon appears in the donut longer the following untested change should work:

In shell/model/homeactivity.py replace:

self._launch_timeout_id = gobject.timeout_add(20000, self._launch_timeout_cb)

with (for example) this:

self._launch_timeout_id = gobject.timeout_add(120000, self._launch_timeout_cb)

As far as I can tell this only has a cosmetic impact and activities should still load without it.