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.
sur tumbleweed, on est sur le noyau 5.10.16, on devrais passé 5.11.2 prochainement
david
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
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
tu pourrais peut être tester leap en vm avec le dépôt kernel?
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.
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.
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... )
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.
Ah c'est bon à savoir!
T'aurais moyen d'expliquer comment tu fais ça si ça passe? :)
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?
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. )
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
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.
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 ;-)...
Sauf que comme dit, si tu as un kernel trop récent et que tu as besoin des headers, tu as forcément besoin d'un glibc à jour, c'est tout le problème de ce fonctionnement "boiteux".
C'est pour ça que même le dépôt "kernel" ne fonctionne plus réellement avec leap 15.2 vu qu'il a été compilé sous glibc 2.33 et que les headers ont besoin de glibc 2.33 en dépendance.
Et je me demande si on compilant soit même son kernel on levait ce genre de pb, si on compile avec glibc 2.26 genre un kernel 5.10 (le dernier lts).
Je me demande d'ailleurs si leap 15.3 met à jour glibc ou pas, je n'ai pas fait gaffe, je vais regarder tien.
EDIT: vérifié, c'est la 2.31 dans LEAP 15.3 pour l'instant
Un tutorial pour compiler:
https://tutorialforlinux.com/2021/01/05/step-by-step-build-kernel-opensuse-easy-guide/2/
(je l'essaie pour l'instant)
Bon j'ai testé à l'arrache sous tumbleweed de builder un kernel 5.10.
C'est ok pour le build, pour l'installation via zypper ça foire niveau dépendance.
Je testerais en vm sur une leap 15.12 pour voir si c'est pareil.
Bon j'ai testé la compilation d'un 5.10 sous leap 15.2.
ça compile bien, ça s'installe aussi (mais me demande de remplacer des fichiers), mais une fois choisis dans le grub ==> ko
En mode failsafe ça foire sur: "fb0: switching to amdgpudrmfb from epi vga" et ça s'arrête là.
EDIT: je teste ça en plus
https://tutorialforlinux.com/2021/01/12/how-to-update-linux-firmware-on-opensuse-guide/2/
EDIT2: ça ne change rien. :(
C'est bon j'ai réussi!!!!
Il faut rajouter: sudo mkinitrd
Me voilà sous un noyau 5.10 avec les firmware à jour
Par contre forcément pour tout ce qui est builder de base genre virtualbox je pense que ça va poser pb...
Hello ;=)
as tu des choses mal supportées au départ qui marchent mieux ?
Oui!
Je n'avais pas plymouth (pb de support gpu) et c'est ok maintenant
Le hdmi ne fonctionnait pas non plus avec mon igp ==> c'est ok maintenant.
En fait leap 15.2 ne supporte pas à 100% les cpu renoir, avec un kernel 5.10 + des firmwares à jour tout est ok.
Hello ;)
Cool que ca porte ses fruits, tu dois être content de voir tes efforts récompensés et de mieux maîtriser/profiter de ta configuration. C'est vrai qu'il y a un côté frustrant d'avoir un matériel tip top quand on ne profite pas de tout ce qu'il offre :)
hello.
En fait c'était un test rapide pour voir.
Tous n'est pas parfait, ça pose pb sous openSuse car beaucoup de paquet derrière ont des dépendances avec les headers du kernel 5.3 et ça rentre en conflit avec les headers des 5.10 installés.
Donc à chaque fois il faut choisir de casser les dépendances, et ça marche ok mais bon on ne peut pas dire que ça soit pour tous les jours.
En gros pour bien comprendre, quand tu veux installer dkms il te dit qu'il a besoin du headers-5.3.... alors qu'il y a les headers 5.10.
Donc les paquets ne sont pas fait avec un truc genre >= 5.3 mais avec == donc dès que tu n'as plus le paquet de base paf.
Donc pour le coup mon salut sera plus sur la 15.3 ou ça semble ok, ou alors partir sur tumbleweed.
;=)
Si tu veux continuer à t'amuser le 5.12 est dispo
https://www.nextinpact.com/lebrief/46897/le-noyau-linux-5-12-disponible-avec-sa-cohorte-dameliorations
A voir si les plus attendus sont pertinents dans ta config.
Après tu peut aussi ajouter le dépôt http://download.opensuse.org/repositories/Kernel:/stable/standard et faire zypper in, mais tout ce qui est avance de phase faudra faire gaffe.
tu as quel noyau ?
ici je suis revenu à
~> uname -r
5.3.18-lp152.72-default
JE sais pour le dépôt kernel, j'en avais parlé ici, mais c'est encore pire, parce que le kernel compilé dans ce dépôt dépend d'un glibc trop récent, donc ça fout la grouille. ça ne marche pas au final.
Et idem je sais pour le kernel 5.12. :)
J'avais testé le 5.10 car LTS.
Pour l'instant je fais des tests, donc je n'ai pas arrêté de choix. Comme dit, si je dois rester sur une distrib au final ça sera forcément sur le kernel de base vu que compiler son propre kernel pose pb de dépendance sous openSuse malheureusement. :/
Donc ça sera soit sur la 15.3 (qui a aussi un kernel 5.3 mais avec d'autres backport qui fait que le les cpus renoir avec igp sont enfin supportés à priori) soit sur tumbleweed qui a un kernel 5.11. (et là pour le coup aucun doute tout marchait au poil)