OS images for emulation
| english | español | Copy "{{subst:requesttranslation}}" to 日本語 | Copy "{{subst:requesttranslation}}" to 한국어 | Copy "{{subst:requesttranslation}}" to português | Copy "{{subst:requesttranslation}}" to русский | HowTo [ID# 38838] +/- |
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.
Contents
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:
QEMU Development Strategies
If you wish to develop software on an emulated image, you will usually want a connection between your host and the laptop image.
You need a "*-devel*.img" image, rather than a standard (non-devel) one. The -devel image has extra software like sshd and wget.
Get network working on the laptop. See Using QEMU for Troubleshooting#Network. A simple echo ifup eth0 >> /etc/rc.local , run as root on the laptop, should do it. You should now be able to surf with the laptop's web activity. Under QEMU the Laptop image can see the host as IP address 10.0.2.2 .
Next, you have several alternatives:
- SSH using qemu -redir tcp:2222::22. (a good first approach)
- First-time setup
- Get the image's network working.
- Change the image's root password.
- Log into the image as root (no password needed yet!), type passwd , and then give it one. Complaints about "BAD" passwords won't stop things from working.
- Logging in as root is easy in qemu - you have a console window. Elsewhere...(? someone else will need to fill this in)
- Whenever you run qemu, add the argument -redir tcp:2222::22
- You can now log into the laptop image, from your real machine, using ssh. And you can use scp, etc.
- First-time setup
ssh -p 2222 root@localhost # simple ssh -o NoHostAuthenticationForLocalhost=yes -p 2222 root@localhost #avoids annoying warning
- SSH using a key. (if ssh passwords get annoying, you can try this)
- 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. This avoids password typing.
- Adding platform-specific instructions might be useful? MitchellNCharity 15:59, 21 May 2007 (EDT)
- Using a web server. (if you don't want to deal with ssh, and have a webserver)
- If you have a web server, you might simply download stuff onto the laptop using the laptops's web browser.
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 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
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:
- 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.
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
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
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
▪ NeoAmsterdamTalkEdits 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.
