The [[Arch Build System]] can be used to build a custom kernel based on the official {{Pkg|linux}} 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.

The [[Arch Build System]] can be used to build a custom kernel based on the official {{Pkg|linux}} 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.

−

==Install ABS==

+

==Getting the Ingredients==

{{bc|# pacman -S abs base-devel}}

{{bc|# pacman -S abs base-devel}}

−

To get the whole tree run:

+

First of all, you need a clean kernel to start your customization from. Fetch the kernel package files from ABS:

−

{{bc|# abs}}

+

{{bc|1=$ ABSROOT=. abs core/linux}}

−

See [[Arch Build System]] for more information.

+

If you have some problem with the firewall blocking the rsync port, you can try with -t, which uses the tarball to sync.

−

==Getting the Ingredients==

+

{{bc|1=$ ABSROOT=. abs core/linux -t}}

−

First of all, you need a clean kernel to start your customization from. In this article I will assume that you use the official kernel package. So create a folder you want to work in and get the kernel package files from ABS (after syncing):

+

−

+

−

{{ic|cp /var/abs/core/linux/* <working_dir>/}}

+

Then, get any other file you need (e.g. custom configuration files, patches, etc.) from the respective sources.

Then, get any other file you need (e.g. custom configuration files, patches, etc.) from the respective sources.

==Modifying the PKGBUILD==

==Modifying the PKGBUILD==

−

Modify the PKGBUILD of the official linux package.

+

Modify {{ic|pkgbase}} for your custom package name, e.g.:

+

pkgbase=linux-custom

−

===Changing pkgname===

+

===Changing build()===

−

The first lines will look like this:

+

If you need to change a few config options you can use the default one and append your options the config file:

−

{{hc|PKGBUILD|2=

+

$ echo '

−

# $Id: PKGBUILD 130991 2011-07-09 12:23:51Z thomas $

+

CONFIG_DEBUG_INFO=y

−

# Maintainer: Tobias Powalowski <tpowa@archlinux.org>

+

CONFIG_FOO=n

−

# Maintainer: Thomas Baechler <thomas@archlinux.org>

+

' >> config.x86_64

−

pkgbase=linux

+

Or you can use GUI tool to tweak the options. Uncomment one of the possibilities shown in the build() function of the PKGBUILD, e.g.:

As you see, there is a commented line for building a kernel with a different name. All you need to do here is to uncomment that line, change the suffix '-custom' to your needs, and comment the standard line. And if you want two kernels (ARCH and test) you need disable section conflicts. Files linux.install and linux.preset must be linux-custom.install and linux-custom.preset. For instance, your file could become:

#next lines give you problems with nvidia drivers which depend on kernel

+

−

#provides=('kernel26')

+

−

#conflicts=('kernel26')

+

−

#replaces=('kernel26')

+

−

}}

+

−

+

−

{{Note|This assumes that you do not need to recompile linux-headers, -manpages or -docs. If you do, change all three strings accordingly.}}

+

−

+

−

Now, all the variables of your package will be changed according to the new name. For instance, after installing the package the modules will be located at {{ic|/lib/modules/<kernel_release>-test/}}.

+

−

+

−

===Changing build()===

+

−

You probably need a custom .config file for your kernel. You can uncomment one of the possibilities shown in the build() function of the PKGBUILD, e.g.:

+

{{hc|PKGBUILD|

{{hc|PKGBUILD|

...

...

Line 67:

Line 45:

}}

}}

−

If you have already a kernel config file, I suggest to uncomment one interactive config tool, such as nconfig, and load your config from there. This avoids problems with kernel naming I have met with other methods.

−

{{Note|If you uncomment ''return 1'', you can change to the kernel source directory after makepkg finishes extraction and then make nconfig. This lets you configure the kernel over multiple sessions. When you're ready to compile, copy the .config file over top of either config or config.x86_64 (depending on your architecture), comment ''return 1'' and use '''makepkg -i'''. But not use this for custom patch, put you patch commands after these lines. If you do patch manually bztar unpack and replace your patch.}}

+

If you have already a kernel {{ic|.config}} file, uncommenting one of the interactive config tools, such as {{ic|nconfig}}, and loading your {{ic|.config}} from there avoids any problems with kernel naming that may otherwise occur - except in the case of at least make menuconfig. See note.

−

===Changing the package_linux() function===

+

{{Note|If you uncomment and use 'make menuconfig' in build(), then use the menuconfig gui to load your existing config, you will run into problems with conflicting files in the end package. This is because you will overwrite the default config that PKGBUILD has modified to provide a unique install path, specifically the LOCALVERSION and LOCALVERSION_AUTO config options. To fix this, simply re-set LOCALVERSION to your custom kernel naming and LOCALVERSION_AUTO&#61;n while still in menuconfig. For details, see https://bbs.archlinux.org/viewtopic.php?id&#61;173504 }}

−

Now, you have to write a custom function to tell your system how to install the package. This is most easily done by changing the name of the package_linux() function to package_linux-test(), and adapting the instructions to your needs. If you have no particular needs, your package_linux-test() should look like this:

+

−

{{hc|PKGBUILD|2=

+

{{Note|If you uncomment ''return 1'', you can change to the kernel source directory after makepkg finishes extraction and then make nconfig. This lets you configure the kernel over multiple sessions. When you're ready to compile, copy the .config file over top of either config or config.x86_64 (depending on your architecture), comment ''return 1'' and use '''makepkg -i'''. But do not use this for custom patches; put your patch commands after these lines. If you do patch manually bztar unpack and replace your patch.}}

−

...

+

−

package_linux-test() {

+

−

pkgdesc="The Linux Kernel and modules"

+

−

...

+

−

}

+

−

}}

+

==Compiling==

==Compiling==

Line 86:

Line 57:

You can now proceed to compile you kernel by the usual command

You can now proceed to compile you kernel by the usual command

{{ic|makepkg}}

{{ic|makepkg}}

−

If you have chosen an inteactive program for configuring the kernel parameters (like menuconfig), you need to be there during the compilation.

+

If you have chosen an interactive program for configuring the kernel parameters (like menuconfig), you need to be there during the compilation.

−

{{Note|A kernel needs some time to be compiled. 1h is not unusual.}}

+

{{Note|A kernel needs some time to be compiled. 1h is not unusual. On recent systems with a SSD it usually takes less than ten minutes.}}

==Installing==

==Installing==

Line 95:

Line 66:

==Boot Loader==

==Boot Loader==

−

Now, the folders and files for your custom kernel have been created, e.g. {{ic|/boot/vmlinuz-linux-test}}. To test your kernel, update your bootloader (/boot/grub/menu.lst for GRUB) and add new entries ('default' and 'fallback') for your custom kernel. That way, you can have both the stock kernel and the custom one in parallel.

+

Now, the folders and files for your custom kernel have been created, e.g. {{ic|/boot/vmlinuz-linux-test}}. To test your kernel, update your bootloader (grub-mkconfig for GRUB) and add new entries ('default' and 'fallback') for your custom kernel. That way, you can have both the stock kernel and the custom one to choose from.

Revision as of 17:13, 25 December 2013

The Arch Build System can be used to build a custom kernel based on the official linux 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.

If you have already a kernel .config file, uncommenting one of the interactive config tools, such as nconfig, and loading your .config from there avoids any problems with kernel naming that may otherwise occur - except in the case of at least make menuconfig. See note.

Note: If you uncomment and use 'make menuconfig' in build(), then use the menuconfig gui to load your existing config, you will run into problems with conflicting files in the end package. This is because you will overwrite the default config that PKGBUILD has modified to provide a unique install path, specifically the LOCALVERSION and LOCALVERSION_AUTO config options. To fix this, simply re-set LOCALVERSION to your custom kernel naming and LOCALVERSION_AUTO=n while still in menuconfig. For details, see https://bbs.archlinux.org/viewtopic.php?id=173504

Note: If you uncomment return 1, you can change to the kernel source directory after makepkg finishes extraction and then make nconfig. This lets you configure the kernel over multiple sessions. When you're ready to compile, copy the .config file over top of either config or config.x86_64 (depending on your architecture), comment return 1 and use makepkg -i. But do not use this for custom patches; put your patch commands after these lines. If you do patch manually bztar unpack and replace your patch.

Compiling

You can now proceed to compile you kernel by the usual command
makepkg
If you have chosen an interactive program for configuring the kernel parameters (like menuconfig), you need to be there during the compilation.

Note: A kernel needs some time to be compiled. 1h is not unusual. On recent systems with a SSD it usually takes less than ten minutes.

Installing

After the 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 package as usual with pacman (or equivalent program):

# pacman -U <kernel_package>

Boot Loader

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 (grub-mkconfig for GRUB) and add new entries ('default' and 'fallback') for your custom kernel. That way, you can have both the stock kernel and the custom one to choose from.