Difference between revisions of "Kernels/Arch Build System"

From ArchWiki
Jump to: navigation, search
(modify config file using 'echo')
m (Changing prepare(): cofig to config - typo)
 
(54 intermediate revisions by 25 users not shown)
Line 1: Line 1:
 
[[Category:Kernel]]
 
[[Category:Kernel]]
 
[[de:Eigenen Kernel erstellen]]
 
[[de:Eigenen Kernel erstellen]]
[[it:Kernels/Compilation/Arch Build System]]
+
[[it:Kernels/Arch Build System]]
[[ru:Custom Kernel Compilation with ABS]]
+
[[ja:カーネル/コンパイル/Arch Build System]]
[[zh-CN:Kernels/Compilation/Arch Build System]]
+
[[ru:Kernels/Arch Build System]]
 +
[[zh-cn:Kernels/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 {{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.
  
 
==Getting the Ingredients==
 
==Getting the Ingredients==
  
{{bc|# pacman -S abs base-devel}}
+
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 {{ic|build}} directory in your user home first.
 +
  $ cd ~/
 +
  $ mkdir build
 +
  $ cd build/
  
First of all, you need a clean kernel to start your customization from. Fetch the kernel package files from ABS:
+
[[Install]] the {{Pkg|abs}} package and the {{Grp|base-devel}} package group.
  
{{bc|1=$ ABSROOT=. abs core/linux}}
+
You need a clean kernel to start your customization from. Fetch the kernel package files from ABS into your build directory by running:
 +
 
 +
$ 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.
 
If you have some problem with the firewall blocking the rsync port, you can try with -t, which uses the tarball to sync.
  
{{bc|1=$ ABSROOT=. abs core/linux -t}}
+
$ ABSROOT=. abs core/linux -t
  
 
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 {{ic|pkgbase}} for your custom package name, e.g.:
+
 
 +
Edit {{ic|PKGBUILD}} and look for the {{ic|pkgbase}} parameter.  Change this to your custom package name, e.g.:
 +
 
 
   pkgbase=linux-custom
 
   pkgbase=linux-custom
  
If you dont want to build -headers or -docs package, remove them from {{ic|pkgname}} at the bottom of the file, e.g.:
+
Depending on the PKGBUILD you may have to also rename {{ic|linux.install}} to match the modified {{ic|pkgbase}} (e.g. for {{Pkg|linux-grsec}}).
  pkgname=("${pkgbase}")
+
  
===Changing build()===
+
===Changing prepare()===
If you need to change a few config options you can use the default one and append your options the config file:
+
$ echo '
+
CONFIG_DEBUG_INFO=y
+
CONFIG_FOO=n
+
' >> 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.:
+
In prepare function, you can apply needed kernel patch or change kernel build configuration.
 +
 
 +
If you need to change a few config options you can edit config file in the source. Change or copy existing config file to {{ic|config.x86_64}} for 64bit system and {{ic|config}} for 32bit system.
 +
 
 +
Or you can use GUI tool to tweak the options. Uncomment one of the possibilities shown in the prepare() function of the PKGBUILD, e.g.:
 
{{hc|PKGBUILD|
 
{{hc|PKGBUILD|
 
...
 
...
Line 47: Line 55:
 
}}
 
}}
  
 +
{{Warning| systemd has a number of kernel configuration requirements for general use, for specific usecases (e.g., UEFI) and for specific systemd functionality (e.g., bootchart). Failure to meet these requirements can result in your system being degraded or unusable. The list of required and recommended kernel CONFIGs can be found in {{ic|/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.}}
  
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.
+
==== Load existing .config ====
 +
{{Remove|Simply overide {{ic|config.x86_64}} or {{ic|config}} should be enough.}}
 +
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.
  
{{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.}}
+
{{Note|1=If you uncomment and use 'make menuconfig' in prepare(), 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 BBS#173504]
 +
}}
 +
 
 +
===Generate new checksums===
 +
As we modified config, we need to generate new checksums by running:
 +
$ updpkgsums
  
 
==Compiling==
 
==Compiling==
{{Tip|[[Makepkg#MAKEFLAGS|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
+
You can now proceed to compile your kernel by the usual command {{ic|makepkg}}
{{ic|makepkg}}
+
 
 
If you have chosen an interactive 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.}}
+
  $ makepkg -s
 +
 
 +
The {{ic|-s}} parameter will download any additional dependencies used by recent kernels such as xml and docs.
 +
 
 +
{{Note|
 +
* Kernel sources are [https://www.kernel.org/signature.html#kernel-org-web-of-trust PGP signed], and makepkg will attempt to verify them. See [[Makepkg#Signature checking]] for details.
 +
* [[Makepkg#MAKEFLAGS|Running compilation jobs simultaneously]] can reduce compilation time significantly on multi-core systems.}}
  
 
==Installing==
 
==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>
+
After running ''makepkg'', you can have a look at the {{ic|linux.install}} file. You will see that some variables have changed.  
 +
 
 +
Now, you only have to install the package as usual. Best practice is to install kernel headers first as they will be needed (e.g. to install the [[NVIDIA#Alternate install: custom kernel|nvidia]]{{Broken section link}} driver) for the custom kernel later.
 +
# pacman -U ''kernel-headers_package''
 +
  # pacman -U ''kernel_package''
  
 
==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 to choose from.
+
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]] 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.

Latest revision as of 04:54, 10 September 2016

See Kernels for the main article.

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

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 abs package and the base-devel package group.

You need a clean kernel to start your customization from. Fetch the kernel package files from ABS into your build directory by running:

$ 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

Edit PKGBUILD and look for the pkgbase parameter. Change this to your custom package name, e.g.:

 pkgbase=linux-custom

Depending on the PKGBUILD you may have to also rename linux.install to match the modified pkgbase (e.g. for linux-grsec).

Changing prepare()

In prepare function, you can apply needed kernel patch or change kernel build configuration.

If you need to change a few config options you can edit config file in the source. Change or copy existing config file to config.x86_64 for 64bit system and config for 32bit system.

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

PKGBUILD
...
  # 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
...
Warning: systemd has a number of kernel configuration requirements for general use, for specific usecases (e.g., UEFI) and for specific systemd functionality (e.g., bootchart). Failure to meet these requirements can result in your system being degraded or unusable. The list of required and recommended kernel CONFIGs can be found in /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.

Load existing .config

Tango-edit-cut.pngThis section is being considered for removal.Tango-edit-cut.png

Reason: Simply overide config.x86_64 or config should be enough. (Discuss in Talk:Kernels/Arch Build System#)

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 prepare(), 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 BBS#173504

Generate new checksums

As we modified config, we need to generate new checksums by running:

$ updpkgsums

Compiling

You can now proceed to compile your 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.

 $ makepkg -s

The -s parameter will download any additional dependencies used by recent kernels such as xml and docs.

Note:

Installing

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 package as usual. Best practice is to install kernel headers first as they will be needed (e.g. to install the nvidia[broken link: invalid section] driver) for the custom kernel later.

# pacman -U kernel-headers_package
# 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 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.