Using the stable version of Emdebian

This page is intended to provide guidance for those wishing to use the version of Emdebian included in Debian stable (Lenny). Its focus is on Crush.

Crush development has stalled! These instructions are out of date and some tools have been removed

In the case of emdebian "stable" should _not_ be read "less bugs" but rather "not a moving target". Because emdebian was under very active development at the time of the Lenny freeze there are probably _more_ bugs in the stable version of emdebian than in the unstable one. However some people may prefer the bugs they know (and can work around) to trying to track a development branch.


The methods described here do not necessarily reflect those of the emdebian developpers (although some of the ideas have been discussed on the mailing list and have not met with opposition). Some solutions described may be considered "hacks" but are necessary to work within the constraints of the current stable version. Feel free to suggest improvements within these constraints.

Some of the techniques suggested for private packages are not Debian policy compliant but they are _only_ for private helper packages.

Intended audience

People wishing to use emdebian to create an embedded GNU / Linux device in an "industrial" manner.

It is assumed the reader is familiar with


In addition to emdebian other tools will typically be required on a developer's workstation:

To simplify installation it is suggested to create a custom Debian package (which is almost a simple metapackage - but with an added postinst script).

This, together with a few makefiles stored in version control will let the bare PC to built and deployed embedded target workflow look like

For example:

Depends: build-essential, sudo, ccache, sparse, \
        subversion, git-core, stgit, \ 
        emdebian-tools, \
        python, atftp, nfs-kernel-server

Since the stable version of emdebian-tools tries to use the unstable package repository the following may be placed in the postinst

        # bug in lenny version of emdebian-tool uses unstable sources
        sed -i s/unstable/lenny/g /etc/apt/sources.list.d/emdebian.sources.list
        sed -i s/unstable/lenny/g /etc/emsource.conf
        sed -i s/unstable/lenny/g /etc/emsandbox.conf
        # ensure proxy environement variables propagated to sudo
        grep -q "Defaults.*env_keep" /etc/sudoers || sed -i 's#\(Defaults.*\)#\1, env_keep += "http_proxy ftp_proxy no_proxy"#' /etc/sudoers

Directory structure

Below is a simplified version of my project directory structure.

|-- custom-packages
|   |-- debs
|   `-- project-environment
|       `-- debian
|-- env
|-- src
|   |-- kernel
|   |   |-- patches
|   |   `-- scripts
|   `-- userspace
|       `-- emdebian
|           `-- rootfs
|               |-- machine
|               |   `-- tgx200
|               |       `-- default
|               |           `-- raw
|               |               |-- etc
|               |               |   `-- X11
`-- target
    `-- nfs

Interesting parts


source for any custom debian packages (like the "meta" package described above)


patches and Makefile for kernel. Source is obtained from an external git repository


root for emsandbox


files to be directly copied to root filesystem

Top level Makefile

A Makefile like the one shown below can handle the initial emsetup

        echo TODO help


        @lsb_release -d | grep -q "Debian.*lenny" || (echo \
"Please run on Debian 5.0 (lenny) or in a chroot using the mycompany-lenny-chroot package"; false)
        @dpkg-query -l mycompany-myproject-build >/dev/null 2>/dev/null || (echo \
"Please install the mycompany-myproject-build package"; false)

toolchain: check_env .stamp-toolchain

        emsetup --arch arm
        touch .stamp-toolchain

kernel: toolchain
        cd src/kernel && $(MAKE) all

userspace: toolchain
        cd src/userspace/emdebian/rootfs && $(MAKE) all

nfs: userspace
        mkdir -p $(NFS_DIR)
        sudo tar -C $(NFS_DIR) -xzf $(ROOTFS_TARBALL)

        sudo rm -rf $(NFS_DIR)

pristine-nfs: nuke-nfs nfs

.PHONY: help check_env toolchain kernel userspace nfs pristine-nfs

Rootfs Makefile

Simple wrapper to only invoke emsandbox when required

all: ship_rootfs

include ../../../../

tarball := emdebian-tgx200-gui.tgz
all_files := $(shell find machine -name .svn -prune -o -print)

