Ce document explique aux utilisateurs avancés comment recompiler le noyau à partir des sources. Notez néanmoins, qu’en compilanc et l’utilisant un tel noyau, on ne doit pas s’attendre à une quelconque assistance de l’équipe noyau de Fedora ; vous êtes en quelque sorte livré à vous-même si quelque chose ne se passe pas comme vous l’attendez. Mais vous êtes un utilisateur avancé, c'est pourquoi vous pouvez vous en sortir, n’est-ce pas ?
Ceci dit, un utilisateur avancé peut être conduit à recompiler un noyau personnalisé pour des tas de raisons :
- pour appliquer des correctifs à des fins de test qu'il a lui-même généré ou obtenu d’une tierce source ;
- pour reconfigurer un noyau existant ;
- pour en apprendre un peu plus sur le noyau et son développement;
- etc.
Dépendances nécessaires à la re-compilation du noyau
Toutes ne sont pas nécessaires dans toutes les méthodes mais la liste de dépendances fournie ici est plutôt satisfaisante.
# dnf install fedpkg fedora-packager rpmdevtools ncurses-devel pesign
Exécutez la commande suivante depuis le dossier racine de l’arbre du noyau une fois que vous l’avez contrôlé.
# dnf builddep kernel.spec
si vous envisagez d'exécuter make xconfig
# dnf install qt3-devel libXi-devel gcc-c++
Assurez-vous également d’avoir ajouté l’utilisateur effectuant la compilation à /etc/pesign/users et exécutez le script d'autorisation des utilisateurs :
# /usr/libexec/pesign/pesign-authorize-users
Il faut noter que pesign-rh-test-certs est tiré automatiquement pour certains, mais pas pour tous. Cela dépend de la façon dont vous avez installé pesign. C’est mieux de vous assurer qu’il est installé.
Compilation du noyau depuis l’arbre source de Fedora
Assurez-vous que toutes les dépendances sont installées.
$ fedpkg clone kernel
Vous devrez probablement extraire les sources de façon anonyme sauf à disposer d’un compte de développeur Fedora.
$ fedpkg clone -a kernel
Au moment d’écrire cet article, le noyau est géré à partir de git. Chacune des versions de Fedora est dans une branche séparée. rawhide suit la branche master. Pour obtenir l’arbre d’une version particulière, vous pouvez utiliser git checkout depuis le dossier de tête de votre arbre des sources nouvellement créé.
P. ex. pour Fedora 23,
$ git checkout origin/f23
Vous pouvez désormais effectuer n'importe quelle modification/personnalisation que vous souhaitez avant de générer les rpm et de les installer. Vous pouvez envisager de décommenter
# define buildid .local
pour éviter les conflits, p. ex. :
%define buildid .local
Une fois terminé, générez les rpm appropriés avec :
$ fedpkg local
Les rpm sont générés dans un sous-dossier $ARCH et peuvent alors être installés :
$ dnf install --nogpgcheck ./x86_64/kernel-$version.rpm
Compilation d’un noyau sans messages de débogage
Les noyaux branchés sont compilés avec debugging activé par défaut dans les premiers stades de la version pour aider les développeurs. Pour compiler un noyau sans les informations de débogage, vous pouvez suivre les instruction données ci-dessus pour extraire (checkout), puis faire :
$ make release
$ fedpkg local
Activation des options de configuration
Si vous avez besoin d’ajuster certaines options de configuration pour votre compilation, vous pouvez faire des modifications dans le fichier kernel-local. Ces changements seront pris en compte lors de votre compilation.
Mise à jour
$ cd kernel kernel $ git status
votre arbre sera sale dans configs and kernel.spec
kernel $ git stash
mettez vos modifications de côté ainsi votre arbre sera propre
kernel $ git pull origin
faite une mise à jour au dernier arbre depuis git fedpkg
Désormais, vous pouvez exécuter n’importe quelle commande que vous voulez (p. ex. make release )
Compiler un noyau depuis les arbres explosés de git
Fedora maintient un arbre git qui contient les correctifs appliqués au sources vanilla.
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/jwboyer/fedora.git
$ git checkout -b my_branch kernel-4.7.4-200.fc24
vous pouvez maintenant compiler le noyau en suivant les instructions normales du noyau. Cet arbre est utile pour générer des correctifs qui peuvent être appliqué à kernel.spec.
Compilation d’un noyau à partir des RPM sources
Les instructions pour cela se trouvent sur une page séparée. En général, vous devriez utiliser l’une des autres méthodes pour compiler un noyau car elles sont plus faciles.
Compilation des modules du noyau seulement (Modules hors de l’arbre)
Cette section intéresse des utilisateurs seulement intéressés par le travail sur un module du noyau, et qui ne veulent pas compiler un noyau personnalisé dans son entièreté. Il n’est pas nécessaire de télécharger et de reconstruire le noyau entier pour compiler un module. Pour compiler un module pour le noyau courant, seul le paquet kernel-devel correspondant est nécessaire. Exécutez les commandes suivantes pour installer le paquet kernel-devel avec dnf.
- dnf install kernel-devel
You can build against any kernel version, as long as you have kernel and kernel-devel packages installed for that version. The rest of this section assumes we're building for the running kernel; if not, replace uname -r
As a simple example, to build the foo.ko module from foo.c, create the following Makefile in the directory containing the foo.c file:
obj-m := foo.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) default: [TAB]$(MAKE) -C $(KDIR) M=$(PWD) modules
[TAB] Denotes a tab character which must come first for makefile lines containing commands.
Then, issue the make command to build the foo.ko module.
The above is a helpful local Makefile wrapper invoking kbuild; in general you can simply do things like
# make -C /lib/modules/`uname -r`/build M=`pwd` modules # make -C /lib/modules/`uname -r`/build M=`pwd` clean # make -C /lib/modules/`uname -r`/build M=`pwd` modules_install
etc to build those targets.
Building Vanilla upstream kernel
Sometimes a Fedora developer may ask you to try building and installing an upstream kernel (possibly with a patch added) for testing. If there are multiple iterations, it may be quicker for you to do this than for the developer to turn around several RPMs.
Existing Fedora Vanilla packages
There is an effort underway for packaging vanilla kernels. See if this meets your needs first
Getting the sources
Clone a kernel tree from kernel.org
The README file in the top-level directory provides very good build instructions, including how to direct the build to a particular directory, the necessary make targets, and the order in which to issue them. Save time by reviewing the Documentation directory and its sub-directories containing informative ".txt" files. View the top level Makefile for kernel version information.
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
This will clone the entire upstream tree. This may take a while depending on your connection speed. (While the tree is syncing, why not take the time to update some steps on this wiki that are inevitably out of date?)
$ cd linux
Double check what baseline is being used and check out a new one if necessary:
$ git checkout v4.5.2
Applying patches
The patch method
If you were asked to apply any patches by the developer, this is the stage at which we would do so. These would typically be applied using a command something like..
$ cat ~/testpatch.diff | patch -p1
If you have to try multiple different patches individually, you can unapply the previous one after testing by adding -R on the end of the above command.
The git method
Most developers these days generate patches using git and you can use git to help apply patches. You can do:
$ git am -3 <patch file>
This will create a git commit of a single patch in your tree.
Configuring the kernel
Consider using the make targets "mrproper" and "menuconfig" as specified in the top-level README file. The "menuconfig" target is an alternative to "oldconfig" and pops up a menu that allows you to easily set virtually all build options. Accepting the defaults is generally fine, although you can use the "General Setup->Local version" option to append a label to your build instead of tweaking "EXTRAVERSION" in the .config file.
Chances are that the kernel you are running is older than the one you are about to configure. This means there will be new options. There are several possibilities here.
- If the developer has pointed you at a specific config file to use, save it in the linux directory with the filename .config
- You can take your existing .config file by using the command
cp /boot/config-uname -r* .config
When you run the next step, you'll be asked (potentially lots of) questions about all the new options. Just hitting return 'should' always pick the safe decision for each option. However, it's worth taking care and reading each option, as this isn't always the case, and they may introduce new features your distro isn't capable of running, which may result in a non-booting system.
- FIXME how to grab a rawhide config
With the config in place, you are now ready to move on to the next step.
Building the kernel
$EDITOR Makefile
Change the EXTRAVERSION line to add something on the end. For example, if it reads "EXTRAVERSION = -rc5" change it to "EXTRAVERSION = -rc5-dave" (what you choose is only relevant for the final part of this procedure)
$ make oldconfig
$ make bzImage
$ make modules
(become root)
# make modules_install
# make install
You have now built and installed a kernel. It will show up in the grub menu next time you reboot.
Rebuilding
If you have been asked to try several different things, the procedure once you have already built the tree once is mostly the same. A make clean is recommended between builds. This will leave the .config in place, so you can skip that step above and proceed straight to the make bzImage part of the steps above. Because we installed ccache in the first step, subsequent builds may go a lot faster as the compiler hits files that haven't changed since the last time it built them.
Cleaning up
Once you have tested the kernel, and you've booted back to one of your kernels installed from an RPM, you can clean up the files that the above procedure installed by becoming root, and calling these commands. (Be sure to get the kernel version correct!) Remember above, we changed EXTRAVERSION to add a 'tag' to the kernel ? All the files it installed will have this as part of the filename. So you should be able to use wildcards to delete them safely using commands similar to those below. (Just replace 'dave' with whatever tag you chose)
rm -f /boot/config-2.6.*dave* /boot/initrd-2.6.*dave* /boot/vmlinuz-*dave* /boot/System.map-*dave* rm -rf /lib/modules/2.6*dave*
Finally, you will need to remove the kernel as an option to your bootloader. This will change from architecture to architecture. For x86, (as root), edit /boot/grub2/grub.cfg or /boot/efi/EFI/fedora/grub.cfg if you have EFI enabled and delete the four lines relating to your kernel (They should be easy to spot, they'll be the ones with your tag). They'll look something like this..
title Fedora Core (2.6.22-rc3-dave) root (hd0,0) kernel /vmlinuz-2.6.22-rc3-dave ro root=/dev/md0 initrd /initrd-2.6.22-rc3-dave.img