Aller au contenu principal ↑ ↓
Sujet: Compilation Kernel (Lu 8441 fois) sujet précédent - sujet suivant

Compilation Kernel

Bonjour,

Je devrais récupérer une machine avec un cpu 4XXX, donc cpu "renoir".
Pour de tels cpu il faut normalement un kernel 5.9 voir plus récent pour avoir un igp bien supporté.

Dans les premiers retours, sur la 15.3, ces cpus semblent enfin correctement supportés, mais pas sur que ça soit suffisamment backporté pour avoir quelque chose de parfait.
Je sais qu'il existe un dépôt KERNEL "stable", mais celui ci contient toujours le tout dernier kernel (genre le 5.11 en ce moment), et personnellement par sécurité je préférerais avoir le contrôle et potentiellement rester sur le LTS.

Vous avez déjà compilé un kernel à la mano sous openSuse?
Peut-on garder la configuration effectuée par le noyau Suse, et l'appliquer en compilant un noyau 5.10 ou on va forcément repartir sur du vanilla?

Qu'en est-il sur tumbleweed niveau kernel, c'est du vanilla ou les patchs de suse sont aussi appliqués?

merci d'avance.

Re : Compilation Kernel

Répondre #1 –
sur tumbleweed, on est sur le noyau 5.10.16, on devrais passé 5.11.2 prochainement

david

Re : Compilation Kernel

Répondre #2 –
salut,

je vais te faire une réponse con, puisque tu demandes simplement un ressenti.
Je ne pense pas que ça t'avancera à grand chose, mais j'avais tenté de compiler et j'avais trouvé ça longuet; il faut aussi connaître bien des nuances techniques, être à la limite au parfum des développeurs pour pouvoir compiler au poil, sans aucun risque pour ta machine.
Je pense donc que dans un premier temps tu devrais donner toutes les caractéristiques connues de ta machine, ce qui permettrait aux cadors du forum (jtro, chalu, seb95 pour ne pas les citer -il y en a d'autres, je ne les ai pas tous en tête donc toutes mes excuses pour les autres  :D )de pouvoir t'aider avec toutes les précautions nécessaires.
Au poil du pif je pense que c'est possible y compris sous tumbleweed, mais qu'il faut juste connaître bien des subtilités que je ne connais point. Le problème étant, comme tu as pu le remarquer la floraison d'options en tous genre - que je ne pense pas destructrices, pour autant, les développeurs suse n'étant pas, loin de là des manchots bien que linuxiens  :)) et si tu as envie d'une optimisation en tous points parfaite, il te serait bcp plus recommandable de tester une compilation à minima dans un premier temps afin d'éviter tout problème, quitte à la refaire par la suite.
Bonne soirée, et courage!
lucky 

Re : Compilation Kernel

Répondre #3 –
hello.

IL n'y a pas de risque pour le matériel de compiler.
Au pire il te manque une dépendance et le kernel ne se compile pas.
Au pire tu oublies une option dans le kernel (pilote) et ça ne boote pas, mais tu as toujours l'ancien kernel.

Dans mon cas, je n'ai aucun risque de casser quoi que ce soit, en fait je vais récupérer une machine avec un 4800H donc un gpu vega7.
JE sais que pour que cette machine soit bien supportée il faut un kernel 5.9 minimum.

De ce que j'ai pu lire comme info sous leap 15.2 ça ne passera donc pas avec le kernel 5.3 même avec les modifs faites par suse.
Sous leap 15.3 qui arrive ça semble bien avec les derniers backport.

Du coup sous tumbleweed ça passerait parfaitement mais je préfère une distrib fixe pour mon usage donc leap.
A partir de là j'ai deux choix, soit rajouter le dépôt "kernel" mais ce dépôt contient le dernier kernel, je trouve ça trop "risqué" je me contenterait sans soucis du kernel 5.10, ou à minima j'aimerais avoir le contrôle pour pouvoir revenir en arrière lorsqu'il y a maj de kernel et ne pas resté bloqué. D'ou le compiler soit même son kernel.

