Proxmox 2 : compilation d’un kernel OpenVZ à partir des sources

Comme dirait Luke : même pas mal ! (d’abord…)

A part occuper (un peu) les geeks et frimer (bêtement) sur IRC, ça sert à quoi ?

Si comme bibi vous avez soumis un bug auprès des développeurs d’OpenVZ, la première chose qu’ils vont vous demander c’est, justement, de reproduire ledit bug avec un kernel OpenVZ « stock ». Donc là, forcément, pas moyen, va falloir s’y coller.

Sinon, et c’est ce qui m’intéressait le plus, en ayant accès aux sources il devient alors possible de modifier certains modules du noyau car, croyez le ou non, certains paramètres utiles sont hardcoded. Non seulement c’est mal mais en plus ça ennuie tout le monde.

Bref, je voulais juste augmenter la taille de la file d’attente du scheduler SFQ (Stochastic Fair Queue) mais pour cela, il est nécessaire de modifier directement les valeurs dans le code source.

Étape 1/10 : récupérer le « Source RPM » qui va bien même qu’il y a tout dedans

Pour cela, direction l’espace de download d’OpenVZ : http://download.openvz.org/kernel/

La branche stable actuelle est la « rhel6-2.6.32 » donc z’allions fouiller à l’intérieur et nous poser sagement dans le répertoire « current ». Là, parmi les différents RPM, il y en a un qui contient le mot « src » (flash, flash…) et il est facile à trouver vu que c’est le plus gros.

Ensuite, tant qu’on y est, nous allons récupérer la config du noyau adéquate dans le sous répertoire « configs ». Deux choix possibles en fonction de votre processeur,  32 ou 64 bits.

Mais, j’aperçois quelques feignasses dans le fond, alors voici le lien direct : lien-magique-toujours-à-jour-vers-le-dernier-noyau-openvz

Bon, ok, elle est nulle mais comme le lien change à chaque mise à jour, il est plus sûr de chercher le bon fichier soi-même.

Étape 2/10 : décompresser le « Source RPM » dans /usr/src/vzkernel

Note : si vous êtes sous Proxmox (on sait jamais hein…), le mieux est de vous créer un container OpenVZ et de jouer à l’intérieur.

Donc, z’avions notre gros RPM téléchargé dans « /usr/src », maintenant on va l’extraire avec l’utilitaire adapté :

apt-get install rpm2cpio cpio

Ensuite c’est du billard :

mkdir /usr/src/vzkernel

cd /usr/src/vzkernel

rpm2cpio /usr/src/vzkernel-2.6.32-xxxxxxxxxx.x.src.rpm | cpio -vid

Parmi tous les fichiers extraits, seuls deux nous intéressent : le plus volumineux (linux-2.6.32-xxx.xx.x.xxx.tar.bz2) et celui qui contient les patchs à appliquer (patch-xxxxxxxxxx).

Étape 3/10 : décompresser le vrai kernel dans « /usr/src/linux »

Si vous n’avez pas installé bzip2, il est temps de le faire :

apt-get install bzip2

Ensuite, rebelote, c’est du billard :

cd /usr/src

bzcat vzkernel/linux-2.6.32-xxx.xx.x.xxx.tar.bz2 | tar -xv

ln -s linux-2.6.32-xxx.xx.x.xxx linux

Étape 4/10 : appliquer les patchs d’OpenVZ

Attention, cette partie là requière des compétences de haute voltige genre « j’ai découvert Linux il y a deux heures » :

apt-get install patch

cd /usr/src/linux

cat /usr/src/vzkernel/patch-xxxxxxxxxx | patch -p1

Aucune erreur ne doit se produire. Sinon, ben, je sais pas mais en tout cas vous être dans la mouise…

Étape 5/10 : récupérer les paramètres utilisés par le kernel de Proxmox

EDIT : quitte à compiler un kernel OpenVZ, autant utiliser le fichier de config récupéré à l’étape 1/10 (je n’utilise qu’OpenVZ, pas KVM)

Mais, si vous souhaitez récupérer la config utilisée par Proxmox, il faut sortir de votre container OpenVZ et se rendre dans le répertoire « /boot » du système hôte.

Choisissez le fichier config-xxx qui vous convient (uname -a si vous n’êtes pas sûr) et copiez le dans la VM :

cp /boot/config-2.6.32-xx-pve /var/lib/vz/private/xxx/usr/src/linux/.config

Étape 6/10 : paramétrer son nouveau jouet kernel

De retour dans le container OpenVZ et avant de plonger dans les paramètres de conf, il va (encore) nous falloir quelques outils :

cd /usr/src/linux

apt-get install kernel-package

apt-get install libncurses5-dev

