Compilation noyau

Support Debian
#1

Bonsoir,

j’ai une petite question concernant la compilation du noyau. Comment peut-on recupérer exactement la configuration precedente?

J’utilise ‘make menuconfig’.
Au prealable, je copie le fichier .config qui m’interesse dans le repertoire des sources et je lance ‘make menuconfig’.
Le probleme, c’est que ‘make menuconfig’ change tout seul des trucs, ou alors ne considere pas le .config. Car, une fois que je sors de ‘make menuconfig’ (en enregistrant), meme si je n’ai fait aucune modification, le .config generé est différent de celui importé (et vraiment différent. Par exemple, des options pour les portables acer ont été désactivés par la manip).

Est-ce normal? Y-a-t-il quelque chose a faire (une option a passé a make menuconfig imposant de ne modifier que ce qu’on lui demande)?
Ou alors, utiliser autre chose que ‘make menuconfig’?

Merci de votre retour d’expérience et de votre aide.

#2

Fais d’abord un make oldconfig puis un menuconfig après mais c’est bizarre.

#3

La commande

make oldconfig

est censée baser tes options sur le noyau courant.

Il y aura malgré tout des nouveautés et des dépendances internes,
des “choix” qui n’en seront pas car obligés et non optionnels.

A nouveau noyau nouvelles options obligatoires.

La procédure menuconfig en fait de même au nom de la cohérences interne
et des “options” sont imposées par défaut bien que tu aies
un ancien “.config” opérationnel sans les dites options.

Readme

If you want to carry your existing configuration to a
new version with minimal work, use “make oldconfig”, which will
only ask you for the answers to new questions.

  • Alternate configuration commands are:
    “make config” Plain text interface.
    “make menuconfig” Text based color menus, radiolists & dialogs.
    “make xconfig” X windows (Qt) based configuration tool.
    “make gconfig” X windows (Gtk) based configuration tool.
    “make oldconfig” Default all questions based on the contents of
    your existing ./.config file and asking about
    new config symbols.
#4

Cela n’explique pas la désactiviation des options ACER genre CONFIG_ACER_WMI, il n’y a aucune raison qu’elle n’ait pas été maintenue.

#5

Je n’ai en ce moment pas de compilation de noyau en cours pour voir de quoi il en retourne concernant ACER*.

Do it yourself. Fais le toi même

Après menuconfig rechercher les options ACER* par /
Voir si ils sont acceptés en M ou en dur.
S’il n’est pas possible de les rajouter c’est qu’il manque une option par ailleurs ce qui expliquerait la disparition de cette option malgré le .config ancien.

$ diff .config_ancien .config_nouveau

“help” correspondant aux options différentes,
linux-2.6.??/Documentation

#6

À mon avis tu te trompes d’interlocuteur là.

En ce qui concerne l’option CONFIG_ACER_WMI, elle est dans Device Drivers->X86 Platform Specific Device Drivers et n’a pas de dépendances. C’est typiquement l’option «feuille» présente dans les noyaux depuis lulu (elle y est encore dans le 2.6.31) qui ne devrait pas partir sur un oldconfig, d’où mon étonnement.

etxeberrizahar: fais avant tout un «make oldconfig» et regarde les ajustements faits. Tu peux préciser les versions (si tu passes d’un 2.2.19 à un 2.6.31, c’est normal :slightly_smiling:)

#7

a propos ashgenesis a fait un petit truc a ce sujet,je sais pas ce que ca vaut mais il est la:
ashgenesis.developpez.com/linux/kernel-debian/

peut-etre doit-il etre mis a jour il date quand meme de 2006

alors ne pas tenter le diable ,renseignons nous d’abord :slightly_smiling:

#8

Merci pour vos réponses.

Imaginons: je suis sous 2.6.30 et je veux passer au 2.6.31. Je copie mon .config actuel, et pour des raisons de compatibilité, il est modifié par ‘make *config’. La d’accord. Pas de problème. C’est tout à fait normal, étant donné que, les noyaux étant différents, il y ait des ajustements à faire.

La situation que je décris: j’ai un 2.6.30 et les sources de ce 2.6.30 (exactement les sources qui ont servi à compiler ce noyau).
Je souhaite recompiler mon noyau (par exemple, pour ajouter un module). Comment faire pour qu’il garde exactement les options qu’il avait?

Mon exemple avec les modules ACER n’est qu’un exemple: en fait, c’est a cause de ca que je me suis rendu compte de ce probleme. Car en rebootant sur le nouveau noyau, les modules ACER avaient disparu, alors que je n’avais pas touché à ça lors de ma compilation (et qu’ils étaient présents dans le .config initial).
Pour ces modules, c’est pas un probleme. Je sais qu’il suffit de les réactiver et de recompiler.

Le problème, c’est plus de ne pas savoir TOUT ce qui sera modifié apres le passage de ‘make *config’ (je sais qu’on le voit avec ‘diff ancien-config nouveau-config’, mais la liste des modifications est tres longue, et s’il faut tout refaire a la main, alors autant faire a la main du debut. Mais je ne peux pas m’imaginer qu’il n’y ait pas une solution plus simple, qui impose de conserver le .config, lorsqu’il sagit des meme sources).

Merci encore pour votre réactivité.

#9

tu as essayé?
make-kpkg clean
cp /boot/config2.x(config ancienne) /usr/src/linux/.config
make oldconfig (et non menuconfig)
diff /boot/.conf_ancien .conf_nouveau

