Vous n'êtes pas identifié(e).
Pages : 1
D'après le retour de lspci la carte n'est pas reconnu.
J'ai fait un test avec une clé live ubuntu 18.04, la commande lspci me retourne bien Network controller: Intel Corporation Wireless 8265 / 8275.
Quelqu'un aurait une idée du problème ?
Merci.
Dernière modification par Twinky (13-11-2018 18:39:28)
Hors ligne
D'après le retour de lspci la carte [wifi] n'est pas reconnue.
Ce problème strictement cosmétique n'a rien à voir avec la version du noyau, plutôt celle de pci.ids :
Et hop, le « problème » est [Résolu] ! cela doit également concerner cinq ou six autres « Device »...
Pour le fun et sur le même principe, mise à jour de la base usb.ids qui commence à dater également.
Hors ligne
20-acpi-vendor.hwdb 20-pci-classes.hwdb 20-usb-vendor-model.hwdb 69-libmtp.hwdb
20-bluetooth-vendor-product.hwdb 20-pci-vendor-model.hwdb 20-vmbus-class.hwdb 70-joystick.hwdb
20-libgphoto2-6.hwdb 20-sdio-classes.hwdb 60-evdev.hwdb 70-mouse.hwdb
20-net-ifname.hwdb 20-sdio-vendor-model.hwdb 60-keyboard.hwdb 70-pointingstick.hwdb
20-OUI.hwdb 20-usb-classes.hwdb 60-sensor.hwdb 70-touchpad.hwdb
j'ai regardé sur Stretch le même dossier
a priori mit en place avec systemd (jessie)
le début du fichier pour 20-pci-classes.hwdb par exemple
le lien en http pointe sur les fichiers disponibles
par contre je ne sais pas a quelle occasion ça se met a jour
il y a un binaire /lib/udev/hwdb.bin .
le lien que je donne en début donne le détail des tests que j'ai fait.
Dernière modification par anonyme (13-11-2018 07:48:39)
Pour Buster, pci.ids et usb.ids ne sont plus utilisés, a priori (pas testé sur une Stretch).
Pour autant, les paquets pciutils et usbutils, y fournissent toujours les commandes update-machin !
Le lien en HTTP pointe sur les fichiers disponibles.
Plus exactement, le lien pointe vers le fichier importé, qui est aussi celui importé par update-pciids...
Par contre, je ne sais pas à quelle occasion ça se met à jour.
Ce serait intéressant ; mise à jour du paquet udev, sous testing ? mise à jour manuelle, ou service :
Il y a un binaire : /lib/udev/hwdb.bin.
Et donc, comme expliqué dans la page man correspondante il s'agit de la base de données compilée.
@Twinky
Ne te laisse pas impressionner par ce flood and fud ; les commandes proposées en #2 sont valides.
Voilà à quoi devrait ressembler le retour de la commande lspci, après mise à jour de la base bien sûr.
Dernière modification par èfpé (13-11-2018 12:10:42)
Hors ligne
Hors ligne
J'ai des problèmes de wifi sur une Debian Stretch avec un kernel 4.17.
Pourquoi 4.17 et pas 4.18 ? Le méta-paquet linux-image-amd64 rétroporté dépend du noyau 4.18 !
Le pilote firmware-iwlwifi est installé.
Déjà tu confonds pilote (iwlwifi) et firmware (iwlwifi-8265-36.ucode), et quelle version, rétroportée ?
Hors ligne
retour
je m' explique pas comment ma base reste a jour , sans jamais utilisé la commande "update"
nota: le fichier "pci.ids" sur certaines machines est vraiment limite moisissure
pour cette commande ça me recrée les fichiers dans /lib/hwdb.d/ => systemd-hwdb --usr update (voir mon lien ).
désolé pour le flood mais je pense que l'info est intéressante
par exemple de la machine ou je poste
retour
idem pour pci.ids
un ryzen 1700 en 2015 ça n'existe pas.
bon stop mon flood .........
Hors ligne
Désolé pour le flood mais je pense que l'info est intéressante :)
Bien sûr que ce hors-sujet est techniquement intéressant... le sujet initial est résolu ! vive le fllood !
Ce qui suit concerne évidemment Debian 9.6 Stretch, tentative de synthèse avant de tout balancer :
la commande lspci peut utiliser la base de données d'udev
la commande systemd-hwdb ne va rien chercher sur le net
la commande systemd-hwdb se comporte comme annoncé
les fichiers compilés sont fournis par des paquets (udev...)
le service systemd-hwdb-update compile dans /etc/udev/ !
Maintenant j'envoie le machin (les premières commandes génèrent un message d'erreur volontaire) :
La base est récente et il n'est pas certain que le service systemd-hwdb-update soit actif par défaut.
Dernière modification par èfpé (18-11-2018 14:30:42)
Hors ligne
j'ai supprimé le fichier /usr/share/misc/pci.ids et le dossier /lib/udev/hwdb.d/ mon retour de lspci est toujours correct (mon hwdb.bin est vide(quelques octets))
j'ai remit en place le dossier "hwdb.d" et régénéré mon hwdb.bin avec la commande ci dessus
pour les options de lspci (sur l'utilisation particulière)
retour
j'ai testé le linux-sysfs et le linux-proc (le même comportement que sous buster)
je reprend la conclusion de èfpé
- la commande lspci peut utiliser la base de données d'udev
- la commande systemd-hwdb ne va rien chercher sur le net
- la commande systemd-hwdb se comporte comme annoncé
- les fichiers compilés sont fournis par des paquets (udev...)
- le service systemd-hwdb-update compile dans /etc/udev/ !
qui renseigne le contenu de /lib/udev/hwdb.d/ ?
Dernière modification par anonyme (14-11-2018 21:32:32)
(les premières commandes génèrent un message d'erreur volontaire)
juste une remarque, cette commande en root (pas en user)
Ben, heureusement que j'ai pris soin de préciser que l'erreur était volontaire : montrer les chemins !
qui renseigne le contenu de /lib/udev/hwdb.d/ ? :)
Réponse en fin de post #10 (le paquet udev, pour près de 95 %) ; bref, j'en profite pour préciser :
la commande lspci utilise soit pci.ids, soit hwdb.bin
la commande lsusb utilise uniquement usb.ids
la base hwdb.bin n'est pas mise à jour, par défaut.
Les conditions de l'activation du service systemd-hwdb-update ne sont pas remplies : pas d'update.
Hors ligne
Pages : 1