Poky Handbook

Hitchhiker's Guide to Poky

Richard Purdie

OpenedHand Ltd

<richard@openedhand.com>

Tomas Frydrych

OpenedHand Ltd

<tf@openedhand.com>

Marcin Juszkiewicz

OpenedHand Ltd

<hrw@openedhand.com>

Dodji Seketeli

OpenedHand Ltd

<dodji@openedhand.com>

- Permission is granted to copy, distribute and/or modify this document under - the terms of the Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England & Wales as published by Creative Commons. -

Revision History
Revision 3.1	15 Feburary 2008
Poky 3.1 (Pinky) Documentation Release

Table of Contents

1. Introduction

1. What is Poky?

2. Documentation Overview

3. System Requirements

4. Quick Start

4.1. Building and Running an Image
4.2. Downloading and Using Prebuilt Images

5. Obtaining Poky

5.1. Releases
5.2. Nightly Builds
5.3. Development Checkouts

2. Using Poky

1. Poky Overview

1.1. Bitbake
1.2. Metadata (Recipes)
1.3. Classes
1.4. Configuration

2. Running a Build

3. Installing and Using the Result

3.1. USB Networking
3.2. QEMU/USB networking with IP masquerading

4. Debugging Build Failures

4.1. Task Failures
4.2. Running specific tasks
4.3. Dependency Graphs
4.4. General Bitbake Problems
4.5. Building with no dependencies
4.6. Variables
4.7. Other Tips

3. Extending Poky

1. Adding a Package

1.1. Single .c File Package (Hello World!)
1.2. Autotooled Package
1.3. Makefile-Based Package
1.4. Controlling packages content
1.5. Post Install Scripts

2. Customising Images

2.1. Customising Images through a custom image .bb files
2.2. Customising Images through custom tasks
2.3. Customising Images through custom IMAGE_FEATURES
2.4. Customising Images through local.conf

3. Porting Poky to a new machine

3.1. Adding the machine configuration file
3.2. Adding a kernel for the machine
3.3. Adding a formfactor configuration file

4. Making and Maintaining Changes

4.1. Bitbake Collections
4.2. Committing Changes
4.3. Package Revision Incrementing

5. Modifying Package Source Code

5.1. Modifying Package Source Code with quilt

4. Platform Development with Poky

1. Software development

1.1. Developing externally using the Anjuta Plugin
1.2. Developing externally using the Poky SDK
1.3. Developing externally in QEMU
1.4. Developing externally in a chroot
1.5. Developing in Poky directly
1.6. Developing with 'devshell'
1.7. Developing within Poky with an external SCM based package

2. Debugging with GDB Remotely

2.1. Launching GDBSERVER on the target
2.2. Launching GDB on the host computer

3. Profiling with OProfile

3.1. Profiling on the target
3.2. Using OProfileUI

1. Reference: Directory Structure

1. Top level core components

1.1. bitbake/
1.2. build/
1.3. meta/
1.4. meta-extras/
1.5. scripts/
1.6. sources/
1.7. poky-init-build-env

2. build/ - The Build Directory

2.1. build/conf/local.conf
2.2. build/tmp/
2.3. build/tmp/cache/
2.4. build/tmp/cross/
2.5. build/tmp/deploy/
2.6. build/tmp/deploy/deb/
2.7. build/tmp/deploy/images/
2.8. build/tmp/deploy/ipk/
2.9. build/tmp/rootfs/
2.10. build/tmp/staging/
2.11. build/tmp/stamps/
2.12. build/tmp/work/

3. meta/ - The Metadata

3.1. meta/classes/
3.2. meta/conf/
3.3. meta/conf/machine/
3.4. meta/conf/distro/
3.5. meta/packages/
3.6. meta/site/

2. Reference: Bitbake

1. Parsing
2. Preferences and Providers
3. Dependencies
4. The Task List
5. Running a Task
6. Commandline
7. Fetchers

3. Reference: Classes

1. The base class - base.bbclass
2. Autotooled Packages - autotools.bbclass
3. Alternatives - update-alternatives.bbclass
4. Initscripts - update-rc.d.bbclass
5. Binary config scripts - binconfig.bbclass
6. Debian renaming - debian.bbclass
7. Pkg-config - pkgconfig.bbclass
8. Distribution of sources - src_distribute_local.bbclass
9. Perl modules - cpan.bbclass
10. Python extensions - distutils.bbclass
11. Developer Shell - devshell.bbclass
12. Packaging - package*.bbclass
13. Building kernels - kernel.bbclass
14. Creating images - image.bbclass and rootfs*.bbclass
15. Host System sanity checks - sanity.bbclass
16. Generated output quality assurance checks - insane.bbclass
17. Autotools configuration data cache - siteinfo.bbclass
18. Other Classes

