Talk:Emulating the XO

Article TODO

The top of the article should:

• be more specific about ease of installation. Eg, if kqemu is easily installed on Ubuntu (unlike fc6), then it might be easier than the LiveCd.
• mention hardware support. Once it becomes clear whether the LiveCd actually supports camera, it should be mentioned.

Does TamTam sound work under qemu in the release we recommend? (It hasn't lately in latest-release). Should test, and mention if it doesn't. MitchellNCharity 13:14, 5 June 2007 (EDT)

Xen Player

Is anybody doing such an emulation? Nitpicker 21:59, 5 October 2006 (EDT)

Moved from abandoned Talk:OS_images_for_emulation. MitchellNCharity 03:04, 24 May 2007 (EDT)

Temporary summary of current state

currently: quickstart is a "choice of livecd/sound/no-library/read-only or qemu/non-devel.img/no-sound/library/read-write". and devel is "mix of qemu/livecd.iso/sound/ro and qemu/-devel.img/no-sound/rw". MitchellNCharity 13:06, 24 May 2007 (EDT)

Modifying the LiveCD .iso - adding the olpc Library

The LiveCd is intended for development, and thus doesn't include the Library sample content. One wants the library when demo'ing sugar. Here is how to add it.

The next release (June?) of the LiveCd will have google as the default browser page (rather than an error message). Making adding the Library less important. A nice, simple fix. MitchellNCharity 13:03, 5 June 2007 (EDT)

The LiveCD is currently created manually every month or two.

Getting /home/olpc/Libary

Alternatives:

• Snarf a copy from an xo disk image (the ext3.img variety).

mkdir tmp_img
mount -o loop,offset=33174 olpc-redhat-stream-development-ext3.img tmp_img

The Libary is in tmp_img/home/olpc/Library. The offset=NNNNN may need to be adjusted. See Emulating the XO/Help and tips.

• As of 2006-06-01, there is a snapshot:

wget http://dev.laptop.org/pub/content/lib-4-6.tar.gz

Get squashfs

Get squashfs. On fc6,

yum install squashfs-tools

Add the library

wget http://olpc.download.redhat.com/olpc/streams/sdk/latest/livecd/olpc-redhat-stream-sdk-livecd.iso

As root

mkdir tmp_iso
mount -o loop -t iso9660 olpc-redhat-stream-sdk-livecd.iso tmp_iso
/usr/sbin/unsquashfs -dest tmp_squashfs tmp_iso/squashfs.img  # about 4GB

file tmp_squashfs/os.img
## tmp_squashfs/os.img: x86 boot sector; partition 1: ID=0x83, starthead 1, startsector 62, 8388290 sectors, extended partition table (last)\011
## 62 * 512 = 31744
mkdir tmp_os
mount -o loop,offset=31744 -t ext3 tmp_squashfs/os.img tmp_os

mkdir tmp_os/home/olpc/Library
(cd dev.laptop.org/pub/content/library/; tar cf - .)|(cd tmp_os/home/olpc/Library; tar xf -)
chown -R 500:500 tmp_os/home/olpc/Library

umount tmp_os
/sbin/mksquashfs tmp_squashfs squashfs.img.new

mkdir tmp_iso2
(cd tmp_iso; tar cf - .)|(cd tmp_iso2; tar xpf -)
umount tmp_iso
mkisofs -v -r -T -J -V 'Modified LiveCd mumble' -l -R -c boot.catalog -b squashfs.img -o new.iso tmp_iso2  ##XXX - wrong - doesn't work

Notes:

• Unfinished.
• Could be cleaned up. And parts copied out into Help_and_tips.
• http://git.fedoraproject.org/?p=pilgrim/.git;a=summary
• http://git.fedoraproject.org/?p=hosted/livecd

Future possibilities

It would be nice to have:

• LiveCd with Library. To be an "intro" livecd for non-developers to try sugar.
  • Perhaps create a mutant LiveCd. Take LiveCd, unsquash its squashfs, add library, resquash, and mkisofs. Downsides: LiveCd isn't updated very frequently (but since an update is coming rsn, perhaps we don't care just now). See Talk:Emulating_the_XO.
