Bonjour,
Je viens de réinstaller debian buster pour la nième fois sur un portable LENOVO R500.
Dans un premier temps, j’ai utilisé l’image debian-10.0.0-amd64-netinst.iso
et j’ai galéré pour installer les firmwares sans vraiment y arriver.
Depuis, j’ai réinstallé en utilisant l’image firmware-10.0.0-amd64-netinst.iso
et la seule amélioration que j’y ai trouvée, c’est que le firmware de ma puce wifi a été installé, mais pas les autres.
Il me manque un firmware pour la puce graphique, pour la puce bluetooth, j’ai un problème avec mei…
Bonjour,
Peut-être, partir d’une installation «classique»,
déterminer quels firmwares manquent et les installer.
Vraisemblablement il s’agit de versions non-free qui ne sont pas incluses par défaut dans Debian.
C’est vrai que cela peut prendre du temps.
Si quelqu’un connaît ta configuration, il te sera, certainement, d’une plus grande utilité que moi.
Bonne journée.
@ Hervé33,
Dans mon post initial, j’ai bien indiqué que j’avais utilisé l’image firmware-10.0.0-amd64-netinst.iso
Sauf erreur de ma part, c’est bien la même.
De plus :
jean-marie@serveur:~$ dpkg -l | grep firmware
ii firmware-amd-graphics 20190114-1 all Binary firmware for AMD/ATI graphics chips
ii firmware-iwlwifi 20190114-1 all Binary firmware for Intel Wireless cards
ii firmware-linux-free 3.4 all Binary firmware for various drivers in the Linux kernel
ii firmware-linux-nonfree 20190114-1 all Binary firmware for various drivers in the Linux kernel (meta-package)
ii firmware-misc-nonfree 20190114-1 all Binary firmware for various drivers in the Linux kernel
ii intel-microcode 3.20190618.1 amd64 Processor microcode firmware for Intel CPUs
jean-marie@serveur:~$
Je crois que la messe est dite.
@ grandtoubab,
J’ai déjà essayé d’installer à partir de cette image mais je n’avait pas réussi à booter sur la clé USB (je pense que l’image n’avait pas été correctement téléchargée). Je n’ai pas insisté car j’avais trouvé l’image netinst avec les firmwares.
Je vais réessayer.
[EDIT]
Je viens de retélécharger l’image debian-live-10.0.0-amd64-standard+nonfree.iso
et même symptômes. Le sha1sum est bon (donc le fichier a été bien téléchargé), mais le créateur de disque de démarrage refuse de me le prendre et je crains que si, comme la fois précédente, je tente de transférer l’image sur la clé USB avec un dd, j’obtienne le même résultat.
[/EDIT]
Pour l’ISO debian-live-10.0.0-amd64-standard+nonfree.iso
, je crois savoir pourquoi ça n’avait pas fonctionné la première fois. J’ai dû retirer la clé USB trop tôt après la fin de l’exécution du dd et le cache ne devait pas être vide. Cette fois-ci, ça a marché.
Par contre, que ce soit en version installée ou en version live, j’ai toujours les mêmes messages d’erreur au démarrage :
mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: Could not read FW version
mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: FW version command failed -5
bluetooth hci0: firmware: failed to load brcm/BCM20702A1-0a5c-21e6.hcd (-2)
firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
La bonne nouvelle, c’est que si je désactive “physiquement” le bluetooth, les deux derniers messages disparaissent. Et comme l’installation finale se fera sur une machine non équipée d’un module bluetooth…
Il ne me reste donc plus que les deux premières lignes pour lesquelles j’ai bien trouvé des informations en anglais sur internet, mais rien de bien concluant.
C’est du à ce que fwupd ( un daemon de mise à jour des firmwares ) est devenu un paquet recommandé par gnome-software pendant que buster était en phase testing.
# apt-cache depends gnome-software
Malgré que j’ai installé les paquets recommandés pour fwupd, j’ai la même erreur :
aptitude search '?reverse-recommends(?narrow(?version(CURRENT),^fwupd$))'
i A bolt - démon système pour gérer les périphériques thunderbolt 3
i fwupd-amd64-signed - Tools to manage UEFI firmware updates (signed)
v fwupd-signed -
i A python3 - langage orienté objet interactif de haut niveau – version par défaut de
i tpm2-abrmd - TPM2 Access Broker & Resource Management Daemon
i tpm2-tools - TPM 2.0 utilities
Tu as comment utiliser fwupd avec fwupdmgr sa commande ici :
Mais pour moi cela a été décevant, aucune mise à jour des firmwares et toujours le message d’erreur, j’avais trouvé une déclaration de bug à ce sujet, mais je crois que je ne vais pas essayer de la retrouver, je me souviens juste que debian pour buster avait décidé d’ignorer ce bug et donc je n’en tiens plus compte.
Le problème, c’est que je n’ai ni gnome, ni fwupd, ni fwupdmgr, ni libfwxxx sur cette machine.
Par contre, dans dmesg, j’ai :
[ 10.730899] intel_powerclamp: No package C-state available
[ 10.763764] intel_powerclamp: No package C-state available
[ 10.845943] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: Could not read FW version
[ 10.846013] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: FW version command failed -5
J’ai eu le message mei et la dépendance rajoutée à gnome-software le même jour et comme les deux sont liés aux firmwares, j’en ai conclu que ces deux évènements étaient directement liés, mais peut-être n’est-ce qu’indirect.
Chez moi :
lscpu | grep CPU
Nom de modèle : Intel(R) Core(TM)2 Duo CPU E8500 @ 3.16GHz
dmesg |grep "intel\\|mei"
[ 0.911813] intel_idle: does not run on family 6 model 23
[ 10.117448] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: Could not read FW version
[ 10.117485] mei mei::55213584-9a29-4916-badf-0fb7ed682aeb:01: FW version command failed -5
[ 11.511271] fbcon: inteldrmfb (fb0) is primary device
[ 11.559920] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 11.663862] intel_powerclamp: No package C-state available
[ 11.704664] intel_powerclamp: No package C-state available
Pour intel_powerclamp, je ne suis pas concerné par cette technologie de refroidissement des CPU par logiciel qui consiste à injecter des temps où le CPU ne fait rien ( idle ) pour le refroidir :
intel_idle: does not run on family 6 model 23
Pour les erreurs mei, elles sont liées a l’Intel Management Engine.
Pour intel_powerclamp, nous ne sommes pas concernés par cette technologie de refroidissement des CPU par logiciel qui consiste à injecter des temps où le CPU ne fait rien ( idle ) pour le refroidir, car nos processeurs ne peuvent pas la prendre en charge vu qu’ils ont été conçus avant que intel_idle soit mis en œuvre :
L’erreur powerclamp n’en est pas une pour nous car elle ne change rien pour nos machines car nos processeurs ne prennent pas en charge cette technologie.
Reste l’erreur mei Management Intel Engine à laquelle je sèche pour une explication depuis que tu as démoli mon hypothèse que c’était lié à fwupd !
le noyau xanmod se mets à jour sans problème automatiquement, comme tout dépôt, et ça ne casse rien du noyau Debian que tu peux toujours sélectionner dans Grub au démarrage
Bonjour grandtoubab ! Comment expliques-tu qu’en installant le noyau 5.2.4-xanmod5 et qu’ensuite même en redémarrant sur le 4.19.0-5-amd64 tout est plus rapide : durée de démarrage abaissée de 6 secondes, applications plus rapides ?
Est-ce du au paquet libelf-dev qui est venu avec l’installation du noyau 5.2.4-xanmod5 ?
peut etre que xanmod est vraiment bien optimisé ou que le noyau 5 est intrinsèquement meilleur. je n’en sais pas plus que ce qui est dit sur le site https://xanmod.org/