Et là, Ô joie bonheur, nous pouvons lancer fièrement un :

make menuconfig

Note : ce que vous faites à partir de ce moment là ne regarde plus que vous et éventuellement Dieu (qui n’a pas « prié » après l’install d’un nouveau kernel ?).

Étape 7/10 : compiler le kernel OpenVZ et obtenir de jolis paquets .deb

Une fois votre causerie avec Dieu terminée (les voies du kernel sont impénétrables)1, il est temps de passer à l’action. Enfin bon, façon de parler car vu le temps que ça va prendre, z’êtes bon pour aller mater un épisode de Dr House.

Note : à la place de « -mon-noyau », pensez à mettre une valeur plus utile.

EDIT : si vous disposez d’un processeur multi-coeurs, il est possible d’accélérer (fortement) la cadence en utilisant la variable « CONCURRENCY_LEVEL« .

cd /usr/src/linux/

make-kpkg clean

export CONCURRENCY_LEVEL=4

make-kpkg --initrd --append-to-version=-mon-noyau kernel-image kernel-headers kernel-source

En fonction de la vitesse du vent, de l’âge du capitaine et de tout le merdier, grosso-modo, ça va être long : plus de 4 heures sur un Atom D525 (1.8 Ghz), une demi-heure bien tassée sur un Core I5 (3.2 Ghz) et moins si vous êtes blindés de pognon.

D’ailleurs, à ce sujet et même si ACTA est définitivement morte (au sein de l’UE en tout cas), pensez à faire un don à la Quadrature du Net, c’est rien que des gens biens qui défendent nos libertés sur Internet :  https://soutien.laquadrature.net/.

Étape 8/10 : installer le nouveau noyau sur le système hôte

Au sein du répertoire « /usr/src » vous allez maintenant trouver des fichiers .deb qui contiennent tout ce qu’il faut pour mener l’opération à bien.

Quittez votre container Openvz afin de retourner sur le système hôte et ensuite, dans la série « plus simple tu meurs » :

cp -av /var/lib/vz/private/xxx/usr/src/*.deb /root

cd /root

dpkg -i linux-image-2.6.32-xxxxxx_2.6.32-xxxxxx-xx.xx.Custom_amd64.deb

Voilà, votre kernel est installé, maintenant y’a plus qu’à booter dessus.

Si vous voulez installer les headers ainsi que le source, répétez l’opération avec les autres fichiers .deb.

Étape 9/10 : modifier grub à l’arrache même que c’est mal

Note : cette étape va profondément heurter les personnes sensibles, toutes mes excuses par avance… (Je compte sur vous pour m’indiquez la bonne marche à suivre dans les commentaires)

EDIT : la solution était si simple… Il suffit d’éditer le fichier « /etc/default/grub », de modifier la variable « GRUB_DEFAULT » et enfin de lancer « updage-grub ».

Donc, soit vous avez accès à votre serveur et dans ce cas tout va bien, il suffit de sélectionner le nouveau noyau lors du boot, soit vous êtes comme moi un sauvage (n’ayant pas lu la doc de grub) et vous modifiez directement (à vos risques et périls) le fichier « /boot/grub/grub.cfg »  « /etc/default/grub » :

vi /etc/default/grub

En scrollant un peu dans le fichier « /root/grub/grub.cfg », vous allez remarquer des lignes intitulées « menuentry » : il s’agit des différents noyaux installés sur le serveur.

Repérez la position de votre nouveau noyau et soustrayez 1 (grub compte à partir de 0).

Retournez dans le fichier « /etc/default/grub » et modifiez la ligne :

GRUB_DEFAULT="x"

A la place de ‘x’, préciser la position (-1) du nouveau noyau.

Sauvegardez le fichier, lancer « update-grub » et voilà, fin de l’histoire.

Étape 10/10 : booter sur le nouveau kernel (et éventuellement stresser comme un kikoolol)

Donc là, y’a pas de mystère : soit ça marche (99% des cas au doigt mouillé), soit vous êtes maudit.

Si la seconde option venait à l’emporter et que vous n’avez pas un accès physique au serveur, il est temps de découvrir les joies du KVM. Sinon, heu, ben, là vous êtes vraiment dans la mouise. (Quoi ? Je l’ai déjà dis ?)

Toujours partant ? Bon, c’est vous qui voyez…

shutdown -r now

A+

  1. Pas d’offense hein, j’ai pas trouvé mieux comme blague pourrie…

Il y a 8 commentaires de gens bizarres, ce sont sûrement des drogués

Oui Jean-Pierre, je souhaite publier un commentaire assassin sur ce blog minable

(Votre adresse email ne sera jamais publiée, divulguée, revendue, broyée, atomisée, etc.)