$(tarball): $(all_files)
        rm -f $(tarball)
        sudo emsandbox --arch arm -m tgx200

ship_rootfs: $(ROOTFS_TARBALL)

$(ROOTFS_TARBALL): $(tarball)
        cp $(tarball) $(ROOTFS_TARBALL)

.PHONY: all ship_rootfs

Building the root filesystem

Using stable packages

Ensure machine/_machine_name_/default/packages.conf contains


Basic customisation

machine/_machine_name/default/ can contain something like

configDir=$(dirname $0)

echo "Installing Raw files from $configDir to $target"
rsync -av --no-owner --no-group --exclude=.svn $configDir/raw/ $target
chmod +x $target/

# Add kernel modules
cp -R --no-preserve=links ../../../../target/modules/* $target

# No password for root
sed -i s/root.*/root::0::::::/ $target/etc/shadow

mknod $target/dev/console c 5 1

# Ensure we have pts device nodes for telnet in case udev doesn't come up
mkdir -p $target/dev/pts
mknod $target/dev/pts/0 c 136 0
mknod $target/dev/pts/1 c 136 1

Initial boot

"emsecondstage" must be run on the device on the first boot to complete package installation. I do this by an entry in /etc/inittab :

#First time complete debian package intallation

and a / script:

/emsecondstage 2>&1 | tee /tmp/emsecondstage.log

The redirection in is useful when debugging (especially when /tmp is on NFS)

Working around bugs

Many bugs can be worked around in the machine/_machine_name/default/ by modifying the filesystem tree after generation

For example

# (em)Debian lenny hack fixes below
# Missing directory
mkdir -p $target/etc/rc.d

# lenny version of emsandbox creates /var/lib/X11 rather than /var/lib/x11
mv $target/var/lib/X11 $target/var/lib/x11

# See #512012
sed -i "s/kill -s /kill -/g" $target/var/lib/dpkg/info/udev.postinst

# See #497551
sed -i "s/kill -USR1/#kill -USR1/g" $target/etc/init.d/

# See #512028
sed -i 's:#!/bin/bash:#!/bin/sh:' $target/usr/bin/startx
(cd $target/usr/bin;ln -s Xorg X)

# we need to grab some conf files from the normal (non emdebian) packages
# since the files we need are arch indep we can use the system apt sources
# which will normally point to our internal (i386 only) mirror
extract_from_package () {

        tmpdir=$(mktemp -d)
        (cd $tmpdir ; aptitude download $package)
        debfile=$(ls $tmpdir/*.deb)
        files=$(dpkg-deb -c $debfile | grep -E $pattern | awk '{print $6}')
        dpkg-deb --fsys-tarfile $debfile | tar -C $dest -xf - $files
        rm -rf $tmpdir

# See #512241
extract_from_package libgtk2.0-0 $target "\.immodules|\.loaders"

# See #512243
extract_from_package libpango1.0-0 $target "\.modules"

Remaining bugs

The above fixes give a working GPE setup however there are still some non fatal bugs

Error setting up package debian-archive-keyring or using gpg

This is being discussed on the mailing list and manifests itself as

Setting up debian-archive-keyring (2009.01.31em1) ...
gpg: symbol lookup error: /lib/ undefined symbol: PC
gpg: symbol lookup error: /lib/ undefined symbol: PC
gpg: symbol lookup error: /lib/ undefined symbol: PC
dpkg: error processing debian-archive-keyring (--configure):
 subprocess post-installation script returned error exit status 127

Error setting up fontconfig-config

Sometimes (but not always :( ) there is

 Setting up fontconfig-config (2.6.0-3em1) ...
dpkg: error processing fontconfig-config (--configure):
 subprocess post-installation script returned error exit status 10

This causes all the X11 related packages to fail to install too. However manually re-running the postinst or calling apt-get install fixes it. Still trying to investigate this.

Using a package mirror

In order to be able to work without an internet connection you may want a mirror of the emdebian repository.

TODO: try it and describe

Adding packages