Wiki /
Immutable Page
Info Attachments EmDebian CrossDebootstrapContentsCross-installing Debian using debootstrap/multistrapRequirementsMultistrapExample useBasic usagemultiple repository usagepackages from multiple componentsConfiguring the rootfsQEMU/debootstrap approachInstalling required packagesGenerating cross images as root userGenerating cross images as non-root userUsing schrootUsing fakechrootConfiguring the new system (target specific)Serial consoleNetworkingAptReferencesReal Hardware/cdebootstrap approachSecond attempt using debootstrapUnpacking methodIssues with the final filesystem imageIssues with replacing debconf with cdebconf/etc/group and /etc/passwdash, not bashbusybox applets, not coreutilsstarting init processesOutputting messages to the userCalling processes within debootstrapMethodapproximate time and SecureAptInstalling the imageCross-installing Debian using debootstrap/multistrapEmbedded Debian.
From debootstrap's manpage:
"Debootstrap can be used to install Debian in a system without using an installation disk but can also be used to run a different Debian flavor in a chroot environment. This way you can create a full (minimal) Debian installation which can be used for testing purposes".
Basically, bootstrapping a Debian system involves four steps (some were ommitted for simplicity):
Download the necessary .deb packages from a repository.
Unpack then into the target directory.
Chroot into the target directory.
Run the installation and configuration scripts from each package, finishing the setup.
Usually, when doing cross-bootstrapping, steps 3 and 4 need to be done on the target side. This document explains how to bootstrap a Debian system for a target architecture different from the host's one, doing all steps on the host side and, optionally, using QEMU to run target executables.
This is useful, for example, to create filesystem images without depending on the target board to be available.
RequirementsThere are lots of ways of doing this. You can use multistrap (recommended) or debootstrap or cdebootstrap for stages 1 and 2. And QEMU or real hardware for stages 3 & 4.
Four variant approaches are described on this page:
Multistrap + real hardware
Multistrap + config script for rootfs creation
hardware or QEMU for configuration.
QEMU
QEMU with transparent user mode emulation (see
QemuUserEmulation)
debootstrap, with patch (
355801) applied to support cross-bootstrapping
Real hardware
An ARM machine which can mount an NFS root
cdebootstrap (in squeeze)
Unpacking method
Any Debian box, to support any ARM machine with serial, network or USB connectivity
emsandbox (debootstrap --foreign).
This page will try to stick to general issues around how a cross bootstrap differs from typical usage of debootstrap. See also
EmDebian/DeBootstrap which deals with specific issues with particular boards or devices.
There’s now also debootstrap --foreign + debootstrap --second-stage, which should erase the need to “re-install everything to get the configuration scripts run”. The author of this document is asked to look into this. --mirabilos
MultistrapMultistrap is a relatively new tool (March 2009) which does essentially the same job as Debootstrap but much more flexibly, efficiently and reliably. It works in a completely different way by simply using apt and dpkg, rather than avoiding using them, which is how debootstrap works. It is focussed on producing rootfs images for devices, as opposed to chroots for existing machines, but in fact (like debootstrap) does both of these jobs almost equally well.
Advantages:
Can use packages from multiple repositories - uses normal apt resolution to choose set. This is very powerful - you can use emdebian grip as a base, plus some packages from debian plus packages from a local repository, by listing the repositories to use and the set of top-level packages wanted from each.
Doesn't need copies of every deb in /var/cache/apt/archives, so tarball approx half the size
Unpacks with dpkg so dpkg database already has packages marked 'unpacked': only postinst scripts need to be run to complete process.
Because it uses apt all the normal apt features work (e.g. apt-cacher, repository key checks, different apt methods (url, file))
Limitations:
You need a real Debian-based system to run it on. Debootstrap can work on any system.
It needs a configuration file to run - you can't just do 'multistrap <mirror> squeeze'
Multistrap creates the image from the packages needed; it does not make device/chroot-specific modifications. Most real devices need a set of such changes to operate (console, inittab, fstab, devicenodes, etc) and a script or manual changes are needed. It will soon gain hooks to help automate this sort of config.
apt-get install multistrap
Example useBasic usageTo create a new image in targetdir for arch armel using repsoitories specified in multistrap.conf: (both arch and dir can be specified in the config file too if you prefer)
# multistrap -a armel -d targetdir -f multistrap.conf
This is a minimal config which will make a grip rootfs using just the packages which are Priority: required (essential is ignored by multistrap, making it much easier to only get what you want/need). Noauth stops secure-apt complaining about keys if no keyring package is specified.
[General]
noauth=true
unpack=true
debootstrap=Grip
aptsources=Grip
[Grip]
# space separated package list
source=http://www.emdebian.org/grip
suite=lenny
The (tared-up) result is a 30Mb tarball (approx 50% apt cache contents). Adding
cleanup=true
to the config removes the apt cache debs and lists, resulting in a 15Mb tarball.
multiple repository usageThis is a more complex example which uses four repositories: grip, debian (for extra packages not in grip), grip updates from proposed-updates, and a local repository, as well as specifying some optional packages from those repositories. The important thing is that for every name listed in 'aptsources' you need a correspondingly named section containing at least source and suite. The use of keyring packages and specifying components other than the default of 'main' is also shown.
I've set the cleanup option (which tidies up /var/cache/apt/ ), the retainsources option (which keeps all downloaded debs in a directory so you have a copy of what was used to make this rootfs) and an example of setting the arch and target dir in the config instead of on the command line:
[General]
unpack=true
debootstrap=Grip
aptsources=Grip Updates Debian Localserver
cleanup=true
arch=armel
directory=/tmp/targetdir/
retainsources=/tmp/targetdir/sources
[Grip]
#space separated package list
packages=udev ntpdate
source=http://www.emdebian.org/grip
keyring=emdebian-archive-keyring
suite=lenny
[Updates]
packages=apt
source=http://www.emdebian.org/grip
keyring=emdebian-archive-keyring
suite=lenny-proposed-updates
[Debian]
packages=erlang-nox
source=http://ftp.uk.debian.org/debian
keyring=debian-archive-keyring
suite=lenny
[Localserver]
packages=sl40-platform-debian balloon3-config
source=http://aptcache.localhost:4132/debian
keyring=localrepo-archive-keyring
suite=development
Running
sudo multistrap -f multistrap.conf
updates package lists, takes packages from all 4 repositories (checking them against the specified keyrings) and builds the rootfs, clears out the apt-cache and saves all the debs in the directory specified in retainsources.
packages from multiple componentsAs of multistrap version v2.0.6, it is possible to use the "components=" option to load packages from components other than main. Here is an example to include a firmware package from non-free:
[General]
noauth=true
unpack=true
debootstrap=Squeeze
aptsources=Squeeze
arch=armel
[Squeeze]
packages=wpasupplicant wireless-tools firmware-ralink
source=http://ftp.au.debian.org/debian/
keyring=debian-archive-keyring
components=main non-free
suite=squeeze
Configuring the rootfsThe rootfs produced is chrootable, but often not bootable without fixing up a few files. See the QEMU/DeBootstrap section below for examples of the changes usually needed. Normaly it's best to script those changes for repeatability.
If you can, it usually easier to chroot into the rootfs (on an ARM machine, or using qemu) to configure it as less work is required than making it bootable.
chroot /tmp/targetdir
dpkg --configure -a
will run all the postinst scripts of the installed packages and complete the rootfs generation process. Tar up the result and copy it onto your device.
Alternatively, if you can boot the image on the device then you can do the
dpkg --configure -a
on the device directly.
QEMU/debootstrap approachInstalling required packagesInstall required packages using the following command:
# apt-get install binfmt-support qemu qemu-user-static debootstrap
Generating cross images as root userThe following steps need to be done as root, because debootstrap will create device nodes (using mknod) as well as chroot into the newly created system, which require root privileges.
Choose the target's architecture and Debian suite (e.g. stable, testing, sid) you want to bootstrap. For this tutorial, we will choose the ARM target architecture and the wheezy (AKA Debian testing) suite.
Choose a (empty) directory where you want the new system to be populated. This directory will reflect the root filesystem of the new system. Note that the host system is not affected in any way, and all modifications are restricted to the directory you have chosen.
Note: For the purporses of this document, we will use "debian_armel_wheezy" as the target directory. Create this directory, if it does not exist already:
# mkdir debian_armel_wheezy
To bootstrap the new system, run debootstrap. E.g.:
# debootstrap --foreign --arch armel wheezy debian_armel_wheezy http://ftp.debian.org/debian/
where "debian_armel_wheezy" is the directory you have created and "armel" is the target architecture. See debootstrap(8) manpage for more details about each parameter used above.
"
http://ftp.debian.org/debian/" is the Debian mirror from which the necessary .deb packages will be downloaded. You are free to choose any mirror you like, as long as it has the architecture you are trying to bootstrap. See
http://www.debian.org/mirror/list for the list of available Debian mirrors.
The new system is now created. By default, debootstrap creates a very minimal system, so you will probably want to extend it (see below 'Configuring the new system' for some instructions).
Copy in the chroot qemu-arm-static
# cp /usr/bin/qemu-arm-static debian_armel_wheezy/usr/bin
Trigger post install scripts
chroot DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true \
LC_ALL=C LANGUAGE=C LANG=C dpkg --configure -a
Generating cross images as non-root userGenerate a configure file for multistrap (armel.conf)
[General]
# arch and directory can be specified on the command line.
arch=armel
directory=/tmp/chroot_armel
omitrequired=false
# same as --tidy-up option if set to true
cleanup=true
# retain the sources outside the rootfs for distribution
# specify a directory to which all the .debs can be moved.
# or override with the --source-dir option.
retainsources=
# same as --no-auth option if set to true
# keyring packages listed in each debootstrap will
# still be installed.
noauth=true
# extract all downloaded archives
unpack=true
# the order of sections is no longer important.
# debootstrap determines which repository is used to
# calculate the list of Priority: required packages
debootstrap=Grip
# the order of sections is no longer important.
# aptsources is a list of sections to be listed
# in the /etc/apt/sources.list.d/multistrap.sources.list
# of the target.
aptsources=Grip
#configscript=config.sh
#setupscript=setup.sh
[Grip]
packages=udev aptitude
source=http://www.emdebian.org/grip
keyring=emdebian-archive-keyring
suite=lenny
omitdebsrc=true
Generate the root filesystem with multistrap
$ cd /tmp
$ multistrap -a armel -f armel.conf -d chroot_armel
Alternatively generate a root filesystem with debootstrap
$ fakeroot debootstrap --foreign --arch=armel sid $ROOTDIR
Add emulation layer
$ cp /usr/bin/qemu-arm-static chroot_armel/usr/bin
Using schrootInstall and configure schroot (/etc/schroot/schroot.conf)
[chroot_armel]
description=Debian armel cross chroot
directory=/tmp/chroot_armel
users=$USER
groups=sbuild
root-groups=root
aliases=default
In order to bypass a QEmu limitation mapping lower memory addresses, you should configure your system with:
$ sudo sh -c "echo 0 > /proc/sys/vm/mmap_min_addr"
schroot into the root filesystem as user (any time)
$ schroot -c chroot_armel
Using fakechrootCreate a symlink as root under /lib, otherwise it does not work
$ sudo ln -sf /tmp/chroot_armel/lib/ld-linux.so.3 /lib/ld-linux.so.3
Execute chroot as follows ignoring ERROR messages
$ LD_LIBRARY_PATH=$(pwd)/chroot_armel/usr/lib/fakechroot fakechroot /usr/sbin/chroot $(pwd)/chroot_armel/ /bin/pwd
Configuring the new system (target specific)The system you have just created needs a few tweaks so you can use it for specific tasks. The following steps need to be done as root, as the files touched are owned by root.
First create a fixed symlink to the directory where the new system was bootstrapped:
# ln -sfn /full/path/to/debian_armel_wheezy/ /armelfs_debian
Mount the proc filesystem on the target so the next commands can run properly:
# mount -t proc proc /armelfs_debian/proc
Serial consoleEdit /armelfs_debian/etc/inittab and add the following line at the bottom:
T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100
also comment out the following lines (virtual consoles are not needed for our purposes):
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6
Create the "ttyS0" device node on the target so the serial console can be used:
# chroot /armelfs_debian sh -c "cd /dev; ./MAKEDEV ttyS0"
NetworkingCopy the /etc/hosts file from the host to the target system, so networking can work properly inside the chroot:
# cp /etc/hosts /armelfs_debian/etc/
AptRun apt-setup to create a new /etc/apt/sources.list for the target:
# LC_ALL=C chroot /armelfs_debian apt-setup
Select "edit sources list by hand" and add the following entries: