Chargement...
 
[Voir/Cacher menus de gauche]
[Voir/Cacher menus de droite]

2 - Les distributions et les noyaux

> Forums de discussion > 2 - Les distributions et les noyaux > [RESOLU]microcode manquant où le trouver ?
Dernier post

[RESOLU]microcode manquant où le trouver ?

calixtus06 utilisateur non connecté
Salut,

A l'ouverture de librazic j'ai un script qui me dit :

modprobe:module microcode not found in modules.dep
/dev/sda1:clean, 182334/9371648 files 2195295/37479680 blocks


Le processeur de l'ordi que je destine à linux MAO:

nicolas@nicolasMAO:~$ cat /proc/cpuinfo | grep model | cut -c14-

Intel(R) Core(TM)2 Duo CPU     T6570  @ 2.10GHz

Intel(R) Core(TM)2 Duo CPU     T6570  @ 2.10GHz
nicolas@nicolasMAO:~$


Si j'ai bien compris on peut aller le chercher dans un dépôts différents mais comment le trouver ?

Merci d'avance

Nico

olinuxx utilisateur non connecté France
C'est un non-problème (je pense). En tout cas, c'est présent depuis longtemps dans LibraZiK, et vu que je n'ai pas vraiment compris d'où ça venait et que ça n'empêchait pas au système de fonctionner, je ne m'y suis pas pencher plusse que ça.

Au moment ou tu configure ton noyau il est possible dans une des options du menu d'activer la prise en charge des microdes qui est désactivée par defaut. Mais le soucis c'est qu'à pares t'es contraint d'activer le non-free et contrib...

calixtus06 utilisateur non connecté
utilisateur_anonyme écrit :
Au moment ou tu configure ton noyau il est possible dans une des options du menu d'activer la prise en charge des microdes qui est désactivée par defaut. Mais le soucis c'est qu'à pares t'es contraint d'activer le non-free et contrib...


Salut utilisateur_anonyme !

Dis moi si je me trompe. Tu veux dire que quand Olivier crée librazik il configure le noyau de la distribution sans activer les microcodes non free ?

Merci c'est plus pour ma culture perso

A toute

olinuxx utilisateur non connecté France
calixtus06 écrit :
Olivier crée librazik il configure le noyau de la distribution sans activer les microcodes non free


Oui.

Merci pour l'info utilisateur_anonyme. Je regarderai plus précisément cette option lors de la prochaine construction de noyau pour LibraZiK.

J'ai l'impression que depuis la polémique d'éthique en FSF et debian que depuis debian à décidé de désactiver les micro-codes par defaut.

Pour la culture il semble que les micro-codes créer des portes dérobées du système que les développeur peuvent remprunter. C'est du moins ce qu'il en état à l'époque de wheezy je crois.
Après c'est choix si ça fonctionne bien sans, bin tu fait sans et tu reste dans "l'esprit libre" sans sinon il faudrait presque faire un noyau sans micro code et un autre avec puis offrir un backport non-free.

Mais bon après tu te retrouve avec le dilemme des micro-code amd et micro code intel brefs a moins d'avoir 36000 machines pour le construire et le tester ça me parait être une perte de temps.

ouhena utilisateur non connecté France
Pour être même plus précis, outre le fait qu' il faille autoriser leur support par le noyau quand tu le compiles (c' est le boulot d' olinuxx), ces microcodes n' étant pas du code libre, ils ne sont pas distribués dans les sections "normales" de Debian mais dans la section non-free, qui n' est pas active à l' installation de LibraZiK.
Je pense, comme olinuxx, que ça ne devrait pas influer sur tes problèmes, mais sur ce coup-là je me réserve la possibilité de me gourrer.

olinuxx utilisateur non connecté France
Citation :
J'ai l'impression que depuis la polémique d'éthique en FSF et debian que depuis debian à décidé de désactiver les micro-codes par defaut.


C'est pas une polémique, c'est une discussion amenant à un point de vue. La question est de savoir si Debian étant libre ou non.

Pour ce qui est des portes dérobées, ça n'est qu'une conséquence du soucis. Le soucis étant que le code non-libre (que ce soit ces micro-codes ou autre logiciel), n'est pas auditable facilement. Càd : vu qu'on a pas les sources, il n'est pas évident/possible de savoir ce que ce code fait (ou ne fait pas). Du coup, c'est possible qu'il y ait des portes dérobées, mais le soucis est surtout de ne pas pouvoir améliorer le code après l'avoir étudié. Quand c'est un logiciel "normal", au pire, ça plante. Mais quand on en est à des pilotes pour processeurs/carte graphique/... qui ne sont pas libres et donc pas étudier, alors c'est carrément tout le système qui peut se retrouver par terre à cause d'une erreur dans le code.