Je vais commencer à regarder et faire mes essais, mais je me demandais s'il était possible de compiler un kernel avec les options de suse, si c'est vanilla c'est pas bien grave, reste à voir si je me prends la tête à choisir les pilotes précisément ou si je prends le noyau normal ou y a tout de compilé. :D

Re : Compilation Kernel

Répondre #4 –
tu pourrais peut être tester leap en vm avec le dépôt kernel?

Re : Compilation Kernel

Répondre #5 –
Ouep c'est ce que j'avais fait, je ne vois pas pourquoi ça ne marcherait pas, mais comme dit ce qui me pose pb c'est sur le long terme, tu peux passer du 5.11 au 5.12 et avoir des régressions car (passé trop tôt au 5.12 et il aurait fallut attendre le 5.12.Y), sauf que comme il n'y a qu'un seul kernel dans ce dépôt, ça passe ou ça casse, aucun retour en arrière possible ou alternative tant que le kernel 5.12.Y ne sort pas.
Sans compter que tu peux ne jamais avoir de régression en virtualisé alors qu'en natif certains pilotes posent pb.
En effet les dev testent souvent sur des vm, donc il y a rarement des pbs dessus.

C'est tout le pb.
En compilant toi même, tu peux lire ce qui se dit sur le kernel 5.12, voir les retours, et attendre sur le 5.X (qui te convient) jusqu'à ce que le le 5.12 soit suffisamment mature.

A voir au final ce qu'il en est en pratique.

Re : Compilation Kernel

Répondre #6 –
Autre solution pour obtenir un kernel avec la version voulu.
Dans OBS refaire un paquet lié et changer les sources du kermel et garder tout les patch SUSE.

Avantage les patchs seront toujours appliqués sur le kernel.



Re : Compilation Kernel

Répondre #7 –
Ah en voilà une idée qu'elle est bonne!
On est sûr que ça passe sur tous les kernels?

C'est exactement le genre d'idée que je voulais faire, garder les patchs de suse mais avec un kernel plus récent.
Il va falloir que je me renseigne sur tout ça, reste à trouver les bonnes informations. (j'ai vu passer le topic ici sur OBS mais c'était sur le packaging d'un logiciel, je me doute que pour un kernel ça ne va pas être trivial... )

Re : Compilation Kernel

Répondre #8 –
Non justement avec OBS c'est simple pas besoin de refaire tout les paquets.
Les paquets peuvent être liés mais dans un paquet lié on peut juste mofifier un fichier.

J'ai lancé une compilation sur un kernel-default sans aucun changement voir ce que cela donne.

Re : Compilation Kernel

Répondre #9 –
Ah c'est bon à savoir!
T'aurais moyen d'expliquer comment tu fais ça si ça passe? :)

Re : Compilation Kernel

Répondre #10 –
Bon j'ai reçu le pc portable.
Voici le constat:
Sous leap 15.2 ça "marchotte" avec le kernel de base.
Comprendre ça marche sans être parfait, mais la sortie HDMI ne fonctionne pas.
Je n'ai pas non plus de "zoli" écran de boot (ça c'est moins grave).

Si je mets le kernel 5.11 du dépôt "kernel", c'est ok, sauf que derrière impossible de rajouter le paquet "kernel-default-devel", soucis de dépendance. (demande GCC 2.33 dispo nul part pour openSuse 15.2.

Du coup, je commence à me réorienter vers un build d'un kernel 5.10 si ça me permettait de résoudre ces pbs là.
T'as du neuf sur le sujet du coup?

Re : Compilation Kernel

Répondre #11 –
Hello ;=)

Regarde si ca aide en ajoutant ces paquets, ajoute ce dépôt dans Yast :
http://download.opensuse.org/repositories/Kernel:/stable/standard/

tu n'as pas forcément besoin du dernier kernel, mais parfois de ceux là oui : ( zypper ref && zypper in toto )

