Compiling kernels with

From postmarketOS

This page details how to compile a kernel manually using the helper script as well as how to package and install a locally compiled kernel. This workflow can be used to quickly iterate and test during kernel development by using the existing kernel packaging and upgrade process to install a development kernel.

Usually when compiling a kernel, you would install all dependencies and a cross compiler in your host system. To make it easier, we have the script (for fish shell: It sets up an Alpine Linux chroot with all the dependencies by using pmbootstrap internally, exports the environment variables to use the right cross compiler and creates an alias to make. This means, whenever you type make after sourcing that script, it will actually run make in the chroot.

Selecting a kernel

This section details how to fetch the kernel source of an existing postmarketOS device. Existing kernel aports can be found in the pmaports/device directory. Make sure to use your actual device name instead of the example name.

The kernel aport is in the pmaports/device/linux-wiki-example directory. Within the APKBUILD is the source variable which lists the kernel source repository.

After determining the kernel you want to work with, download the source code.

$ git clone
$ cd android_kernel_wiki_example

Preparing the source directory

To compile the current version of the kernel, check out the git revision found in the APKBUILD.

$ git checkout dd65620ba04a8c6ba0e30553c9c95388daefae02 # example

Applying patches

Some kernel aports have patches applied on top of the remote source. You may want to apply these patches if they aren't in the source tree you have checked out.

Our example device wiki-example has a patch which isn't in the git revision we just checked out.

$ git apply pmaports/device/linux-wiki-example/02_fix-example.patch

Compile the kernel

Note The script is not provided when you installed pmbootstrap from pip. You have to install pmbootstrap from git to have it.

The script will set up a build environment based on the target device configured for pmbootstrap.

Make sure to replace the example names with your correct device name. When running pmbootstrap init, the correct target device needs to be selected. Most devices should include a link to their kernel package at the bottom of their wiki page.

$ pmbootstrap init

Run the script (found in the pmbootstrap git repository) once in the kernel source directory to initialize the build environment. If the kernel can only be compiled with GCC6 then pass the --gcc6 flag.

$ source pmbootstrap/helpers/ --gcc6

Copy the defconfig from the kernel aport to the kernel source directory. Replace the defconfig file that your build would use.

$ cp ~/.local/var/pmbootstrap/cache_git/pmaports/device/testing/linux-wiki-example/config-linux-wiki-example.aarch64 arch/arm64/configs/example_defconfig

Build the defconfig and kernel with the following commands.

$ make example_defconfig
$ make

Run the kernel

Post make scripts

Some kernels require extra packaging steps such as dtbtool. The build environment works within the pmbootstrap chroots. The run-script alias can be used to execute scripts within the source or build directory in the chroot.

This example explains how to deal with a device thatr requires dtbtool. Create a script with the dtbtool command named in the kernel source directory.

dtbTool -s 2048 -p "${srcdir}/scripts/dtc/" -o \
	"${builddir}/arch/arm/boot/dt.img" \

Run the script.

$ run-script

Packaging and flashing the kernel

A kernel compiled under can be packaged by pmbootstrap by using the --envkernel build option.

$ pmbootstrap build --envkernel linux-wiki-example

Usually if the device boots to SSH with USB networking and has support for kernel upgrades, you can install the new kernel by sideloading.

$ pmbootstrap sideload linux-wiki-example

After compiling and packaging the kernel, it can be flashed to device using the standard pmbootstrap flash commands. Note that if your kernel includes kernel modules (most mainline kernels do) these will not be installed and some features might break when you boot back up. In this case you can sideload as above once you have a booting kernel.

$ pmbootstrap flasher flash_kernel

Packaging kernels built without envkernel

As of !2175 the envkernel packaging logic can be used to package kernels built directly on the host. This is intended to allow folks who prefer to set up their own kernel building environment to still make use of pmbootstrap for packaging and sideloading the new kernel.

Currently this requires that you use .output as your output directory (add O=.output as an argument to make). With that done just build your kernel as normal and follow the packaging/flashing steps above. Note that the output directory needs to be set for any make invocation, including things like defconfig or menuconfig. If you have a .config in the source tree (instead of in .output) you will get error messages about the source directory not being "clean" when you try to build the kernel with O=.output.


If you want to use the Clangd language server while working on the kernel, you need to generate the compile_commands.json file for your build. The kernel source contains the scripts/clang-tools/ script to do that. It works with envkernel or independent cross compiling, but you will need to tell it where to find the build output (same value as for O=):

$ ./scripts/clang-tools/ -d .output/

If you built using envkernel the compile_commands.json file might contain /mnt/linux/ (the mount point for kernel source inside the chroot) in a few places. You'll need to replace that with the correct path.

If your build was done using GCC (as is the default with envkernel) the build commands might use some options Clang and thus Clangd don't understand, and you might need to tell Clang the target architecture. You can override compile flags in a .clangd config file. The config might look similar to this, please check which options you really need for your own build (incorrect options could also cause issues):

  Compiler: clang
    - -xc  # C only, no C++
    - --target=aarch64
    - -fno-allow-store-data-races
    - -fconserve-stack
    - -march=*
    - -mabi=*

See also