Emulating the XO/Help and tips
More often than not, technology manages to get us 95% of the way... being the last 5% a mix of magical incantations, rituals and other esoteric activities only clear to the initiated. This page tries to take some of the magic away from the sufficiently advanced science.
Please remember to end your comments with ~~~~, which is replaced by a timestamp when you save the page. Without them, notes months old and obsolete look just like notes added yesterday.
Some of the information on this page is obsolete. Some of it only applies to the XO disk images.
How to
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. For example:
sendkey ctrl-alt-f1 # to switch to the shell sendkey ctrl-alt-f7 # to return to Sugar
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.
Get a login prompt
If you started qemu with the -serial `tty` argument, you can simply use that login prompt.
Otherwise, pressing ctrl alt 3 will bring up the console. (But then you can't cut and paste from/to the host machine).
Login as root
#Get a login prompt. The root password on fresh qemu images is empty.
Change the root password
#Login as root. Then:
passwd
Complaints about "BAD" passwords won't stop things from working.
Speed
Does my qemu have kqemu?
Does the version of the QEMU support KQEMU? Type ctrl+alt+2 and type info kqemu. Use ctrl+alt+1 to return to OLPC screen.
On x86_64 you must run qemu-system-x86_64 instead of qemu.
Giving the -kqemu-kernel argument if kqemu is not supported will cause a one-line warning to go by as qemu starts up:
Could not open '/dev/kqemu' - QEMU acceleration layer not activated
kqemu impact
After installing kqemu and modprobe'ing, I get a 3x speedup in booting (to 45 sec), and a 5x in starting the webrowser (to 7 sec). It actually feels usable. MitchellNCharity 17:25, 13 May 2007 (EDT)
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.
More often than not, technology manages to get us 95% of the way... being the last 5% a mix of magical incantations, rituals and other esoteric activities only clear to the initiated. This page tries to take some of the magic away from the sufficiently advanced science
If you want to use nano for system file edits, make sure line wrap is disabled by Alt-L (or look here for it's documentation).
My emulator is very slow
Are you using the kqemu or qvm accelerator modules? You do have to have administrator rights to install the services. QEMU manager (in Windows) knows to start these services according to your profile settings. See Qemu on Windows and QEMU Home Page
Development
Running sugar activities from shell
Running sugar activities from the command-line, instead of via the gui, can be useful when debugging.
Log in as root, then:
su olpc grep export /usr/bin/sugar > /tmp/env source /tmp/env
You can then run activities:
sugar-activity web
Logging boot messages
qemu -serial stdio -hda olpc-redhat-stream-development-ext3.img | tee boot.log
The kernel params in /boot/grup/menu.lst are already set to send to console IO to both the screen and serial ( console=ttyS0,115200 console=tty0), so -serial stdio is all it takes to have it sent to stdout.
Mounting a qemu image (to directly manipulate its filesystem)
You can mount a ext3.img, to directly manipulate its filesystem. Caution: running qemu on it while it's mounted is said to be bad.
file olpc-redhat-stream-development-ext3.img
will say something like
olpc-image/olpc-redhat-stream-development-ext3.img: x86 boot sector; partition 1: ID=0x83, starthead 1, startsector 62, 984994 sectors, extended partition table (last)\011, code offset 0x48
Here the startsector is 62. Multiply it by 512 to get the mount offset (here 62*512=31744).
mkdir tmp_img sudo mount -o loop,offset=31744 olpc-redhat-stream-development-ext3.img tmp_img
Using nano
If you want to use nano for system file edits, make sure line wrap is disabled by Alt-L (or look here for it's documentation).
Network startup
Chances are that the network will not be enabled. Following are two possible ways to enable it.
Network setup
- (This section is linked to from elsewhere, so don't rename it casually.)
- #Change the root password
- As root:
To see the net:
echo ifup eth0 >> /etc/rc.local
To also see other sugar machines:
mv /etc/rc5.d/S98NetworkManager /etc/rc5.d/DISABLED-S98NetworkManager
- Reboot the image. Simply exiting qemu and starting it again is fine.
Congratulations, your network should now be working.
Dealing with NetworkManager
NetworkManager is intended to make wireless networking "just work". As connectivity comes and goes, it notices and sets things up. Unfortunately, it doesn't get along with qemu.
Logged into an image as root, you can see
ifconfig
thinks eth0 is up, as the web browers proves, but NetworkManager's
nm-tool
thinks eth0 is Active: no, and thus that you are disconnected from the net.
The problem is nm expects a modern network interface card which support line/carrier detect. qemu's emulated ne2k_pci, doesn't. I don't know how to fix this.
Fortunately, inside qemu, with our hardwired eth0, we don't care about the functionality nm provides. And also fortunately, sugar has reasonable fallbacks for when it finds nm isn't running.
So if we avoid running nm, everything works.
mv /etc/rc5.d/S98NetworkManager /etc/rc5.d/DISABLED-S98NetworkManager
Enabling the Network Alternative #1
When the emulator is starting GRUB boot loader, press a key.
- Choose then the Qemu line with arrow keys.
- Press E
- Move to the 'Kernel' line and press End
- Add Space 1 to end of the line
- Press Enter
- Press B
You will be automaticaly log in as superuser in terminal (in single user mode).
You can start network and put your local keyboard layout command there like this (using tabulator key to complete the filenames):
echo ifup eth0 >> /etc/rc.local
or
#(change ONBOOT from "no" to "yes") nano /etc/sysconfig/network-scripts/ifcfg-eth0 #(disable NetworkManager) mv /etc/rc5.d/S98NetworkManager /etc/rc5.d/K98NetworkManager
On build 432, the following is also needed to have the network automatically started on bootup:
mv /etc/rc5.d/K90network /etc/rc5.d/S10network
It also helps sugar to find other people automatically upon startup.
Put your own keyboard layout for text terminals
echo loadkeys Your_two_letter_country_code >> /etc/rc.local . /etc/rc.local
Type Ctrl-D to continue normal boot.
Keyboard layout and network should work automatically every time you start the QEMU image. --Tonyv 01:52, 13 January 2007 (EST)
Enabling the Network Alternative #2
Make sure the the window has the focus (label should say QEMU - Press Ctrl-Alt to exit grab). If the following keys do not work try pushing also the Shift key down to exit the Sugar environment. If it does not work see the sendkey method of Alternative #3
- Press Alt + Ctrl + F1 to enter the terminal mode of the OLPC.
- Make sure that you're logged in.
- If not, just hit enter and it'll ask you to.
- Login as root (no password is required)
- Type dhclient and press return.
- Press Alt + Ctrl + F7 to return to the graphical mode of the OLPC.
- Your browser / network connection should be working fine.
Enabling the Network Alternative #3
The steps below work on QEmu regardless of which operating system you are running.
If you are having trouble getting an internet connection inside QEmu:
Get the image running in QEmu so that you can see the normal view with the XO icon in the middle.
Make sure your mouse is active in QEmu, then press ctrl+alt+2 together.
This will bring up a screen like a command line, called the QEmu monitor.
Type the following:
sendkey ctrl-alt-f1
And press return.
Then with the keyboard hold down the following keys: ctrl+alt+7
Another text based screen will appear, asking you to log-in. Sometimes there can be an extra "1" after the word "Login:", just delete it. Type root and press return
Then type:
dhclient
or
ifup eth0:
You should see the screen fill with text.
Some of the numbers have been removed from the screenshot above - they're not important.
Then hold down the following keys on the keyboard: ctrl+alt+2
and type the following:
sendkey ctrl-alt-f7
Justin: Using the latest disk image (Build 385), I found that it was "ctrl-alt-f3" that returned to the Sugar interface.
Then using the keyboard, hold down the following keys: ctrl+alt+1
Now open the browser and you should have internet access.
Networking multple images
This section describes attempts to get multiple qemu images working together.
With:
qemu-system-x86_64 -soundhw es1370 -serial `tty` -hda -kernel-kqemu lap-443a.img -net nic,macaddr=52:54:00:12:34:56 -net socket,listen=:1234 -net user qemu-system-x86_64 -soundhw es1370 -serial `tty` -hda -kernel-kqemu lap-443b.img -net nic,macaddr=52:54:00:12:34:57 -net socket,connect=127.0.0.1:1234
Both can get web pages, and they can ping each other, but they don't show up on each others' Neighborhood view. They attempt contact with olpc.collabora.co.uk, but can't ping it (though my host can - perhaps a firewall issue?). And /home/olpc/.sugar/default/logs/presenceservice.log says
INFO - s-p-s: Starting presence service... STDOUT - ACCT: {'register': True, 'account': '9a7801a0e8a682ea0b39ad263eea9eb20a8d2c29@olpc.collabora.co.uk', 'password':'f607d78534dbf9ebc9c49eaf1966d3e0646b38dc', 'server': 'olpc.collabora.co.uk'} STDOUT - DEBUG - s-p-s.server_plugin: Starting up... DEBUG - s-p-s.server_plugin: ::: No IP4 address, postponing connection
I haven't looked at the rest of the logs yet. MitchellNCharity 23:26, 5 June 2007 (EDT)
Configuration
Altering the desktop resolution
This is said to work on the current LiveCd. It might also work in qemu images? MitchellNCharity 13:50, 5 June 2007 (EDT)
- Somehow pull up a terminal (there is one easily accessible via the classic Gnome desktop)
- Either edit /etc/X11/xorg.conf (example below focusing on the 'Modes' line setting 800x600) OR run system-config-display and select the appropriate resolution from the GUI
- Restart the X server with ctrl-alt-backspace (NOTE: This may take some seconds. It will drop back to a login prompt but if you wait it will start up X again, assuming you provided a valid resolution.)
Section "Screen" Identifier "Screen0" Device "Videocard0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "800x600" EndSubSection EndSection
Configuring X
- In some builds X is configured to load the Geode driver by default. You need to modify it to load the frame buffer driver instead. In /etc/X11/xorg.conf, go to the "Device" section and change the Driver setting from "amd" to "fbdev"
- You can then change XKbLayOut in the same file to your keyboard code with for example nano text editor by
nano /etc/X11/xorg.conf
Setting Framebuffer resolution
NOTE: If you don't set the VGA kernel parameter to 0x317 (in order to get a 1024x768 with 64k colors) you will NOT be able to view / use Etoys properly.
In order to set the framebuffer's VGA kernel parameter you must edit /boot/grub/grub.conf according to the following table:
Colors | 640x480 | 800x600 | 1024x768 | 1280x1024 |
---|---|---|---|---|
256 | 0x301 | 0x303 | 0x305 | 0x307 |
32k | 0x310 | 0x313 | 0x316 | 0x319 |
64k | 0x311 | 0x314 | 0x317 | 0x31A |
16M | 0x312 | 0x315 | 0x318 | 0x31B |
Sound
Latest images add support of sound. Emulation does not work properly with Tam-Tam, yet, even with kqemu at 2 GHz Pentium4 (performance or insufficient emulation issue?). Maybe somebody could install Csound in host and pipe sound over the virtual network? Windows version can be found in Cecilia and Csound for Windows installer --Tonyv
Keyboard and Mouse
A typical case is that their keyboard and mouse don't work. A solution to the problem is:
- Make sure the the window has the focus (label should say QEMU - Press Ctrl-Alt to exit grab).
- Press Alt + Ctrl + 1 (or Alt + Ctrl + 3) to enter the terminal mode of the OLPC. Notice that QEMu seems to respond better to by pushing first down Ctrl, after Alt and finally the number.
- Make sure that you're logged in.
- If not, just hit enter and it'll ask you to.
- Login as root (no password is required)
- Type modprobe i8042 (oddly, you may need to try this multiple times before it works, so keep trying!)
- Press Alt + Ctrl + 7 to return to the graphical mode of the OLPC.
- Your keyboard and mouse should be working fine.
- Usually the result is a continuous series of 1's will flow (as if the key is stuck)
- Just hit any key (to stop it) and delete the offending 1's
Alternatively you can use the developers console and su command. I have not been able to bring up the terminal in most images. Quote from BTest-1_Release_Notes :
The terminal (activity) does not appear on the Frame, but can be launched by typing Alt-Shift-F11. (F11 is found in the 3rd position from the left in the Volume Slider key.) Note that on some newer builds, the terminal window (Memphis) is launched by typing Alt-Shift-F12. In even more recent builds, e.g., Build 224, Memphis is launched by typing Alt-View_Source or Alt-F12.
See also Sugar Instructions:Terminal --Tonyv 01:24, 13 January 2007 (EST)
Problems
On Fedora, "service qemu start" needed?
On fedora linux, to get qemu working, you may have to start the service for it. As root run:
service qemu start
- Why would this be needed?? Emulation works without it. And making .exe files self launching seems unfortunate. MitchellNCharity 21:21, 23 May 2007 (EDT)
On Linux, if qemu complains about insufficient space in /dev/shm
then
mount -t tmpfs -o remount,size=144m none /dev/shm
Boot hangs on Debian-derived distros
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.
We have heard multiple people say that QEMU doesn't work with these images on the debian-derived distributions. We also haven't heard of any solutions to these problems. The symptom is that the kernel hangs during boot.
Marcin: On Ubuntu Dapper it hangs with qemu 0.8.0 (from distro), but works with 0.8.1 from i386 binary tarball.
Budgester (I can confirm this situation on Ubuntu Dapper)
Vedran: It also hangs on Debian unstable with qemu 0.8.1-1 (from distro), but works with 0.8.1 from i386 binary tarball.
kevin.mark@verizon.net: It also hangs on Debian unstable with bochs 2.2.6-2 (from distro) the same way it does for qemu as noted above
MikeX: qemu 0.8.1-1 packaged for debian sid amd64 seems to work for me (system boots but sugar hangs, tried with build84).
[1]: It works on Debian Etch with qemu 0.8.2-4 (a little slow but works ok).
Spawn968: Hangs using qemu 0.8.2 with kqemu-1.3.0pre9, but runs fine on qemu 0.8.2 in Ubuntu Dapper.
dilinger: This is not actually a qemu issue; it's a bochsbios issue. Bochsbios 2.2 is broken in this regard; bochsbios 2.3 might work (an sti was added). A quick fix for allowing it to boot is to add 'apm=off' as a kernel argument. Debian bug #363047 has additional details.
Jwaddell:: Thanks Marcin...getting the 0.8.2 binary tarball from the link you provided made the image work under Ubuntu Dapper for me ;)
Tomhannen:: Please could some of you document your successes/failures on this page?
lealcy:: OLPC image doesn't work with Qemu 0.8.2 on Ubuntu 6.10 (Edgy Eft). It freeze in startup process. Check this shot:
http://wiki.laptop.org/go/Image:OLPC-qemu0.8.2-ubuntu6.10.png
Update: With the qemu 0.8.2 downloaded from http://fabrice.bellard.free.fr/qemu/download.html (the binaries) 1b2 loaded to the graphic interface, but I feel the interface a bit unresponsible (maybe an issue by emulation.) Thanks to Fernando <fernandogrd@yahoo.com.br> by the Qemu 0.8.2 Ubuntu issue tip.
SandwichButton:: lealcy, try entering the apm=off kernel argument. You need to enter the grub menu, edit the 'for qemu target' option by highlighting it and pressing e. The second line is the kernel arguments you pass at boot time. enter 'apm=off' without the single quotes at the end of the line, hit enter, then press b. It was previously freezing while mounting hda. My machine runs qemu 8.2, edgy 6.10 (w/ updates), and build 185 just fine now.