Emulating the XO
Contents
Simulating an XO
Emulators allow you to run a "virtual machine" on a (reasonably powerful) host machine. There are a number of emulator systems available which can be used to run a simulated OLPC-XO. The three listed here provide either Open Source or Gratis players to run images:
As of official build 557, VirtualBox and VMWare are both able to load converted images with networking support. VirtualBox also provides sound support. At the moment, these converted images are the recommended practice for simulating an XO, both for testing out the environment and developing activities.
As of the same date, Qemu is able to run the official images, but networking must be restarted (/etc/init.d/network restart) from the developer's console to have any networking support. Sound doesn't yet appear to be working.
Simulating a Developer's Desktop
Most core developers use Fedora 7 or Ubuntu Feisty desktops which are running sugar-jhbuild to track the latest developments in the code-base. This allows you to integrate into the core development process, but can be a considerable maintenance headache due to the fragile nature of the build process.
You can readily run a simulated Fedora/Ubuntu desktop in VMWare. This setup is not substantially different from running a regular Linux desktop using sugar-jhbuild.
Note: This approach is really only recommended for those who want to work on core components of the environment, activity developers are probably better off using an official image.
Note: Previously we have attempted to provide LiveCD and Developer Images for download. Manpower issues have meant that these images have fallen far behind the official images, thus they are no longer a recommended approach for developers. If you are interested in volunteering to maintain the LiveCD or Developer Images, please contact Mike Fletcher.
Comparison of alternatives
An OLPC laptop is custom hardware, running a stripped-down Red Hat linux, running Sugar. But what if you don't have a real olpc laptop? There are a several options, which can each be used in a couple of ways.
| platform | purpose | recommendation |
|---|---|---|
| Ubuntu | play & development | xo disk images on qemu. See Emulating the XO/Quick Start. |
| Ubuntu 32-bit | core development | Sugar with sugar-jhbuild and Sugar on Ubuntu Linux |
| Fedora | play & development | xo disk images on qemu. See Emulating the XO/Quick Start. Perhaps also on VirtualBox? |
| Fedora 32-bit | core development | Sugar with sugar-jhbuild |
| Linux & FreeBSD | play & development | xo disk images on qemu. See Emulating the XO/Quick Start. Perhaps also on VirtualBox? |
| Windows | play & development | emulated xo disk image, on VirtualBox, VMWare, or QEMU on Windows. |
| Mac | play & development | emulated xo disk image, on qemu. See Emulating the XO/Quick Start/Mac. Perhaps also VirtualBox and VMWare? See also /Mac. |
| Mac with Parallels | play | No reports of emulated xo disk image on Parallels. Reports encouraged. |
| Mac with Parallels | core development | install Ubuntu 32-bit, and Sugar on Ubuntu Linux. See /Mac. |
Build recommendations
For running XO disk images on an emulator, some builds are better than others, and the most recent one will not always work. Here is a summary of current status. Please add your own experiences here, and in User Feedback on Images.
505 is the most recent build known to work in qemu. Builds after 541 run, but collaboration is broken (you can't see other laptops).
Many builds between 541 and 505, including 531, 529, and 525, didn't boot. However, some of the later 50x may work.
- Actually build 542, the Trial 2 build, introduced a "feature": the configuration is no longer hardcoded to use the server olpc.collabora.co.uk, and has no server prepopulated. You can set the server yourself by editing ~olpc/.sugar/default/config and setting server = olpc.collabora.co.uk and restarting. This should mean that 542 is the preferred image for developing with, since 505 and other 50x are quite old. --morgs 03:54, 21 August 2007 (EDT)
- I've added seting the server to the instructions below. Thanks! :) But for now, we're still stuck at 505, because the workaround for #1977 stopped working. MitchellNCharity 23:25, 22 August 2007 (EDT)
- #1977 is now marked fixed. Hopefully once #2981 is fixed, emulation of current builds will again work. MitchellNCharity 10:33, 24 August 2007 (EDT)
- #2981 is now marked fixed. If qemu is run with -net nic,model=rtl8139, then NetworkManager no longer needs to be disabled (build 564). Presence services still doesn't seem to work (neither jabber.laptop.org, nor olpc.collabora.co.uk (registered False or True)). Cause unknown. MitchellNCharity 00:39, 2 September 2007 (EDT)
- Observations: 557 and 564 seem to behave similarly. wget http://SOME-IP-ADDRESS/ fails (Connecting to SOME-IP-ADDRESS... failed: Network is unreachable.). ifup eth0 fails (Determining IP information for eth0... failed.). nm-tool reports Gateway: 0.0.0.0 Primary DNS: 0.0.0.0 Secondary DNS: 0.0.0.0. Hmm, how does one /sbin/route add -net 0.0.0.0 gw 10.0.2.2 eth0[1] on an xo? MitchellNCharity 01:45, 2 September 2007 (EDT)
Build 557 is reported to work on VirtualBox and VMWare, but not qemu. MitchellNCharity 22:52, 19 September 2007 (EDT)
- Builds 578, 579, 581 are known to not boot #3470 (578, 579 in VMWare, 581 in QEMU). MitchellNCharity 13:55, 15 September 2007 (EDT)
Overview
- This is the old introduction section. It needs to be updated. Eg, the LiveCd is currently not a useful alternative. And "just use the latest build" isn't good advice, as a more selective approach has been needed. MitchellNCharity 23:36, 19 September 2007 (EDT)
One way to run oplc software is using an emulator on your pc. See Getting started programming for other options.
Note Category:Emulation and Help and tips.
For play, you can use LiveCd or Quick Start.
For development, you can use LiveCd, or qemu (as in quick start, but with a different image), or perhaps one of the Developer Images other than the LiveCd. An alternate approach is to attempt installing sugar. See Getting started programming for a comparison.
A common development approach is to use QEMU with kqemu acceleration. See Quick Start for the basics. Though for development, we will use a different .img, one with a few extra utility programs. See OS images, including latest stable build.
Instead of qemu, you can run VMware, and there are additional options on a Mac.
Please report your experiences in User Feedback on Images. There is a Virtualization Common Room.
There are limitations with XO disk images.
The LATEST-STABLE-BUILD versus LATEST build distinction is mostly of interest to people running on actual XO's. In emulation, developers should usually use LATEST. And when STABLE is old, non-developers probably should too.
Example step-by-step instructions
Here, in one place, are assembled all the steps to get you to a working emulated XO. Assuming you are running on linux, and have already installed qemu and kqemu.
The following will not work on your virtual xo: sound, camera. The first because no one has gotten around to figuring out why it isn't working[2]. The second because qemu doesn't yet support them.
Go to http://olpc.download.redhat.com/olpc/streams/development/LATEST/devel_ext3/ and obtain the numbered -devel_ext3.img.bz2 and its md5. For this example I used build 485.
md5sum -c olpc-redhat-stream-development-build-485-20070703_0249-devel_ext3.img.bz2.md5 bzcat olpc-redhat-stream-development-build-485-20070703_0249-devel_ext3.img.bz2 > xo-485a.img
The resulting file is 1 GB.
export PORT=2221 qemu-system-x86_64 -soundhw es1370 -serial `tty` -kernel-kqemu -redir tcp:$PORT::22 -hda xo-485a.img
Unless you have a x86_64 cpu, use qemu instead of qemu-system-x86_64.
The screen will very briefly be black, and then show the blue "GNU GRUB" screen. If it stays black, that's a qemu bug. Kill qemu and try again.
The boot messages will scroll by, and you should eventually see the normal XO first-time login. We'll save that for later.
In the window where you started qemu, you should now see a login: prompt.
- Enter root
- Then:
/etc/rc5.d/S98NetworkManager stop
mv /etc/rc3.d/S98NetworkManager /etc/rc3.d/DISABLED-S98NetworkManager
mv /etc/rc5.d/S98NetworkManager /etc/rc5.d/DISABLED-S98NetworkManager
echo ifup eth0 >> /etc/rc.local
cp -p /home/olpc/.sugar/default/config /home/olpc/.sugar/default/config.old
gawk '/^server/ {print "server = olpc.collabora.co.uk"} !/^server/ {print}' /home/olpc/.sugar/default/config.old > /home/olpc/.sugar/default/config
ifup eth0
killall X
Killing X should restart sugar.
If you want to enter a name with diacritics, you need to wait for X to restart, and then do:
su olpc -c"DISPLAY=:0 xmodmap -e 'keycode 77 = Multi_key'"
This sets up Num_lock as Multi_key. Unfortunately, the next time X is restarted, you will lose it. A better solution is needed.
At this point you could just proceed to use your new XO. However, the screen resolution is wrong (1024x768). So for development, or to get a more accurate feel for how things really look, some extra steps are required.
Once you reach the main sugar screen, you should check the Neighborhood view (F1). If you can't see other people, either the we are having problems with the presence server, you are behind an unusually picky firewall, or networking on qemu is broken again in the build number you are using. (Remember that ping doesn't work inside of qemu).
While this next step is not strictly required, it will enable you to use ssh and scp, which can be handy to move stuff back and forth between your host and xo.
Still as root on the xo,
1. Change the root password.
passwd
Don't worry if it says something like "BAD PASSWORD: ", and complains about the password you picked. It will still work.
2. Change the olpc password.
passwd olpc
Now you can use ssh and scp.
The current released version of QEMU doesn't support 1200x900, so we use a Xephyr remote X server. Each time you boot the xo, if you want 1200x900, you'll need to do these next steps again, except for the ones marked "(First time only)".
1. Still as root on the xo:
init 3 sleep 5 ifup eth0 su olpc grep export /usr/bin/sugar > ~/env source ~/env
If the ifup eth0 fails with an "already running" message, that's ok. Perhaps it is no longer needed.
2. Back on the host, prepare Xephyr (First time only)
mcookie > xephyr-cookie export COOKIE=`cat xephyr-cookie` rm -f xephyr-xauth; echo "add :1 . $COOKIE" | xauth -f xephyr-xauth echo $COOKIE
3. On the xo, still as "su olpc", record the cookie: (First time only)
echo "add 10.0.2.2:1 . " PUT-THE-COOKIE-HERE | xauth
4. Back on the host, start a Xephyr:
Xephyr :1 -auth xephyr-xauth -reset -screen 1200x900x16 -dpi 200
You will probably want to do this in its own window, as it periodically dies and needs to be restarted.
5. On the xo, still as "su olpc", start sugar:
DISPLAY=10.0.2.2:1 sugar
Actually, I usually ssh in from the host, and run sugar that way:
a. On the host,
ssh -o NoHostAuthenticationForLocalhost=yes -p 2222 olpc@localhost
b. in the resulting shell,
source ~/env export DISPLAY=10.0.2.2:1 sugar
You may also want to run
xmodmap -e 'keycode 77 = Multi_key'
to be able to enter diacritics with the Num_lock key. But I find doing it first thing tends to kill Xephyr. :(
You should now see the XO first-login screen in correct resolution. You can use Num_lock to enter diacritics. Congratulations. Sorry it was so much bother.
To run multiple xo's (to play with collaboration, for instance), you
can repeat the above steps. Create a xo-485b.img, and use a different
PORT number (like 2222). If you are using Xephyr, start a second
Xephyr, which will be 10.0.2.2:2, use that instead of ...:1 in
the instructions. You should now be able to see yourself, and
collaborate in Write.
The following will save you having to periodically type your xo password, but is optional, and can just as easily be done later.
Back on the host,
1. Create an ssh key if you don't already have one. See /Help_and_tips#SSH into qemu, using a key.
2. Copy it to the xo,
scp -o NoHostAuthenticationForLocalhost=yes -P $PORT ~/.ssh/id_rsa.pub root@localhost:~/
3. On the xo, as root, spread the key around:
mkdir ~root/.ssh mkdir ~olpc/.ssh cat ~root/id_rsa.pub >> ~root/.ssh/authorized_keys cat ~root/id_rsa.pub >> ~olpc/.ssh/authorized_keys
You can now ssh and scp without retyping your password.
Links
- Tutorial Written by IBM on how to get this working.