4. Reference: Images

5. Reference: Features

1. Distro
2. Machine
3. Reference: Images

6. Reference: Variables Glossary

Glossary

7. Reference: Variable Locality (Distro, Machine, Recipe etc.)

1. Distro Configuration
2. Machine Configuration
3. Local Configuration (local.conf)
4. Recipe Variables - Required
5. Recipe Variables - Dependencies
6. Recipe Variables - Paths
7. Recipe Variables - Extra Build Information

8. FAQ

9. Contributing to Poky

1. Introduction
2. Bugtracker
3. Mailing list
4. IRC
5. Links

10. OpenedHand Contact Information

Index

Chapter 1. Introduction

Table of Contents

1. What is Poky?

2. Documentation Overview

3. System Requirements

4. Quick Start

4.1. Building and Running an Image
4.2. Downloading and Using Prebuilt Images

5. Obtaining Poky

5.1. Releases
5.2. Nightly Builds
5.3. Development Checkouts

1. What is Poky?

- Poky is an open source platform build tool. It is a complete software - development environment for the creation of Linux devices. It aids the - design, development, building, debugging, simulation and testing of - complete modern software stacks using Linux, the X Window System and - GNOME Mobile based application frameworks. It is based on - OpenEmbedded - but has been customised with a particular focus. -

Poky was setup to:

Provide an open source Linux, X11, Matchbox, GTK+, GNOME Mobile platform.
Create a focused, stable, subset of OpenEmbedded that can be easily and reliably built and developed upon.
Fully support a wide range of x86 and ARM hardware

OpenedHand is the principle developer and maintainer of Poky and uses it to:

Provide OpenedHand with stable R&D platform we can build and develop upon.
- Demonstrate the skills available within - OpenedHand and provide a showcase for our software products - (such as the Matchbox and - Pimlico software packages and - Sato, the default user interface in Poky). -
Provide a base we can supply to our clients for building and developing their customised platforms.

- Poky is primarily a platform builder which generates filesystem images - based on open source software such as the Kdrive X server, the Matchbox - window manager, the GTK+ toolkit and the D-Bus message bus system. Images - for many kinds of devices can be generated, however the standard example - machines target QEMU system emulation (both x86 and ARM) and the ARM based - Sharp Zaurus series of devices. Poky's ability to boot inside a QEMU - emulator makes it particularly suitable as a test platform for development - of embedded software. -

- An important component integrated within Poky is Sato, a GNOME Mobile - based user interface environment. - It is designed to work well with screens at very high DPI and restricted - size, such as those often found on smartphones and PDAs. It is coded with - focus on efficiency and speed so that it works smoothly on hand-held and - other embedded hardware. It will sit neatly on top of any device - using the GNOME Mobile stack, providing a well defined user experience. -

2. Documentation Overview

- The handbook is split into sections covering different aspects of Poky. - The 'Using Poky' section gives an overview - of the components that make up Poky followed by information about using and - debugging the Poky build system. The 'Extending Poky' section - gives information about how to extend and customise Poky along with advice - on how to manage these changes. The 'Platform Development with Poky' - section gives information about interaction between Poky and target - hardware for common platform development tasks such as software development, - debugging and profiling. The rest of the manual - consists of several reference sections each giving details on a specific - section of Poky functionality. -

- This manual applies to Poky Release 3.1 (Pinky). -

3. System Requirements

- We recommend Debian-based distributions, in particular a recent Ubuntu - release (7.04 or newer), as the host system for Poky. Nothing in Poky is - distribution specific and - other distributions will most likely work as long as the appropriate - prerequisites are installed - we know of Poky being used successfully on Redhat, - SUSE, Gentoo and Slackware host systems. -

On a Debian-based system, you need the following packages installed:

build-essential
python
diffstat
texinfo
texi2html
cvs
subversion
wget
gawk
help2man
bochsbios (only to run qemux86 images)