De ce que j'en sais utilisateur_anonyme, je ne vois pas l'intérêt de faire 2 noyaux un avec les micro-codes, et l'autre sans, car en utilisant un noyau sans ces micro-codes (j'ai l'intuition que l'on parle ici des micro-codes concernant les processeurs intel et amd), on peut toujours ajouter le paquet debian disponible dans non-free de ces micro codes. Du coup, si un utilisateur les veux, il peut les avoir. Le fait qu'il soit dans le bloc du noyau ou apporté en externe ne semble pas provoquer de différence.

@ouhena, pour rétablir un peu de vérité là dedans : ça n'est pas mon "boulot", c'est ce que je fais et fourni sur mon temps libre wink

C'est exactement ce que je disais ouhena en parlant de la contrainte d'activer le non-free et contrib.
à priori sans les micro-code ça fonctionne c'est juste le message sur le tty qui fait chi#r.

À partir du moment ou tu compile le noyaux avec ces micro-code il ne peut plus être dans la section "main". D'ailleurs depuis un moment le sources.list de debian n’inclue pas les dépots non-free et contrib c'est donc que leur politique à changer et qu'il arrive à faire tourner le kernel sans le micro-code donc

Sauf si tu as des besoin précis c'est à l'utilisateur de compiler le noyaux sinon ça ferait trop de taf au dev ça prend un temps fou à à compiler sur une 32 bit par exemple après faut tester ect ... Et encore attention compiler soit même peut-être périlleux au moment de l'installation.

Le mieux pour librazik c'est de blacklister les micro-codes point barre debian fonctionne sans et c'est très bien.

Désolé pour le temps de réponse mais oui il s'agissait des micro-code intel vs amd j'ai constaté qu'en fonction de l'install il faudrait blacklister ceux qui ne correspondent pas et franchement c'est relou.


Citation :
Quand c'est un logiciel "normal", au pire, ça plante. Mais quand on en est à des pilotes pour processeurs/carte graphique/... qui ne sont pas libres et donc pas étudier, alors c'est carrément tout le système qui peut se retrouver par terre à cause d'une erreur dans le code.


Je suis bien d'accord mais en général les mecs savent ce qu'il font et c'est plus affaire de confiance aveugle. Perso je ne confie pas un gosse à un prêtre pédophile même si le parallèle parait exagéré c'est ce que j'en pense.

ouhena utilisateur non connecté France
Sur mes jessie j' ai bien un noyau un noyau libre issu de la section main et qui charge le microcode intel qui lui vient du paquet intel-microcode qui est dans non-free. Donc tu peux très bien avoir un noyau libre (en tout cas au sens Debian) qui charge du code non-libre, sans rien compiler ni faire de spécial. Après je suis bien d' accord que je l' ai fait surtout pour plus avoir les messages au démarrage, et parce que t' es quand même pas à l' abri d' un bug de conception chez Intel qui soit corrigé ou contourné par le microcode en question.

olinuxx utilisateur non connecté France
Citation :
Le mieux pour librazik c'est de blacklister les micro-codes point barre debian fonctionne sans et c'est très bien.


Ça ne veut rien dire ça. Ou plutôt, ça demande une explication plus détaillée. Parce que pour l'instant, le mieux pour LibraZiK, c'est ce que je fais, c'est à dire : pas de micro-codes non-libres dans le noyau, et si un utilisateur en as besoin pour une raison ou une autre, il installe le paquet qui va bien en activant non-free. Bref, aucune nécessité de blacklister quoi que ce soit. Ou alors, j'ai pas compris ce que tu essaies de dire ?


Citation :
Je suis bien d'accord mais en général les mecs savent ce qu'il font et c'est plus affaire de confiance aveugle.


Quels "mecs" ? Les mecs de chez amd ou intel payés au lance-pierre dans un atelier en Chine ... ? :-) Aucune confiance aveugle perso.


Citation :
Perso je ne confie pas un gosse à un prêtre pédophile même si le parallèle parait exagéré c'est ce que j'en pense.


Je confirme. C'est exagéré.

olinuxx utilisateur non connecté France
Citation :
et parce que t' es quand même pas à l' abri d' un bug de conception chez Intel qui soit corrigé ou contourné par le microcode en question.


Ni d'une erreur de codage, ou d'une porte dérobée, ou d'un bogue ayant été introduit lors d'une correction d'un autre bogue, dans le micro-code... wink

Bref, tant qu'on a pas accès aux sources, c'est du niveau de la croyance.

calixtus06 utilisateur non connecté
euh..s'cuzez moi d'vous déranger ...y a quelqu'un de dispo pour mon fil sur guitarixx

sub26nico utilisateur non connecté France
je t'y ai répondu

