Kernel/Arch Build System
See Kernels for the main article.
The Arch Build System can be used to build a custom kernel based on the official package. This compilation method can automate the entire process, and is based on a very well tested package. You can edit the PKGBUILD to use a custom kernel configuration or add additional patches.
Getting the Ingredients
Since you'll be using makepkg, follow the best practices outlined there first. For example, you cannot run makepkg as root/sudo. Therefore, create a
build directory in your user home first.
$ cd ~/ $ mkdir build $ cd build/
Install the package and the package group.
You need a clean kernel to start your customization from. Fetch the latest kernel package files from ABS into your build directory by running:
$ asp update linux $ asp checkout linux
At this point, the directory tree looks like:
~/build/linux/-+ +--60-linux.hook +--90-linux.hook +--config +--linux.install +--linux.preset \__PKGBUILD
Then, get any other file you need (e.g. custom configuration files, patches, etc.) from the respective sources.
Modifying the PKGBUILD
PKGBUILD and look for the
pkgbase parameter. Change this to your custom package name, e.g.:
Depending on the PKGBUILD you may have to also rename
linux.install to match the modified
prepare() function, you can apply needed kernel patches or change kernel build configuration.
If you need to change a few config options you can edit config file in the source.
Or you can use GUI tool to tweak the options. Comment
make olddefconfig in the prepare() function of the PKGBUILD, and add your favorite tool:
... msg2 "Setting config..." cp ../config .config #make olddefconfig make nconfig # new CLI menu for configuration #make menuconfig # CLI menu for configuration #make xconfig # X-based configuration #make oldconfig # using old config from previous kernel version # ... or manually edit .config ...
/usr/share/doc/systemd/README. Check them before you compile.These requirements also change over time. Because Arch assumes you are using the official kernel, there will be no announcement of these changes. Before you install a new version of systemd, check the version release notes to make sure your current custom kernel meets any new systemd requirements.
Generate new checksums
#Changing prepare() suggests a possible modification to
$_srcname/.config. Since this path is not where downloading the package files ended, its checksum was not checked by makepkg (which actually checked
If you replaced the downloaded
config with another config file before running makepkg, Install the package.
Which will generate new checksums by running:
You can now proceed to compile your kernel by the usual command
If you have chosen an interactive program for configuring the kernel parameters (like menuconfig), you need to be there during the compilation.
$ makepkg -s
-s parameter will download any additional dependencies used by recent kernels such as xml and docs.
After running makepkg, you can have a look at the
linux.install file. You will see that some variables have changed.
Now, you only have to install the packages as usual. Best practice is to install both packages together as they might be both needed (e.g. DKMS.)
# pacman -U kernel-headers_package kernel_package
Now, the folders and files for your custom kernel have been created, e.g.
/boot/vmlinuz-linux-test. To test your kernel, update your bootloader configuration file and add new entries ('default' and 'fallback') for your custom kernel. If you renamed your kernel in the PKGBUILD pkgbase you may have to rename the initramfs.img in your $build/pkg/kernel/etc before installing with pacman. That way, you can have both the stock kernel and the custom one to choose from.
Assuming one has an arch kernel source that he wants to update, one method to do that is with https://git.archlinux.org/linux.git. Follows a concrete example. In what follows, the paths are relative to the top kernel source directory, which is assumed at ~/build/linux/. In general, arch sets an arch kernel source with two local git repositories. The one at archlinux-linux/ is a local bare git repository pointing to git://git.archlinux.org/linux.git. The other one is at src/archlinux-linux, pulling from the first repository. Possible local patches, and building, is expected at src/archlinux-linux/.
For this example, the HEAD of the locally installed bare git repository source at archlinux-linux/ was initially pointing to
4010b622f1d2 Merge branch 'dax-fix-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm, which was, or still is, somewhere between v5.2.5-arch1 and v5.2.6-arch1.
$ cd archlinux-linux/ $ git fetch --verbose
That was fetching v5.2.7-arch1, which was the newest archlinux tag.
$ cd ../src/archlinux-linux/ $ git checkout master $ git pull $ git fetch --tag $ git branch --verbose 5.2.7-arch1 v5.2.7-arch1 $ git checkout 5.2.7-arch1
.scmversion is empty here. In fact, it seems to be always empty, no matter what arch version is checked out. Other than the directory archlinux-linux/, and the version file, all other 4 files at src/ are arch specific files, and are symlinked to files by the same name on its parent directory.
$ ls ../ 60-linux.hook archlinux-linux linux.preset 90-linux.hook config version
The up to date version of these 4 files, as well as the newer PKGBUILD, can be pulled in by asp update, followed by asp export linux:
$ cd ../../ $ asp update $ asp export linux $ mv --verbose linux linux-tmp
$ ls linux-tmp 60-linux.hook config linux.preset 90-linux.hook linux.install PKGBUILD
Now one should manually merge, probably copy, the files at linux-tmp to the files by the same name at its parent directory. After which, the directory linux-tmp/, with all the files in it, can be deleted. Then run manually most, if not all, of PKGBUILD::prepare().
At this point,
makepkg --verifysource should succseed. And
makepkg --noextract should be able to build the packages as if the source was extracted by
- https://kernel.org/doc/Documentation/kbuild/kconfig.txt and the parent directory