kernel-firmware-all     | Compatibility metapackage for kernel firmware files     | paquet

et
ucode-amd  | Microcode updates for AMD CPUs              | paquet

ou (selon ta config)
ucode-intel | Microcode Updates for Intel x86/x86-64 CPUs | paquet


(aussi attention si tu choisis une 15.2 : c'est le choix de la stabilité, ca implique que certaines choses sont moins brillantes/récentes : gui, softs etc ... Ne pas trop écpouter les sirènes de la mercatique car le risque potentiel est le suivant : si tu ajoutes des choses en avance ca risque de te revenir en boomerang, tôt ou tard ; donc bien être prudent sur les ajouts de dépôts ou paquets en avance de phase. )

Re : Compilation Kernel

Répondre #12 –
hello

c'est un pb classique avec le hardware récent : la leap 15.2 est "stable", et donc elle ne prend pas en compte ce qui a été validé "après", ... mais on peut quand-même tenter l'astuce suivante (comme le dit manchette ci-dessus)

1- ajouter le repo kernel latest ci-dessus avec une priorité inférieure (ex: 110)
2- dans yast2, sélectionner *dans ce repo* kernel-firmware (et éventuellement les micro-codes intel et amd) --> il suffit d'aller dans l'onglet "versions" et de cliquer sur la bonne ligne
      NOTE: compare la date avec le paquet de la leap-15.2 officiel, il y a en général un an d'écart
      NOTE: désormais yast2 mémorise l'afinité pour ce(s) paquet(s) et il en fera les mises à jour depuis ce repo
3- rebooter
4- si le kernel officiel de la leap-15.2 n'arrive pas à charger les firmwares, aller chercher un kernel plus récent sur le même principe (en évitant celui de kernel stable car il change tout le temps)
5- ajouter le repo tumbleweed avec une priorité inférieure (ex: 110)
6- dans yast2, sélectionner *dans ce repo* kernel-default --> il suffit d'aller dans l'onglet "versions" et de cliquer sur la bonne ligne
      NOTE: désormais yast2 mémorise l'afinité pour ce(s) paquet(s) et il en fera les mises à jour depuis ce repo
      NOTE: en profiter pour faire du ménage car kernel-default est un paquet multi-versions et il y a souvent plein de vieilleries
      IMPORTANT: toujours conserver le dernier kernel-default de la leap-15.2 , pour pouvoir booter dessus avec grub (on ne sait jamais )
7- rebooter
8- et depuis que je fais ça je n'ai plus jamais joué à recompiler des kernels....

eric



Re : Compilation Kernel

Répondre #13 –
hello,

Justement c'est ce que j'avais fait de mettre le dépot "kernel".
Mais sans booter sur le nouveau kernel, ça ne changeait rien.
j'avoue ne pas avoir osé rajouté le dépôt de tumbleweed pour le kernel. :D

Le problème étant que comme dit, si on se met à prendre le kernel dans tumbleweed, on risque d'avoir le problème mentionné plus haut avec glibc et donc au final à basculer sur une tumbleweed du coup ben on quitte leap quoi.
Après dans mes tests la 15.3 supportera parfaitement ce pc portable (cpu renoir) mais la question sur comment faire si besoin se pose toujours quand même.

Re : Compilation Kernel

Répondre #14 –
hello burn2

oui, en ajoutant tumbleweed, on a effectivement le risque de tirer la glibc de TW si on clique sans vérifier ce qui va être installé dans l'onglet "install summary" (ça se rattrape mais ça peut être chaud si on n'aime pas la ligne de commande...)

mais ce n'est pas senser arriver si le repo TW est en prio inférieure et si on n'ajoute pas des paquets de repos "contrib" qui possèdent des dépendances cachées sur TW (ajoutées par erreur en faisant le .spec car ça marchait sur le host du mainteneur et il n'a pas fait gaffe)

si tu as une astuce pour ne pas prendre les mises a jour kernel du repo kernel_stable, je prends ;-)...