- Debian users can add debian.o-hand.com to their APT sources (See - http://debian.o-hand.com - for instructions on doing this) and then run - "apt-get install qemu poky-depends poky-scripts" which will - automatically install all these dependencies. OpenedHand can also provide - VMware images with Poky and all dependencies pre-installed if required. -

- Poky can use a system provided QEMU or build its own depending on how it's - configured. See the options in local.conf for more details. -

4. Quick Start

4.1. Building and Running an Image

- If you want to try Poky, you can do so in a few commands. The example below - checks out the Poky source code, sets up a build environment, builds an - image and then runs that image under the QEMU emulator in ARM system emulation mode: -

-$ wget http://pokylinux.org/releases/pinky-3.1.tar.gz
-$ tar zxvf pinky-3.1.tar.gz
-$ cd pinky-3.1/
-$ source poky-init-build-env
-$ bitbake poky-image-sato
-$ runqemu qemuarm
-

Note

- This process will need Internet access, about 3 GB of disk space - available, and you should expect the build to take about 4 - 5 hours since - it is building an entire Linux system from source including the toolchain! -

- To build for other machines see the MACHINE variable in build/conf/local.conf - which also contains other configuration information. The images/kernels built - by Poky are placed in the tmp/deploy/images - directory. -

- You could also run "poky-qemu zImage-qemuarm.bin poky-image-sato-qemuarm.ext2" - within the images directory if you have the poky-scripts Debian package - installed from debian.o-hand.com. This allows the QEMU images to be used standalone - outside the Poky build environment. -

- To setup networking within QEMU see the - QEMU/USB networking with IP masquerading section. -

4.2. Downloading and Using Prebuilt Images

- Prebuilt images from Poky are also available if you just want to run the system - under QEMU. To use these you need to: -

- Add debian.o-hand.com to your APT sources (See - http://debian.o-hand.com for instructions on doing this) -
Install patched QEMU and poky-scripts:
-
```
-$ apt-get install qemu poky-scripts
-
```
-
- Download a Poky QEMU release kernel (*zImage*qemu*.bin) and compressed - filesystem image (poky-image-*-qemu*.ext2.bz2) which - you'll need to decompress with 'bzip2 -d'. These are available from the - last release - or from the autobuilder. -
Start the image:
-
```
-$ poky-qemu <kernel> <image>
-
```
-

Note

- A patched version of QEMU is required at present. A suitable version is available from - http://debian.o-hand.com, it can be built - by poky (bitbake qemu-native) or can be downloaded/built as part of the toolchain/SDK tarballs. -

5. Obtaining Poky

5.1. Releases

Periodically, we make releases of Poky and these are available - at http://pokylinux.org/releases/. - These are more stable and tested than the nightly development images.

5.2. Nightly Builds

- We make nightly builds of Poky for testing purposes and to make the - latest developments available. The output from these builds is available - at http://pokylinux.org/autobuild/ - where the numbers represent the svn revision the builds were made from. -

- Automated builds are available for "standard" Poky and for Poky SDKs and toolchains as well - as any testing versions we might have such as poky-bleeding. The toolchains can - be used either as external standalone toolchains or can be combined with Poky as a - prebuilt toolchain to reduce build time. Using the external toolchains is simply a - case of untarring the tarball into the root of your system (it only creates files in - /usr/local/poky) and then enabling the option - in local.conf. -

5.3. Development Checkouts

- Poky is available from our SVN repository located at - http://svn.o-hand.com/repos/poky/trunk; a web interface to the repository - can be accessed at http://svn.o-hand.com/view/poky/. -

- 'trunk' is where the deveopment work takes place and you should use this if you're - after to work with the latest cutting edge developments. It is possible trunk - can suffer temporary periods of instability while new features are developed and - if this is undesireable we recommend using one of the release branches. -

Chapter 2. Using Poky

Table of Contents

1. Poky Overview

1.1. Bitbake
1.2. Metadata (Recipes)
1.3. Classes
1.4. Configuration

2. Running a Build

3. Installing and Using the Result

3.1. USB Networking
3.2. QEMU/USB networking with IP masquerading

4. Debugging Build Failures

4.1. Task Failures
4.2. Running specific tasks
4.3. Dependency Graphs
4.4. General Bitbake Problems
4.5. Building with no dependencies
4.6. Variables
4.7. Other Tips

- This section gives an overview of the components that make up Poky - following by information about running poky builds and dealing with any - problems that may arise. -

1. Poky Overview

- At the core of Poky is the bitbake task executor together with various types of - configuration files. This section gives an overview of bitbake and the - configuration files, in particular what they are used for, and how they - interact. -

- Bitbake handles the parsing and execution of the data - files. The data itself is of various types; recipes which give - details about particular pieces of software, class data which is an - abstraction of common build information (e.g. how to build a Linux kernel) - and configuration data for machines, policy decisions, etc., which acts as - a glue and binds everything together. Bitbake knows how to combine multiple - data sources together, each data source being referred to as a 'collection'. -

- The directory structure walkthrough - section gives details on the meaning of specific directories but some - brief details on the core components follows: -

1.1. Bitbake

- Bitbake is the tool at the heart of Poky and is responsible - for parsing the metadata, generating a list of tasks from it - and then executing them. To see a list of the options it - supports look at bitbake --help. -

- The most common usage is bitbake packagename where - packagename is the name of the package you wish to build - (from now on called the target). This often equates to the first part of a .bb - filename, so to run the matchbox-desktop_1.2.3.bb file, you - might type bitbake matchbox-desktop. - Several different versions of matchbox-desktop might exist and - bitbake will choose the one selected by the distribution configuration - (more details about how bitbake chooses between different versions - and providers is available in the - 'Preferences and Providers' section). Bitbake will also try to execute any - dependent tasks first so before building matchbox-desktop it - would build a cross compiler and glibc if not already built. -

1.2. Metadata (Recipes)

- The .bb files are usually referred to as 'recipes'. In general, a - recipe contains information about a single piece of software such - as where to download the source, any patches that are needed, - any special configuration options, how to compile the source files - and how to package the compiled output. -

- 'package' can also used to describe recipes but since the same - word is used for the packaged output from Poky (i.e. .ipk or .deb - files), this document will avoid it. -

1.3. Classes

- Class (.bbclass) files contain information which is useful to share - between metadata files. An example is the autotools class which contains - the common settings that any application using autotools would use. The - classes reference section gives details - on common classes and how to use them. -

1.4. Configuration

- The configuration (.conf) files define various configuration variables - which govern what Poky does. These are split into several areas, such - as machine configuration options, distribution configuration options, - compiler tuning options, general common configuration and user - configuration (local.conf). -

2. Running a Build

- First the Poky build environment needs to be setup using the following command: -

-$ source poky-init-build-env
-

- Once the Poky build environment is setup, a target can now be built using: -

-$ bitbake <target>
-

- The target is the name of the recipe you want to build. Common targets are the - images (in meta/packages/images/) - or the name of a recipe for a specific piece of software like - busybox. More details about the standard images - are available in the image reference section. -

3. Installing and Using the Result

- Once an image has been built it often needs to be installed. The images/kernels built - by Poky are placed in the tmp/deploy/images - directory. Running qemux86 and qemuarm images is covered in the Running an Image section. See your - board/machine documentation for information about how to install these images. -

3.1. USB Networking

- Devices commonly have USB connectivity. To connect to the usbnet interface, on - the host machine run: -

-modprobe usbnet
-ifconfig usb0 192.168.0.200
-route add 192.168.0.202 usb0 
-

3.2. QEMU/USB networking with IP masquerading

- On Ubuntu, Debian or similar distributions you can have the network automatically - configured. You can also enable masquerading between the QEMU system and the rest - of your network. To do this you need to edit /etc/network/interfaces to include: -

-allow-hotplug tap0
-iface tap0 inet static
-        address 192.168.7.200
-        netmask 255.255.255.0
-        network 192.168.7.0
-        post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.7.0/24
-        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
-        post-up iptables -P FORWARD ACCEPT
-

- This ensures the tap0 interface will be up everytime you run QEMU - and it will have network/internet access. -

- Under emulation there are two steps to configure for internet access - via tap0. The first step is to configure routing: -

-route add default gw 192.168.7.200 tap0
-

- The second is to configure name resolution which is configured in the - /etc/resolv.conf file. The simplest solution is - to copy it's content from the host machine. -

- USB connections to devices can be setup and automated in a similar way. - First add the following to - /etc/network/interfaces: -

-allow-hotplug usb0
-iface usb0 inet static
-        address 192.168.0.200
-        netmask 255.255.255.0
-        network 192.168.0.0
-        post-up iptables -A POSTROUTING -t nat -j MASQUERADE -s 192.168.0.0/24
-        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
-        post-up iptables -P FORWARD ACCEPT
-

- and then to configure routing on the device you would use: -

-route add default gw 192.168.0.202 usb0
-

4. Debugging Build Failures

- The exact method for debugging Poky depends on the nature of the - bug(s) and which part of the system they might be from. Standard - debugging practises such as comparing to the last - known working version and examining the changes, reapplying the - changes in steps to identify the one causing the problem etc. are - valid for Poky just like any other system. Its impossible to detail - every possible potential failure here but there are some general - tips to aid debugging: -

4.1. Task Failures

The log file for shell tasks is available in ${WORKDIR}/temp/log.do_taskname.pid. - For the compile task of busybox 1.01 on the ARM spitz machine, this - might be tmp/work/armv5te-poky-linux-gnueabi/busybox-1.01/temp/log.do_compile.1234 - for example. To see what bitbake ran to generate that log, look at the run.do_taskname.pid - file in the same directory. -

The output from python tasks is sent directly to the console at present.

4.2. Running specific tasks

Any given package consists of a set of tasks, in most - cases the series is fetch, unpack, patch, configure, - compile, install, package, package_write and build. The - default task is "build" and any tasks this depends on are - built first hence the standard bitbake behaviour. There are - some tasks such as devshell which are not part of the - default build chain. If you wish to run such a task you can - use the "-c" option to bitbake e.g. bitbake - matchbox-desktop -c devshell. -

- If you wish to rerun a task you can use the force option - "-f". A typical usage session might look like:

-% bitbake matchbox-desktop
-[change some source in the WORKDIR for example]
-% bitbake matchbox-desktop -c compile -f
-% bitbake matchbox-desktop

- which would build matchbox-desktop, then recompile it. The - final command reruns all tasks after the compile (basically - the packaging tasks) since bitbake will notice the the - compile has been rerun and hence the other tasks also need - to run again. -

- You can view a list of tasks in a given package by running - the listtasks task e.g. bitbake matchbox-desktop -c - listtasks. -

4.3. Dependency Graphs

- Sometimes it can be hard to see why bitbake wants to build - some other packages before a given package you've specified. - bitbake -g targetname will create - depends.dot and - task-depends.dot files in the current - directory. They show - which packages and tasks depend on which other packages and - tasks and are useful for debugging purposes. -

4.4. General Bitbake Problems

- Debug output from bitbake can be seen with the "-D" option. - The debug output gives more information about what bitbake - is doing and/or why. Each -D option increases the logging - level, the most common usage being "-DDD". -

- The output from bitbake -DDD -v targetname can reveal why - a certain version of a package might be chosen, why bitbake - picked a certain provider or help in other situations where - bitbake does something you're not expecting. -

4.5. Building with no dependencies

- If you really want to build a specific .bb file, you can use - the form bitbake -b somepath/somefile.bb. Note that this - will not check the dependencies so this option should only - be used when you know its dependencies already exist. You - can specify fragments of the filename and bitbake will see - if it can find a unique match. -

4.6. Variables

- The "-e" option will dump the resulting environment for - either the configuration (no package specified) or for a - specific package when specified with the "-b" option. -

4.7. Other Tips

Tip

When adding new packages it is worth keeping an eye open for bad - things creeping into compiler commandlines such as references to local - system files (/usr/lib/ or /usr/include/ etc.). -

Tip

- If you want to remove the psplash boot splashscreen, add "psplash=false" - to the kernel commandline and psplash won't load allowing you to see - the console. It's also possible to switch out of the splashscreen by - switching virtual console (Fn+Left or Fn+Right on a Zaurus). -

Chapter 3. Extending Poky

- This section gives information about how to extend the functionality - already present in Poky, documenting standard tasks such as adding new - software packages, extending or customising images or porting poky to - new hardware (adding a new machine). It also contains advice about how - to manage the process of making changes to Poky to achieve best results. -

1. Adding a Package

- To add package into Poky you need to write a recipe for it. - Writing a recipe means creating a .bb file which sets various - variables. The variables - useful for recipes are detailed in the - recipe reference section along with more detailed information - about issues such as recipe naming. -

- The simplest way to add a new package is to base it on a similar - pre-existing recipe. There are some examples below of how to add - standard types of packages: -

1.1. Single .c File Package (Hello World!)

- To build an application from a single file stored locally requires a - recipe which has the file listed in the SRC_URI variable. In addition - the do_compile and do_install - tasks need to be manually written. The - S variable defines the directory containing the source - code which in this case is set equal to - WORKDIR, the directory BitBake uses for the build. -

-DESCRIPTION = "Simple helloworld application"
-SECTION = "examples"
-LICENSE = "MIT"
-
-SRC_URI = "file://helloworld.c"
-
-S = "${WORKDIR}"
-
-do_compile() {
-	${CC} helloworld.c -o helloworld
-}
-
-do_install() {
-	install -d ${D}${bindir}
-	install -m 0755 helloworld ${D}${bindir}
-}
-

- As a result of the build process "helloworld" and "helloworld-dbg" - packages will be built. -

1.2. Autotooled Package

- Applications which use autotools (autoconf, automake) - require a recipe which has a source archive listed in - SRC_URI and - inherit autotools to instruct BitBake to use the - autotools.bbclass which has - definitions of all the steps - needed to build an autotooled application. - The result of the build will be automatically packaged and if - the application uses NLS to localise then packages with - locale information will be generated (one package per - language). -

-DESCRIPTION = "GNU Helloworld application"
-SECTION = "examples"
-LICENSE = "GPLv2"
-
-SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2"
-
-inherit autotools
-

1.3. Makefile-Based Package

- Applications which use GNU make require a recipe which has - the source archive listed in SRC_URI. - Adding a do_compile step - is not needed as by default BitBake will start the "make" - command to compile the application. If there is a need for - additional options to make then they should be stored in the - EXTRA_OEMAKE variable - BitBake - will pass them into the GNU - make invocation. A do_install task is required - - otherwise BitBake will run an empty do_install - task by default. -

- Some applications may require extra parameters to be passed to - the compiler, for example an additional header path. This can - be done buy adding to the CFLAGS variable, as in the example below. -

-DESCRIPTION = "Tools for managing memory technology devices."
-SECTION = "base"
-DEPENDS = "zlib"
-HOMEPAGE = "http://www.linux-mtd.infradead.org/"
-LICENSE = "GPLv2"
-
-SRC_URI = "ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-${PV}.tar.gz"
-
-CFLAGS_prepend = "-I ${S}/include "
-
-do_install() {
-	oe_runmake install DESTDIR=${D}
-}
-

1.4. Controlling packages content

- The variables PACKAGES and - FILES are used to split an - application into multiple packages. -

- Below the "libXpm" recipe is used as an example. By - default the "libXpm" recipe generates one package - which contains the library - and also a few binaries. The recipe can be adapted to - split the binaries into separate packages. -

-require xorg-lib-common.inc
-
-DESCRIPTION = "X11 Pixmap library"
-LICENSE = "X-BSD"
-DEPENDS += "libxext"
-PE = "1"
-
-XORG_PN = "libXpm"
-
-PACKAGES =+ "sxpm cxpm"
-FILES_cxpm = "${bindir}/cxpm"
-FILES_sxpm = "${bindir}/sxpm"
-

- In this example we want to ship the "sxpm" and "cxpm" binaries - in separate packages. Since "bindir" would be packaged into the - main PN - package as standard we prepend the PACKAGES variable so - additional package names are added to the start of list. The - extra FILES_* - variables then contain information to specify which files and - directories goes into which package. -

1.5. Post Install Scripts

- To add a post-installation script to a package, add - a pkg_postinst_PACKAGENAME() - function to the .bb file - where PACKAGENAME is the name of the package to attach - the postinst script to. A post-installation function has the following structure: -

-pkg_postinst_PACKAGENAME () {
-#!/bin/sh -e
-# Commands to carry out
-}
-

- The script defined in the post installation function - gets called when the rootfs is made. If the script succeeds, - the package is marked as installed. If the script fails, - the package is marked as unpacked and the script will be - executed again on the first boot of the image. -

- Sometimes it is necessary that the execution of a post-installation - script is delayed until the first boot, because the script - needs to be executed the device itself. To delay script execution - until boot time, the post-installation function should have the - following structure: -

-pkg_postinst_PACKAGENAME () {
-#!/bin/sh -e
-if [ x"$D" = "x" ]; then
-# Actions to carry out on the device go here
-else
-exit 1
-fi
-}
-

- The structure above delays execution until first boot - because the D variable points - to the 'image' - directory when the rootfs is being m