Installation debian buster

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

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898479

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.

ca ressemble furieusement à çà
https://bbs.archlinux.org/viewtopic.php?id=242015

comme c’est très spécifique du type de matériel, que je connais pas, je te laisse faire :rofl:

Ben…,

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

Serait-ce lui qui produit les messages mei ?

Amicalement.

Jean-Marie

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.

Chez moi :

jean-marie@serveur:~$ lscpu | grep CPU
Nom de modèle :                         Intel(R) Core(TM)2 Duo CPU     T5870  @ 2.00GHz
jean-marie@serveur:~$

Et effectivement, j’ai un :

[ 1.523225] intel_idle: does not run on family 6 model 15

Le mystère reste entier.

Amicalement.

Jean-Marie

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 :

https://duckduckgo.com/?q=powerclamp+linux+driver

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 !

Peut-être un pilote qui buguerait ?

dpkg -S mei | grep driver
linux-image-4.19.0-5-amd64: /lib/modules/4.19.0-5-amd64/kernel/drivers/watchdog/mei_wdt.ko
linux-image-4.19.0-5-amd64: /lib/modules/4.19.0-5-amd64/kernel/drivers/misc/mei
linux-image-4.19.0-4-amd64: /lib/modules/4.19.0-4-amd64/kernel/drivers/nfc/pn544/pn544_mei.ko
linux-image-4.19.0-4-amd64: /lib/modules/4.19.0-4-amd64/kernel/drivers/misc/mei/mei.ko
linux-image-4.19.0-5-amd64: /lib/modules/4.19.0-5-amd64/kernel/drivers/misc/mei/mei.ko
linux-image-4.19.0-4-amd64: /lib/modules/4.19.0-4-amd64/kernel/drivers/misc/mei/mei-me.ko
linux-image-4.19.0-4-amd64: /lib/modules/4.19.0-4-amd64/kernel/drivers/misc/mei
linux-image-4.19.0-4-amd64: /lib/modules/4.19.0-4-amd64/kernel/drivers/nfc/mei_phy.ko
linux-image-4.19.0-4-amd64: /lib/modules/4.19.0-4-amd64/kernel/drivers/watchdog/mei_wdt.ko
linux-image-4.19.0-5-amd64: /lib/modules/4.19.0-5-amd64/kernel/drivers/media/rc/keymaps/rc-gadmei-rm008z.ko
linux-image-4.19.0-5-amd64: /lib/modules/4.19.0-5-amd64/kernel/drivers/nfc/pn544/pn544_mei.ko
linux-image-4.19.0-5-amd64: /lib/modules/4.19.0-5-amd64/kernel/drivers/nfc/mei_phy.ko
linux-image-4.19.0-5-amd64: /lib/modules/4.19.0-5-amd64/kernel/drivers/misc/mei/mei-me.ko
linux-image-4.19.0-4-amd64: /lib/modules/4.19.0-4-amd64/kernel/drivers/media/rc/keymaps/rc-gadmei-rm008z.ko

Une partie du mystère n’est pas encore éclairci.

tester avec le noyau 5

uname -a
Linux debian 5.2.4-xanmod5 #1.190729 SMP PREEMPT Mon Jul 29 14:59:14 -03 2019 x86_64 GNU/Linux

Je ne suis pas chaud pour jouer avec les noyaux.

Je crois que je vais rester avec mon erreur mei jusqu’à ce qu’elle soit corrigée. Après tout, la machine fonctionne correctement.

Amicalement.

Jean-Marie

1 J'aime

joueur petit bras :joy:

Oui. :grinning:

Et si j’upgrade mon noyau en 5.0 ou 5.2, quid des mises à jour ?

Amicalement.

Jean-Marie

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