Citation :
Quels "mecs" ? Les mecs de chez amd ou intel payés au lance-pierre dans un atelier en Chine ... ?


Tous. Il est loin le temps la chine faisait de la copie de merde maintenant il font de qualité tu peux ouvrir n’importe appareil fabriqué en chine tu verra c'est clean de chez clean. Les processeur sont fabriquer certes en chine avec d'une part la main d'oeuvre esclavagiste le tout avec le cahier des charge des concepteurs. Ça s'appelle hypocritement "transfert de technologie" .

ouhena utilisateur non connecté France
olinuxx écrit :
Ni d'une erreur de codage, ou d'une porte dérobée, ou d'un bogue ayant été introduit lors d'une correction d'un autre bogue, dans le micro-code... wink

Bref, tant qu'on a pas accès aux sources, c'est du niveau de la croyance.


La porte dérobée dans le microcode d' un processeur j' y crois extrèmement peu. Mais c' est de la croyance

olinuxx utilisateur non connecté France
utilisateur_anonyme écrit :
Tous. Il est loin le temps la chine faisait de la copie de merde maintenant il font de qualité tu peux ouvrir n’importe appareil fabriqué en chine tu verra c'est clean de chez clean. Les processeur sont fabriquer certes en chine avec d'une part la main d'oeuvre esclavagiste le tout avec le cahier des charge des concepteurs. Ça s'appelle hypocritement "transfert de technologie" .


C'est pas complètement faux. Ceci dit, moi je pense que rien n'a vraiment changé en Chine. La Chine a compris le monde du Capital industriel depuis bien longtemps. Et du coup, si tu paies, elle fabrique. À l'époque où on avait davantage de savoir-faire fabriqué en France (ou pas loin), alors nous n'avions pas besoin d'acheter du matériel moyenne/haute gamme à la Chine, donc on ne lui commandait que de la mouise, et les gens disaient "les chinois, ils fabriquent que de la mouise" alors qu'en fait, c'est nous qui ne leur commandions que de la mouise. Mais maintenant qu'on a bien saigné les fabricants du pays ici, alors on ne fabrique plus de matériel moyenne/haute gamme et du coup on en commande aussi à la Chine. Et les gens disent "le matos fabriqué en Chine est pas mal, ils ont bien progressé". CQFD

Bref, je vais faire mon modéro en te demandant sympathiquement de bien vouloir ouvrir un sujet dans "Le nimp" si tu veux continuer cette discussion (que je serais heureux de faire avancer là bas) car là, on est plutôt loin du sujet de départ. Merci.



@ouhena : ba c'est bien ça le soucis, c'est que l'on ne peut pas "savoir". :-)


@calixtus06 : j'ai vu que tu avais mis un [résolu] dans le titre, merci. On ne va pas tarder à fermer ce sujet du coup.

calixtus06 utilisateur non connecté
lé concielge y va bientôt felmé !! oust allez faile oune toule dou côté dé mon fil guitalixxx porque yé dois accompagner la cantatlixxx

olinuxx utilisateur non connecté France
Note modo-forum : fil de discussion déplacé depuis "1 - Le matériel et les pilotes ALSA, FFADO, ...".


Afficher les articles :
Aller au forum :

Documentation [Afficher / Cacher]

Faire un don
[Afficher / Cacher]

Connexion
[Afficher / Cacher]



Mégaphone [Afficher / Cacher]

calixtus06, 14:33, jeu. 28 mars 2024: Bonjour et bienvenue à b.vl :-)
calixtus06, 09:30, mer. 27 mars 2024: Bonjour et bienvenue à Noar :-)
olinuxx, 18:50, lun. 25 mars 2024: Bonjour et bienvenue à Ted Demore cool
olinuxx, 17:52, dim. 24 mars 2024: Bonjour et bienvenue à Noitavon cool
calixtus06, 11:07, jeu. 21 mars 2024: Bonjour et bienvenue à obds, ceric :-)
obds, 16:12, mar. 19 mars 2024: Cet édito est juste parfait. Trop beau !
olinuxx, 11:48, ven. 15 mars 2024: Bonjour et bienvenue à Jerry cool
calixtus06, 18:03, mer. 13 mars 2024: Bonjour et bienvenue à tanguero :-)
olinuxx, 11:01, dim. 10 mars 2024: Bonjour et bienvenue à lolo cool
bda, 16:59, sam. 09 mars 2024: Chapeau pour l'édito. Vous êtes au top les gars :-)
allany, 07:20, jeu. 07 mars 2024: Ça ne fait jamais de mal, c'est l'éditorial ! [Lien]
olinuxx, 19:52, mer. 06 mars 2024: Bonjour et bienvenue à TrkNrk cool