ou mieux utilise directement ton ancien .config du boot pour la compil
(donc pas de compil perso juste une copie generic avec support initrd)

ton ancien .config est generic (install classique)?
tu as fais un initrd (c’est peut-être initrd qui active ton acer)?
make-kpkg modules?

#10

L’initrd ne change rien sur la compilation et ne peut faire apparaitre des modules non compilés.
make oldconfig récupère le .config et l’adapte au nouveau noyau.
make menuconfig en théorie récupère le .config, l’adapte au nouveau noyau (tout comme make oldconfig donc) puis passe en interactif.

#11

je n’ai pas dis que initrd peut miraculeusement créer un module
mais soit il est dispo dans l’ancienne config et c’est lui qui le charge (à la place de /etc/modules)?
il y a compil hard (inclus au kerel), module ou absence …

Et où il récupère oldconfig ? (bonne question, dans le boot?, racine /usr/src/linux)

make menuconfig n’adapte rien, il te donne juste un “accès” sous forme de fenêtre dialogue au fichier .config pour activer ou désactiver des options…
de même que make xconfig te donne juste un accès au menu sous forme X

#12

[quote=“dchost99”]
make menuconfig n’adapte rien, il te donne juste un “accès” sous forme de fenêtre dialogue au fichier .config pour activer ou désactiver des options…
de même que make xconfig te donne juste un accès au menu sous forme X[/quote]

Ben si justement, il adapte. C’est exactement ça le probleme. Si tu connais un moyen pour qu’un ‘make *config’ se contente de lire le .config qu’on lui passe et donne juste acces au dialogue d’options sans rien modifier, ben ça répondrait exactement à la question initiale.

#13

Désolé d’insister mais il va juste créer (écraser) le .config avec les option activé par défaut, rien n’avoir avec ta machine…

[quote=“dchost99”]tu as essayé?
make-kpkg clean
cp /boot/config2.x(config ancienne) /usr/src/linux/.config
make oldconfig (et non menuconfig)
diff /boot/.conf_ancien .conf_nouveau

ou mieux utilise directement ton ancien .config du boot pour la compil
(donc pas de compil perso juste une copie generic avec support initrd)
make-kpkg modules?[/quote]

c’est juste ton ancienne config pas une config perso …
(ce qui veut dire tt les cartes son en module, sata ide et tt les option generic compilé en module avec obligation initrd)
si tu veux optimiser base toi sur ton .config.2.x.x.x. dans le boot et désactive ce que tu n’a pas besoin …

#14

[quote=“etxeberrizahar”]La commande

make oldconfig

est censée baser tes options sur le noyau courant.

La procédure menuconfig en fait de même au nom de la cohérences interne
et des “options” sont imposées par défaut bien que tu aies
un ancien “.config” opérationnel sans les dites options.

Readme
If you want to carry your existing configuration to a
new version with minimal work, use “make oldconfig”, which will
only ask you for the answers to new questions.[/quote]

#15

La solution serait bien de faire d’abord un make oldconfig (en recopiant /boot/config-uname -r sur .config par exemple) plus le make menuconfig.

Mais je suis étonné, si on a configuré le noyau avant, make menuconfig modifie le .config en cours, et il m’est arrivé de faire des corrections directes sur le .config puis de peaufiner avec le menuconfig. De plus je lis dans la doc

Bon, il faudra faire des essais, peut être que l’adaptation n’est pas terrible ou qu’il y a un bug à ce sujet. En tout cas, ça ne mange pas de pain de faire un oldconfig puis menuconfig…

#16

[quote=“dchost99”]
c’est juste ton ancienne config pas une config perso …
(ce qui veut dire tt les cartes son en module, sata ide et tt les option generic compilé en module avec obligation initrd)
si tu veux optimiser base toi sur ton .config.2.x.x.x. dans le boot et désactive ce que tu n’a pas besoin …[/quote]

Si on n’utilise plus les outils du genre de ‘make menuconfig’ pour configurer le noyau, et qu’on doit le faire directement dans le .config à la main (tu sembles dire que c’est la seule solution, si je comprends bien), existe-t-il une doc qui repertorie toutes les options possibles pour un noyau donné?

#17

Non, la config à la main entrainera des erreurs de compilation: il y a des optiuons incompatibles et des options nécessitant d’autre options (pas de usb gadget si le support usb n’est pas activé par exemple…). L’utilisation de menuconfig/xconfig/gconfig est indispensable.

#18

à la main déconseillé (je crois que que la 1er ligne c’est “do not edit”)

oldconfig recupère les anciennes option .config

menuconfig, xconfig … commance l’edition du .config (option generic)

de toute manière tu as l’option help (dans menu dialog )pour te renseigner sur l’option choisi

doc : le net est remplie de doc sur le kernel (google)
par contre pour faire une config perso faut bien connaitre le matos que tu as.
lsmod t’informe sur les modules que tu utilise et que tu veux intégrer au kernel,
te passer de initrd et réduire la taille de ton kernel.

avantages: boot rapide ( pas de initrd), moins de mémoire utilisé pour le kernel, kernel plus réactif (enfin juste le temps du chargement des modules et des dépendances)

inconvénients: pour les modules exclus , en cas de besoin faut compiler à la main (même si ils était dispo avant), sur les machines récente le gain de mémoire et de rapidité entre un kernel generic et perso est insignifiant