Official OLPC OS is bootstrapped with Debian!?

12 October 2008

I was just looking through the contents of the olpcrd.img file on my XO build update.1 708, and it seems that the initrd is a minature installation of Debian.

It contains some giveaway files, such as /var/lib/dpkg/status, which contains:

Package: libnss-dns-udeb
Status: install ok unpacked
Version: 2.7-5
Description: GNU C Library: NSS helper for DNS - udeb

Package: wireless-tools-udeb
Status: install ok unpacked
Version: 29-1
Depends: libc6 (>= 2.6.1-1), libiw29-udeb (>= 28+29pre7)
Description: Tools for manipulating Linux Wireless Extensions

Package: python2.5-minimal
Status: install ok unpacked
Version: 2.5.1-1
Depends: zlib1g-udeb, libc6
Description: A minimal subset of the Python language (version 2.5)

Package: module-init-tools-udeb
Status: install ok unpacked
Version: 3.3-pre11-4
Depends: libc6 (>= 2.5-5)
Description: tools for managing Linux kernel modules

Package: olpcrd-rootskel
Status: install ok unpacked
Version: 1.54
Depends: python2.5-minimal, wireless-tools-udeb
Description: Skeleton root filesystem used by OLPC initramfs

Package: busybox-udeb
Status: install ok unpacked
Version: 1:1.1.3-5
Depends: libc6 (>= 2.5-5)
Description: Tiny utilities for the debian-installer

Package: libiw29-udeb
Status: install ok unpacked
Version: 29-1
Depends: libc6 (>= 2.6.1-1)
Description: Tools for manipulating Linux Wireless Extensions

Package: zlib1g-udeb
Status: install ok unpacked
Version: 1:1.2.3.3.dfsg-8
Description: compression library - runtime for Debian installer

Package: debian-installer
Status: install ok installed
Version: olpc-20071227-05:33
Description: debian installation image

The packages installed seem to be udebs, which are basically a lite version of normal Debian packages, designed for specialised uses, such as bootstrapping the Debian installer.

But even worse, it seems that the init script for the XO is written in Python. Seriously. The head of the file /init that runs on the OLPC is:

#!/usr/bin/python2.5
## Add an '-i' to the #! line to enable the interactive shell.
## Remove the -i for deployment, to ensure that an
## error in the script doesn't land us in an interactive shell.
from __future__ import division, with_statement
from initutil import *
from activate import activate
import antitheft
import os, os.path, sys, time

debug = False # set to false for deployment

# let's notify console that we've reached this point and python has launched
print "Hello, (children of the) world!"

No wonder it takes so long to boot up! You have to load a whole Python interpreter before we get anywhere!

I haven’t been able to find much documentation on the reasons or inner workings for this bootstrap process. Probably because it’s too embarrasing to reveal. ;)

Can anybody confirm my findings?

4 replies

  • Beyond my knowledge, but one of the early developers was a big debian fan. I found this incomprehensible (to me) page:

    http://wiki.laptop.org/go/Early_Boot

    Perhaps it will make more sense to you?

  • Interesting link. In particular:

    Control is passed to the initramfs’ /init program. This program runs python2.5 as PID 1.

  • Mike says:

    “I haven’t been able to find much documentation on the reasons or inner workings for this bootstrap process. Probably because it’s too embarrasing to reveal.”

    And what’s so embarrassing in that? I really fail to see your point.

  • Mike (who elected to omit his e-mail address, BTW), don’t you think it’s the least bit ironic that they’d use Debian to bootstrap the Fedora-based OLPC? It’s embarrasing for Red Hat because Debian is on the other side. ;)

    Then again, it’s equally embarrasing for Red Hat because they’re using Fedora, and not RHEL. (Like what happened with Kennards Hire.)

    (BTW, if you want to discredit me, point out the fact that OLPC is run by the OLPC Foundation, not Red Hat. :-P)

Leave a reply

Change your avatar.