• a small(?) qemu image with full fedora host detection/configuration (like Big FC6 Build). To be an "intro" qemu image for non-developers. A "virtual XO".
  • Perhaps derive from LiveCd? The bottleneck is getting a clean sugar-jhbuild. LiveCd is the only production source of this human intensive process, other than the latest-stable-builds, which are xo-specific. It's not clear that one could get from any xo disk image to a hardware-independent build. Perhaps one might find out what versions of things went into a latest-stable-build? Perhaps sugar-jhbuild works not-infrequently for some particular environment, eg fc7 x86? Perhaps take someone's fc6+sugar image (Big FC6 Build lacks etoys), attempt updating it, and strip it down?
  • Re derive from LiveCd, one might be able to unsquash the fs, customize for this role, make a qemu image with it, and add boot stuff?
  • The LiveCd image, once unsquashed, is not small (4GB). Is this Gnome and such? Does the xo have some non-readonly compression which we can shrink that with? Is it worth a performance hit? MitchellNCharity 23:38, 1 June 2007 (EDT)
  • If sound starts fully working on xo disk images, given that qemu doesn't support usb cameras, is this option needed? Isn't the non-devel image equivalent? MitchellNCharity 23:38, 1 June 2007 (EDT)

Emulation overhaul

moved from User_talk:Mcfletch

Hi. It's great to have emulation being updated. Here are a couple of observations which drove changes vis the n-1 version of the emulation pages:

• There is a lot of overlap between different emulation platforms.
  • In "front", image selection and prep. Perhaps someday the build images will consistently just work in emulation. So the documentation for grabbing an image will simply be a link. But it's never been true so far, and I don't see any sign of that changing. So the selection of which image to use seems likely to remain something which requires a "weather report" of the status of recent builds. We obviously don't want to replicate that info. Two approaches might be to send people through a single "grab an image" page, or to transluced such a page by platform-specific recipes,
  • In "back", setting up a development environment and dealing with bugs. Getting from emulation is "running", to emulation is running correctly and usably. Display size, sound, camera, shell access, file access. The tuples of <emulation platform, operating system> share content on both axes. The current big Emulating the XO/Help_and_tips collects information which was previously scattered among emulation platform specific pages. It's inelegant. I'm unclear on what the right solution is here.
• Emulation platforms get used for different things. XO devel images; 32-bit fc/ubuntu to run sugar-jhbuild; xs school server images. Live CDs. So separating out platform installation and general usage from their assorted uses seems worthwhile. But installation especially can be os dependent. So we need to deal with <{qemu,vmware,vbox} on {windows,mac,ubuntu,fc,other-linux}> and some extras like Parallels and Virtual PC.
• I kept the OS images for emulation name as a redirect into Emulating the XO, and the access point used elsewhere on the wiki. The core team folk were continuing to use it, and it provides them an easy way for them to clip off Emulating the XO and pursue a different approach. Even though the title is really unfortunate ("which OS?!?").
• One possible role for the article is to provide a "if you want to do X, and you are running OS Y, here's what we recommend". It seems unlikely that any one solution will become the one true way to emulate the XO. I've never really bought the "develop on Live CD" story, but even so, sugar-jhbuild is too big and fragile to be a general solution, different OSes have different prefered emulation platforms, qemu likely remains in as something non-proprietary, we will hopefully have bootable images (LiveCD and or USB stick), etc. Emulating the XO was envisioned as the place which helps visitors figure out their options, and organizes resources they collectively need. A counter argument is it would be really nice to have something, anything, which "just works", and can serve as the focus of effort, even if it is suboptimal for some users/uses. I'm not sure if trying for a sugar-jhbuild/some-emulator duopoly actually addresses a bottleneck. For the last few months at least, the bottleneck has mostly been emulation isn't a priority for the project (doesn't appear on roadmap; isn't kept working in the run-up to releases; isn't tested/tinderboxed; even simple tickets tend to be unaddressed for weeks). But perhaps having a single official and working emulation story might help change that.

MitchellNCharity 13:12, 28 August 2007 (EDT)