This should not be this hard (Qemu or chroot'd loopback mount...)


Looking at what to recommend for developers wanting to get started this evening.

Xen doesn't seem like a readily deployed solution: manually rework your whole boot system, build multiple kernels, edit configuration files, hope it works. Fine for sysadmins building computers every day, but not a programmer's favourite way to deal with their primary development machines.

Conversion from Qemu builds to VMWare still doesn't work due to the missing vmware network driver AFAICS. Failures all over the Gentoo sugar-jhbuild process, looks like all of that is just different library versions and/or complications due to the build prefix and/or having different paths to Python.

Looked into doing a chroot operation as well. Mount the image (with an offset) as a loopback file system, then do a 32-bit chroot into the image. That works to get a shell, but of course it doesn't go through the system initialization, so you don't get a running Sugar environment out of it. That could likely be solved with a simple script to run to set up what Sugar actually needs within the chroot. Need to figure out how to make the X client work in that environment too, but there's some promise there (seems to me).

Qemu is still pretty slow. With KQemu it's not horribly painful. I haven't been able to get my 542 image to use the network, however. At one point I had it getting dhcp from the Qemu system, but it wasn't getting the packets routed out to the real world. Seems Qemu is the only game in town at the moment if you're not running Fedora 7 on your workstation.

There are a number of suggestions on the wiki that I haven't tried yet for fixing the network, guess I'll try them tomorrow or so. At PyCon we basically found that the host setup for Qemu networking on Linux was often rather involved. That still may be the case, or it might be something as simple as a misplaced parenthesis.

Sysadmin-ing is really not my forte.

Comments

  1. Ian Bicking

    Ian Bicking on 08/11/2007 1:43 a.m. #


    Is there something you could install via yum in qemu, that will help the VMWare image once you convert over?

  2. Ian Bicking

    Ian Bicking on 08/11/2007 1:46 a.m. #


    FWIW, on VMWare with the Live ISO, disk sharing was really easy to setup. Unfortunately I couldn't get the same working on the converted qemu images.

  3. Mike Fletcher

    Mike Fletcher on 08/11/2007 9:15 a.m. #


    For the vmware driver: I think it would just be a matter of getting the OLPC kernel source and then compiling the driver. Of course, I don't know how to do that on Fedora :) .<br />
    <br />
    VMWare disk sharing is AFAIK all done via networking interfaces (smb or the like), so it's likely the same basic problem.

  4. Andrew Clunis

    Andrew Clunis on 08/13/2007 11:23 a.m. #


    I've been using KVM for stuff. It's pretty convenient, because the userspace piece is basically qemu.<br />
    <br />
    It's got some bugs relating to dyntick guest kernels right now, though... I don't think it actually works with OLPC guest images at the moment.

  5. Carl Witty

    Carl Witty on 08/13/2007 3:31 p.m. #


    Have you looked at VirtualBox (www.virtualbox.org)?

  6. Mike Fletcher

    Mike Fletcher on 08/13/2007 9:58 p.m. #


    With virtualbox, the old developer's livecd seems to work fine, but the OLPC-542 image converted from the raw ext3 disk isn't able to start the X server. Virtualbox itself is a pretty trivial install, requires adding a boot-flag to disable some kernel feature, and adding a module to the set, but that's the same basic requirement as vmware for Linux. Speed seems quite good in the LiveCD. Probably worth investigating further.

Comments are closed.

Pingbacks

Pingbacks are closed.