Install du kernel 3.6.3 sous squeeze

Voici la Procédure suivi pour la compilation + install du kernel 3.6.3 sous squeeze.
installation des dépendances de compilation du kernel

installation des dépendances pour l’éditeur du fichier de conf du kernel (make menuconfig)

téléchargement et extraction des sources

wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.6.3.tar.bz2 tar -xvf linux-3.6.3.tar.bz2 cd linux-3.6/
utilisation du fichier de conf du kernel actuel pour faciliter le travail

prise en compte de nouveaux paramètres et modification d’anciens si nécessaire (j’ai rien modifié juste sauvegardé)

nettoyages des sources en cas de tentatives précédentes.

compilation et création des deb (pour les machines modestes lancer la procedure le soir ça peut prendre toute la nuit.)

Installation des deb générés

mv ../*3.6.3*.deb ./ dpkg -i *.deb

Salut,

Que nous apportes-tu par rapport au wiki ?

Effectivement , rien, tous y est désolé pour le poste inutile.

[quote=“ggoodluck47”]Salut,

Que nous apportes-tu par rapport au wiki ?[/quote]
Un retour d’expérience positif ? :wink:

Bonjour,

[quote=“hulk”]
Installation des deb générais

mv ../*3.6.3*.deb dpkg -i *.deb[/quote]

Y aurait pas une erreur ici (le mv) ?

oui , je mes souvient pas bien mais c’était sûrement pour déplacer le deb dans le répertoire courent, car il était généré dans le répertoire parent donc:
soit on déplace le deb où on se trouve.

mv ../*3.6.3*.deb ./ dpkg -i *.deb
soit on se déplace où il est:

cd .. dpkg -i *.deb

95 minutes pour compiler seulement le kernel, je ne pensais pas la compilation si longue. Moi qui voulais tester Gentoo je doute avoir la patience nécessaire haha.

C’est le -j1 : n’utilise qu’un unique thread (cf. man make-kpkg pour plus de détails), si ton processeur est disons à 4 cœurs, utilise -j4, ça devrait déjà aller un peu plus vite :wink:

Usti

Salut,

Je ne me rendais pas compte du temps gagné, moi qui suis passé par toutes les étapes pour en être au 3.6.28 :slightly_smiling:

Effectivement c’est plus rapide, 52 minutes avec -j2, merci pour l’astuce.

salut,

[quote]utilisation du fichier de conf du kernel actuel pour faciliter le travail
Code:
cat /boot/config-uname -r>.config[/quote]

je ne sais pas si on perd pas les nouvelles fonctionnalités du noyau que l’on veut compiler avec cette commande. Je propose:

cp /boot/config-`uname -r` ./ diff .config config-`uname -r`>conf.patch patch .config conf.patch rm config-`uname -r`

On peut aussi compiler le noyau sans make-kpkg:

si ça peut éclaircir…

Salut,

Vous devriez faire bénéficier de votre astuce (-j2 ou -j4) le wiki avant que votre astuce ne tombe dans les oubliettes :slightly_smiling:

cp /boot/config-`uname -r` ./ diff .config config-`uname -r`>conf.patch patch .config conf.patch rm config-`uname -r`

diff/patch utilisés de cette façon ne risquent-il pas de d’effacer eux aussi les ajouts de .config ?

[quote=“ggoodluck47”]Salut,

Vous devriez faire bénéficier de votre astuce (-j2 ou -j4) le wiki avant que votre astuce ne tombe dans les oubliettes :slightly_smiling:[/quote]

En général, il faut prendre le nombre de cpu + 1.
Donc -j3 pour un core 2, -j9 pour un core i7.

Pourquoi +1 ?
Sur mon quadri-core, j’utilise généralement un -j3 de façon à garder un coeur totalement libre pour pouvoir faire autre chose durant ma compilation…

Je me suis jamais trop posé la question et ai appliqué bêtement ce qui était recommandé.
C’est “la règle” qui veut ca.

En gros ajouter +1 permet d’occuper tout tes coeurs en permanence et d’avoir une instruction de secours.
Freebsd conseille -j4 pour un seul coeur…
Gentoo conseille n+1 ou 2n+1

Par contre ca va dépendre aussi de ta ram.
Par exemple pour un core 2 avec 512 de ram, tu risque d’avoir de moins bonnes perfs avec -j3 qu’avec -j2 (voire -j1). Tu vas vite swapper.
Pour ton quad-core, si tu as 4g de ram, -j5 devrait passer sans problème et sans saturer ton ordi.

En fait si tu fais pas mal de compil, à toi de trouver le bon réglage, et voir quelle option est la plus performante.
Certaines options du kernel sont a activer/desactiver pour tirer plein benef de tes cpu.

Une compil avec -j9 (j’ai un core i7) n’a jamais fais ramer mon ordi, bien que mes cpu soient à 100% le temps de la compil. Max de ram occupée 1g.
Je viens de faire un test avec -j20 et là mes 4g de ram étaient au taqué et j’ai le swap utilisé de moitié, donc lag de mon ordi.

En gros:
Un j trop faible et le temps entre 2 instructions sera trop élevé.
Un j trop gros et tu vas saturer ton ordi.

EDIT: Et pour gagner du temps, tu peux aussi compiler en tmpfs.

Merci pour les infos, j’expérimenterai et je finirai bien par trouver mon réglage ultime ! :wink:

J’ai découvert cette astuce en faisant un diff avec deux configuration différente. Cela n’efface pas les options “new”. Par exemple:

[quote=“master”]cp /boot/config-uname -r ./
diff .config config-uname -r>conf.patch
patch .config conf.patch
rm config-uname -r[/quote]
En fait en faisant ca tu “court-circuite” le make oldconfig.
Tu va injecter le .config dans ton nouveau kernel sans voir quelles nouvelles options ont été ajoutées et à quoi elles servent.
Un cp .config puis make menuconfig equivaut à la meme chose, tu ne perdra pas les nouveautés qui auront les options par défaut. Dailleurs si tu fais un exit sans rien toucher, il te propose de sauvegarder ta nouvelle conf, c’est donc que les nouvelles options sont intégrées.
Fais un diff entre ton .config et celui qui vient d’être généré, il ne devrait pas y avoir de différences.

Il existe plusieurs écoles:

  • Ceux que j’appellerais les bourrins qui copie l’ancien .config, puis make menuconfig et qui se retrouve dans des menus sans savoir ce qui a été ajouté au noyau.
  • Les prudents qui copie l’ancien .config, lancent un make oldconfig (en général on laisse les options par défaut), notent sur un papier les options qui leur pose probleme, lancent un make menuconfig puis recherche les options notées. C’est la solution recommandée.
  • Les soucieux du détail qui font un make defconfig pour activer par défaut les options qui semblent utiles puis vont activer le reste pas à pas.
  • Les curieux qui vont lancer un make allyesconfig suivi d’un make menuconfig ce qui va activer toutes les options dans le noyau (c’est très formateur car on voit vraiment tout).
  • Les téméraires, qui se disent que ceux qui activent les options par défaut dans le noyau n’y connaissent rien et qu’ils activeront ce qu’ils veulent même si leur ordi ne démarre plus. Alors ceux là feront un make allnoconfig suivi d’un make menuconfig et iront se faire du café le temps de comprendre pourquoi leurs drivers wifi n’apparaissent pas, puis ils abandonneront quand ils comprendront qu’il faut faire des va et vient dans tous les menus pour activer 10 options afin que cette foutue option Atheros apparaisse.

j’ai mis l’option “Kernel .config support” et “Enable access to .config through /proc/config.gz” du menu “general setup” :

General setup Kernel .config support Enable access to .config through /proc/config.gz
Ainsi, je fais directement make menuconfig, et j’obtiens directement la configuration de l’ancien noyau, avec la mention “NEW” aux nouvelles options.

Pour chaque option, on peut utiliser le touche “h” pour avoir de l’aide