Using qemu-debootstrap, it is possible to create a chroot build environment for Raspbian that runs on a desktop Debian or Ubuntu system. The process for setting up an environment was described by Super Pi Adventures in this article: Development environment (Internet Archive link). This is useful if you need to develop your code in an environment that is close to that running on a real device.
Once you have already developed your code and created Debian packaging for it, you want to be able to automate package building for deployment on Raspbian. In this case, it's more convenient to use pbuilder to automate the process of building packages than it is to enter the chroot and perform the tasks in the build process manually.
There are a few steps that are needed to create a chroot for pbuilder to use.
To begin with, we need to install the packages that will be needed to create the chroot (debootstrap), run ARM code (binfmt-support, qemu-user-static) and build packages (pbuilder):
sudo apt-get install debootstrap pbuilder binfmt-support qemu-user-static
Once this is successfully done, we can start to set up the directory structure that will hold the archived chroot.
We will install the archived chroot in a directory structure in our home directory. You may choose to install it somewhere else, in which case you should change the following lines to meet your needs:
mkdir -p $HOME/pbuilder-work/gnupg mkdir -p $HOME/pbuilder-work/raspbian-wheezy mkdir -p $HOME/pbuilder-work/raspbian-wheezy/hooks chmod go-rwx $HOME/pbuilder-work/gnupg
The gnupg directory will hold a GNUPG keyring that will be used to verify the packages installed in the chroot.
Before you can create and populate the chroot, you need to have obtained the public key that corresponds to the key used to sign the packages in the distribution and verified that you can trust it in some sense.
The public key is available from https://archive.raspbian.org/raspbian.public.key. This is distributed over HTTPS so, as long as there are no problems with certificates, we can have some confidence that the key we receive is the one being distributed by that site. However, we still need to establish that the owner of the key is who they say they are. On the other hand, if you trust the Raspbian project then you have already established that the key has come from their site, and so you may feel comfortable trusting that key.
Another way to obtain the key over some kind of secure channel is to download the Raspbian Wheezy system image from the Raspbian download page of the Raspberry Pi site and verify that the SHA1 sum of the downloaded file matches the one published on the download page. From there, we can extract the image from the archive, mount it, and extract the /usr/share/keyrings/raspbian-archive-keyring.gpg file. Again, we are establishing some confidence that the key contained in the image is the one supplied by the Raspberry Pi site, and in some sense delegating the issue of trust to the Raspberry Pi project since it could be argued that they are somehow endorsing the key and suggesting that it can be trusted.
We can also obtain the key via a keyserver (even using HTTPS) but this still presents us with the problem of verifying it.
One way to verify the key is to use the fingerprint published in this message posted to Debian's pastebin. However, to be confident that the fingerprint has not been tampered with, we must verify the message using the public key of the person who signed it. Fortunately, their public key is in the /usr/share/keyrings/debian-keyring.gpg keyring file supplied with recent Debian distributions, so we can verify that the message is correct and use the fingerprint to establish that the Raspbian public key is the one that is supposed to be used with the Raspbian repository.
At this point, we are delegating our trust to the person who signed that message. The message doesn't validate the owner of the Raspbian signing key, only indicating that it is the key to use. If we rely on the message author to vouch for the key then we have gained more confidence about it because we can establish a chain of trust from the identities in the Debian keyring to that person and hope that they are doing the right thing. Otherwise, we haven't gained much beyond what we had when we first downloaded the public signing key from the Raspbian site.
Let's just download the key from the Raspbian site and verify it to some extent. First, we fetch it and import it into our keyring:
wget https://archive.raspbian.org/raspbian.public.key gpg --homedir $HOME/pbuilder-work/gnupg --import raspbian.public.key
You should see the following output from gpg:
gpg: key 90FDDD2E: public key "Mike Thompson (Raspberry Pi Debian armhf ARMv6+VFP) <email@example.com>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1)
We can find the fingerprint with this command:
gpg --homedir $HOME/pbuilder-work/gnupg --fingerprint 90FDDD2E
This produces the following output:
pub 2048R/90FDDD2E 2012-04-01 Key fingerprint = A0DA 38D0 D76E 8B5D 6388 7281 9165 938D 90FD DD2E uid Mike Thompson (Raspberry Pi Debian armhf ARMv6+VFP) <firstname.lastname@example.org> sub 2048R/5373DC6C 2012-04-01
Now, we obtain the clearsigned message from Debian's pastebin, using curl because wget appears to have difficulty:
curl https://paste.debian.net/download/171594 > paste_171594
The message tells us the fingerprint of the public signing key, which happens to match the one above, but we need to verify it first:
plugwash's signed confirmation of the raspbian.org archive key details: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I confirm the key being used to sign the Raspbian repository as for 2014-06-17 is pub 2048R/90FDDD2E 2012-04-01 Key fingerprint = A0DA 38D0 D76E 8B5D 6388 7281 9165 938D 90FD DD2E -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJToL6hAAoJEAxI6ip6j/17F2UP/AuWP2+2lbphMoAzxbTgd6Hp YpuNGgtuXtQXhAWBS6Ml2tTBbOwqPlESbVhVDKunf5TlP2KJvAO4p9nrnRiqwiOl 5gpJ3RA8zoLuTrIfwSEvzbtDGbAAoHHsGogwurn5TB3EMJY+Kktwwm4JYtJvjkjy C4w8kuhuiRosm8FjXchhWbKI4bANfqZ1BpCOkwyP8T7gf0qQTynbWls7VDQTHC2T Yhy1G6qQlGylSDr6D/5yin9J1rmAywpSrVU4fIeR3C/V1YeWgZZbDNHrIbvUJ5T8 ntKSrS1wYLc4dGeLIi2zc3BZWpHxC00GzaC1w6v9aH4qsxmVpM0U0sQ4Rup++8qV VCmYJf22BzVhPeYYjRA0M1hnTjXnMT6FqtD9arVob1EJHtMYlDJiowKDhZC5qxND q1nKmWWNhTTAieA7VwstADsuAjo2NIF57EQilluhZUdLlsfY8cZomAivAbpCaC7R lDYzb/sFa94F1dK5tlBv2/jItZXuUkFadh3ie+ynnZccY4mb31zGmp1/EQOfaisn rAvZ6qIgPNHf1O66P4yYsHBKnzLQLkcs4SsI3XmO/6PHXVXG3CQ0DULUISTaiHES 4D9Os6ryuptmbfRUQOJW7jsSXMn2OyMQVWmySobv5SQK1cydwwrLmgCaKPi1FF3/ +dZEIwZCwzx2E1UiqJRu =gc3M -----END PGP SIGNATURE-----
Before we can verify it, we will need to import a key from one of Debian's keyrings:
gpg --keyring /usr/share/keyrings/debian-keyring.gpg -a --export 7A8FFD7B | gpg --homedir $HOME/pbuilder-work/gnupg --import
This should produce the following output:
gpg: key 7A8FFD7B: public key "Peter Michael Green <email@example.com>" imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: no ultimately trusted keys found
Now we can verify the clearsigned message:
gpg --homedir $HOME/pbuilder-work/gnupg --verify paste_171594
With only the keys we have imported, the output from gpg will look like this:
gpg: Signature made Wed 18 Jun 2014 00:18:09 CEST using RSA key ID 7A8FFD7B gpg: Good signature from "Peter Michael Green <firstname.lastname@example.org>" gpg: aka "Peter Michael Green <email@example.com>" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 5340 D001 360C A656 E349 7EB7 0C48 EA2A 7A8F FD7B
So, at this point, we can either import more keys from the Debian keyring and from our personal keyring to establish a chain of trust between us and the author of the message. Alternatively, we can be assured that someone, whose key is supplied with the operating system we are using and which is signed by other Debian project members, has written and signed a message telling us the fingerprint of the Raspbian public key.
The fingerprint in the clearsigned message matches the fingerprint produced by gpg and we have verified it to some extent. It would have been easier to verify it if the public key had been signed by others with public keys in the Debian keyring.
With the key imported, we can create the chroot for use with pbuilder.
Before we create the chroot, we need to describe it using a configuration file which should be stored in $HOME/pbuilder-work/raspbian-wheezy/pbuilderrc. The contents of the file are as follows:
MIRRORSITE=http://archive.raspbian.org/raspbian #OTHERMIRROR='deb http://archive.raspbian.org/raspbian wheezy main contrib non-free rpi' CCACHEDIR=/home/$SUDO_USER/pbuilder-work/ccache APTCACHE=/home/$SUDO_USER/pbuilder-work/raspbian-wheezy/cache/aptcache APTKEYRINGS=/etc/apt/trusted.gpg ARCHITECTURE=armhf BASETGZ=/home/$SUDO_USER/pbuilder-work/raspbian-wheezy/cache/base.tgz BUILDPLACE=/home/$SUDO_USER/pbuilder-work/raspbian-wheezy/cache/build/ BUILDRESULT=/home/$SUDO_USER/pbuilder-work/raspbian-wheezy/cache/result/ DEBOOTSTRAP=qemu-debootstrap DEBOOTSTRAPOPTS=('--arch' 'armhf' '--keyring=/etc/apt/trusted.gpg' '--keyring=/home/'$SUDO_USER'/pbuilder-work/gnupg/pubring.gpg') DISTRIBUTION=wheezy EXTRAPACKAGES="" HOOKDIR=/home/$SUDO_USER/pbuilder-work/raspbian-wheezy/hooks
This defines where pbuilder obtains packages for the chroot and where it stores the archived chroot. Note the use of qemu-debootstrap instead of debootstrap. If you want to store the archived chroot elsewhere, change all the definitions that start with /home/$SUDO_USER to specify paths corresponding to those you chose earlier.
Now we can run pbuilder to create the chroot:
sudo pbuilder --create --configfile $HOME/pbuilder-work/raspbian-wheezy/pbuilderrc
If this works successfully, there should be a file called base.tgz in the $HOME/pbuilder-work/raspbian-wheezy/ directory (or your chosen location). It should now be possible to use pbuilder to build packages for use on a Raspbian Wheezy system. See the pbuilder User's Manual for information on how to use pbuilder.
We have created a chroot environment that can be used to build packages for Raspbian Wheezy. The two key steps we used in this process were these:
I am interested in receiving suggestions for improvements to this document. Please contact me if you see anything that could be improved.
Copyright © 2015 David Boddie
Last updated: 2015-10-27 20:18:53 UTC