Difference between revisions of "Kernel/Arch Build System"

From ArchWiki
Jump to: navigation, search
m (Changing build(): fix grammar)
(Modifying the PKGBUILD: makepkg --pkg exists)
Line 24: Line 24:
Modify {{ic|pkgbase}} for your custom package name, e.g.:
Modify {{ic|pkgbase}} for your custom package name, e.g.:
If you dont want to build -headers or -docs package, remove them from {{ic|pkgname}} at the bottom of the file, e.g.:
===Changing build()===
===Changing build()===

Revision as of 15:50, 17 September 2013

zh-CN:Kernels/Compilation/Arch Build System 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.

Getting the Ingredients

# pacman -S abs base-devel

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

$ ABSROOT=. abs core/linux

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

$ ABSROOT=. abs core/linux -t

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

Modifying the PKGBUILD

Modify pkgbase for your custom package name, e.g.:


Changing build()

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

$ echo '
' >> config.x86_64

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.:

  # load configuration
  # Configure the kernel. Replace the line below with one of your choice.
  #make menuconfig # CLI menu for configuration
  make nconfig # new CLI menu for configuration
  #make xconfig # X-based configuration
  #make oldconfig # using old config from previous kernel version
  # ... or manually edit .config

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.

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.


Tip: Running compilation jobs simultaneously can reduce compilation time significantly on multi-core systems.

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.


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 (/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 to choose from.