ls -alrt /boot
total 120316
-rw-r--r--  1 root root  5217520 juil. 19 00:23 vmlinuz-4.19.0-5-amd64
-rw-r--r--  1 root root  3371003 juil. 19 00:23 System.map-4.19.0-5-amd64
-rw-r--r--  1 root root   206213 juil. 19 00:23 config-4.19.0-5-amd64
-rw-r--r--  1 root root 48297430 juil. 27 11:24 initrd.img-4.19.0-5-amd64
-rw-r--r--  1 root root   184884 juil. 29 16:14 memtest86+_multiboot.bin
-rw-r--r--  1 root root   182704 juil. 29 16:14 memtest86+.bin
-rw-r--r--  1 root root  7240064 juil. 29 19:58 vmlinuz-5.2.4-xanmod5
-rw-r--r--  1 root root  4642795 juil. 29 19:58 System.map-5.2.4-xanmod5
-rw-r--r--  1 root root   234700 juil. 29 19:58 config-5.2.4-xanmod5
drwxr-xr-x  5 root root     4096 juil. 30 09:08 grub
drwxr-xr-x 25 root root     4096 août   2 14:47 ..
-rw-r--r--  1 root root 53585391 août   3 08:23 initrd.img-5.2.4-xanmod5

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/

la lib que tu cites vient de Debian

apt policy libelf-dev
libelf-dev:
  Installé : 0.176-1.1
  Candidat : 0.176-1.1
 Table de version :
 *** 0.176-1.1 990
        500 https://cdn-aws.deb.debian.org/debian buster/main amd64 Packages
        990 https://cdn-aws.deb.debian.org/debian bullseye/main amd64 Packages
        100 https://cdn-aws.deb.debian.org/debian sid/main amd64 Packages
        100 /var/lib/dpkg/status
     0.168-1 500
        500 https://cdn-aws.deb.debian.org/debian stretch/main amd64 Packages
     0.159-4.2+deb8u1 500
        500 https://cdn-aws.deb.debian.org/debian-security jessie/updates/main amd64 Packages

Salut à tous,

Je ne recréer pas un nouveau topic car j’aurais indiqué exactement le même…
Je voudrais laisser juste quelques notes importantes concernant le passage à buster ou debian 10 :

Les commandes saisies en root ne sont pas trouvées alors que le paquet responsable est installé : c’est un problème de PATH; Pour cela il faut modifier le fichier /root/.profile comme suit :

# ~/.profile: executed by Bourne-compatible login shells.

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc
  fi
fi

PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/sbin:/usr/local/sbin

mesg n || true

Ensuite y a aussi une grosse modification dans gestion du réseau, pour ceux qui comme moi désinstallent network-manager et utilisent ifupdown :

Le fichier lu est /etc/network/interfaces.d/setup , cependant le fichier /etc/network/interfaces existe toujours et si on ne prend pas le temps de lire la modification qu’il y a à l’intérieur, on cherche… :roll_eyes:

Pour ce qui est du reste, tout fonctionne à peu près comme avant, pour moi ça change pas énormément de truc vu que je tourne sous xfce4 et c’est très bien comme ça :slightly_smiling_face:

Oui !

Non, il faut utiliser

su -

tout est expliqué en détail ici :
https://debian-facile.org/viewtopic.php?pid=307336#p307336

Bonjour

Je n’ai pas eu besoin de le modifier,
il m’a suffit, comme toujours,
d’utiliser l’option login de la commande su
(qui peut être remplacée par un simple tiret),
ce qui donne :

su -

La variable d’environnement PATH du compte root
est alors définie par l’exécution des lignes de commandes suivantes
extraites du fichier /etc/profile

…
if [ "`id -u`" -eq 0 ]; then
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
  PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
…

Sur une installation originale d’un système debian stretch ou buster,
le contenu du fichier /root/.profile
est :

# ~/.profile: executed by Bourne-compatible login shells.

if [ "$BASH" ]; then
  if [ -f ~/.bashrc ]; then
    . ~/.bashrc
  fi
fi

mesg n || true

1 J'aime

à propos de /usr

C’est MON sujet et il ne traitait pas de ça ! :wink: :smiley: :smiley: :smiley:

Pour en revenir aux messages d’erreur au boot, j’ai fini par dénicher le firmware de mon circuit bluetooth sur le site de broadcom (fichier BCM20702A1-0a5c-21e6.hcd).

Une fois installé dans /lib/firmware/brcm, l’erreur a disparu.

Amicalement.

Jean-Marie

Du coup sans doute utiliser la petite coche pour signaler que le sujet est résolu :wink:

Ben…, je crois que c’est fait depuis longtemps. :wink: :smiley:

Amicalement.

Jean-Marie