Re: dual screen avec intel UHD 630 possible sur stretch ?
Re, On Wed, Apr 11, 2018 at 10:17:22PM +0200, Daniel Caillibaud wrote: > Le 11/04/18 à 20:57, "JF Straeten" a écrit : > JS> > Est-ce que qqun parmi vous a fait fonctionner sur une stretch du > JS> > dual screen avec les processeurs intel récent (coffee lake, les > JS> > 8xxx) et leur chipset graphique intégré (intel UHD 630) ? > JS> > JS> Oui. Sur un NUC7i3DNKE. Enfin, c'est une buster actuellement, mais la > JS> stretch marchait sans problème aussi avec le dual screen et le chipset > JS> UHD 620 (c'est un i3). > > Merci bcp pour cette confirmation ! > > (et je n'ai pas oublié tes galères à cause des câbles, j'y ferai attention !) Tout à fait. Tout dépend de ta résolution max, en fait. Jusqu'au full HD, pas de problème (en fait même 1920x1200). C'est au dessus que ça se gâte. Je ferai un bref retour dans le fil ad hoc sur la solution finalement retenue... A+ -- JFS.
Détection automatique d'une connection USB
Bonjour la liste, J'ai des appareils fabriqués en interne qui utilisent des chips FTDI pour lesquels j'ai obtenu de la part de FTDI, il y a déjà de nombreuses années, une plage de PID. En fait, j'utilise essentiellement le PID 0xEFE0, donc mon interface apparaît comme 0403:EFE0 Sur mes PC Linux (en l’occurrence "Mint" à jour), je dois lancer en root, un script pour initier la reconnaissance de connection, le contenu de mon script /home/du2/Applications/utils/ Usb_Axiome.sh est le suivant : modprobe ftdi_sio chmod 666 /sys/bus/usb-serial/drivers/ftdi_sio/new_id echo "0403 EFE0" > /sys/bus/usb-serial/drivers/ftdi_sio/new_id Après avoir lancé ce script, je peux bien communiquer avec mes appareil par un port VCP du type /dev/ttyUSBx La déconnexion et reconnexion devient bien automatique, pas de soucis. Par contre, je souhaiterais ne pas avoir à lancer manuellement ce script et j'ai pensé à une règle UDEV, mais là je nage, tous mes essais sont infructueux. Et surtout je ne sais pas comment investiguer de façon efficace. J'ai écrit la règle suivante dans /etc/udev/rules.d/99-axiome.rules : ACTION=="add", SUBSYSTEM=="usb", ATTR{idProduct}=="EFE0", ATTR{idVendor}=="0403", RUN+="/sbin sh /home/du2/Applications/utils/Usb_axiome.sh" Si quelqu'un voit mon erreur ou a une autre idée pour arriver au résultat, je lui en serai infiniment reconnaissant. D'avance merci à ceux qui me lirons. Danilo
Re: GRUB : listes de blocs, erreur : résolu
Le 11/04/2018 à 11:38, Klaus Becker a écrit : Le mercredi 11 avril 2018, 11:31:27 CEST andre_deb...@numericable.fr a écrit : # grub-install /dev/sda1 me donne ce long message : "Le système de fichiers NTFS ne prend ps en charge l'empaquetage. "empaquetage", vraiment ? Ce n'est pas plutôt "embarquage" (embedding) ? Grub ne doit pas être installé sur cette configuration qu'en utilisant la liste de blocs, qui ne sont pas FIABLES donc déconseillées. Erreur, refus de continuer avec les listes de blocs" Il fallait taper : # grub-install /dev/sda Je ne me souviens plus si avant je tapais /dev/sda1, peut-être une modification du dernier paquet grub ? Non, GRUB a toujours réagi ainsi avec un type de système de fichier ne permettant pas l'embarquage (en gros : tous sauf btrfs). De toute façon, je ne suis même pas sûr qu'on puisse installer GRUB dans une partition NTFS. Pour installer grub, il faut toujours /dev/sdx Non, c'est faux.
Re: Pilote carte vidéo AMD Radeon 6550M stretch
On Wednesday 11 April 2018 20:46:25 Étienne Mollier wrote: > On 04/11/2018 08:38 PM, andre_deb...@numericable.fr wrote: > > $ lsmod | grep radeon ne répond rien. > Ça, ce n'est pas normal. Vous pouvez déjà vérifier deux points. > Est-ce que le module radeon est bien configuré dans votre kernel : > $ grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)" > CONFIG_DRM_RADEON=m Je reçois la réponse : "aucun fichier ou dossier de ce type" > Normalement le noyau par défaut de Debian devrait l'embarquer en > tant que module comme dans la copie ci-dessus. > Est ce que le module fglrx est toujour présent ? >$ lsmod | grep fglrx Aucune réponse. # apt-cache search fglrx Aucune réponse; > Si oui, les deux pilotes sont probablement en conflit et il faut > évacuer toute trace du pilote propriétaire. Le désinstaller et > redémarrer devrait suffire. À plus, Ni radeon ni fglrx ne semblent installés, Je suis perdu... Vais je devoir retourner à Jessie ? Bonne fin de soirée, André
Re: dual screen avec intel UHD 630 possible sur stretch ?
Le 11/04/18 à 20:57, "JF Straeten" a écrit : JS> > Est-ce que qqun parmi vous a fait fonctionner sur une stretch du JS> > dual screen avec les processeurs intel récent (coffee lake, les JS> > 8xxx) et leur chipset graphique intégré (intel UHD 630) ? JS> JS> Oui. Sur un NUC7i3DNKE. Enfin, c'est une buster actuellement, mais la JS> stretch marchait sans problème aussi avec le dual screen et le chipset JS> UHD 620 (c'est un i3). Merci bcp pour cette confirmation ! (et je n'ai pas oublié tes galères à cause des câbles, j'y ferai attention !) -- Daniel Une pomme par jour éloigne le médecin, pourvu que l'on vise bien. Winston Churchill
Re: Plantage bizarre
Le 11/04/18 à 15:01, BERTRAND Joël a écrit : BJ> Je pensais à un truc plus tordu dans les options du noyau (les BJ> rp_filter et consorts). Ça pourrait être de ce coté là, mais réinstaller une stretch from scratch en laissant tout par défaut aurait dû régler le pb non ? Comment je peux lister les valeurs de ces différentes options (pour les comparer avec la machine qui fonctionne) ? J'ai regardé un diff sur la sortie de `sysctl -a` des deux machines, et je vois rien qui différe sur les clés net.* (sur les autres, qq différences légères sur ce qui touche à la ram ou au limites de fs, ou les kernel.sched_domain.cpuX.domainY) la seule différence des clés net.* est net.ipv4.tcp_mem = 93225124300 186450 vs net.ipv4.tcp_mem = 94365125823 188730 (net.ipv4.conf.enp2s0 est rigoureusement identique au net.ipv4.conf.eth0 de l'autre) Donc je vois toujours pas… -- Daniel L'avenir est un lieu commode pour y mettre des songes. Anatole France
Re: dual screen avec intel UHD 630 possible sur stretch ?
Hello Daniel, On Wed, Apr 11, 2018 at 08:43:42PM +0200, Daniel Caillibaud wrote: [...] > Est-ce que qqun parmi vous a fait fonctionner sur une stretch du > dual screen avec les processeurs intel récent (coffee lake, les > 8xxx) et leur chipset graphique intégré (intel UHD 630) ? Oui. Sur un NUC7i3DNKE. Enfin, c'est une buster actuellement, mais la stretch marchait sans problème aussi avec le dual screen et le chipset UHD 620 (c'est un i3). Le 630 étant plus capable, j'imagine qu'il ne peut que fonctionner aussi (et mieux ?). [...] > Est-ce qu'il y a d'autres pbs à prévoir ? (autour d'autres trucs > récents comme usb-C, nvme/pci-e, etc. avec un chipset Z370) J'en fais une utilisation super basique (client léger LTSP, choisi justement pour avoir un double écran potable en remplacement du limaçon précédent) et RAS jusqu'ici. Hih, -- JFS.
Re: Pilote carte vidéo AMD Radeon 6550M stretch
On 04/11/2018 08:38 PM, andre_deb...@numericable.fr wrote: > $ lsmod | grep radeon ne répond rien. Ça, ce n'est pas normal. Vous pouvez déjà vérifier deux points. Est-ce que le module radeon est bien configuré dans votre kernel : $ grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)" CONFIG_DRM_RADEON=m Normalement le noyau par défaut de Debian devrait l'embarquer en tant que module comme dans la copie ci-dessus. Est ce que le module fglrx est toujour présent ? $ lsmod | grep fglrx Si oui, les deux pilotes sont probablement en conflit et il faut évacuer toute trace du pilote propriétaire. Le désinstaller et redémarrer devrait suffire. À plus, -- Étienne Mollier
dual screen avec intel UHD 630 possible sur stretch ?
Bonjour, Est-ce que qqun parmi vous a fait fonctionner sur une stretch du dual screen avec les processeurs intel récent (coffee lake, les 8xxx) et leur chipset graphique intégré (intel UHD 630) ? Installer un noyau récent pose pas de pb mais ce sera impérativement sur une stretch. À priori c'est reconnu (https://unix.stackexchange.com/questions/405453/debian-9-with-intel-i7-8700) mais je me demande si le dual-screen peut poser pb. Est-ce qu'il y a d'autres pbs à prévoir ? (autour d'autres trucs récents comme usb-C, nvme/pci-e, etc. avec un chipset Z370) J'ai fouillé sur https://certification.ubuntu.com/catalog/ pour me donner une idée, mais c'est compliqué de s'y retrouver, y'a bien le HD 630 mais c'est évidemment pas le même chipset que UHD 630… Merci -- Daniel Il faut toute une vie pour apprendre à vivre. Sénèque.
Re: Pilote carte vidéo AMD Radeon 6550M stretch
On Wednesday 11 April 2018 19:55:55 Étienne Mollier wrote: > On 04/11/2018 04:14 PM, andre_deb...@numericable.fr wrote: > Bonjour André, > > Depuis l'upgrade de Jessie vers Stretch, > > je n'arrive plus à faire fonctionner ma carte graphique > > AMD Radeon 6550M. > J'utilise une carte AMD Radeon HD5770 sous Sid. À la fin de l'année > 2015, après sortie de Jessie, AMD a sorti son dernier driver fglrx, > qui n'a pas reçu de mise à jour depuis, d'où le manque de support. > Le driver libre alternatif est le pilote radeon, les cartes gpu plus > récentes peuvent aussi avoir besoin du pilote amdgpu: > $ lsmod | grep radeon > radeon Merci Étienne pour votre aide. $ lsmod | grep radeon ne répond rien. > > J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfree" > > et "xserver-xorg-video-ati". > Avec une HD6550M, le paquet xserver-xorg-video-radeon devrait résoudre > votre problème. J'ai bien installé le paquet "xserver-xorg-video-radeon", ainsi que le pilote "xserver-xorg-video-amdgpu". > En espérant que ça aide, À plus, Oui, ça aide, bons tuyaux mais toujours pas de vidéo... :-) Il me semble avoir vu passer un mail sur la ML sur ce même sujet, il y a environ 6 mois, mais pas retrouvé... Bonne soirée, André
Re: Pilote carte vidéo AMD Radeon 6550M stretch
On 04/11/2018 04:14 PM, andre_deb...@numericable.fr wrote: > Bonjour, Bonjour André, > Depuis l'upgrade de Jessie vers Stretch, > je n'arrive plus à faire fonctionner ma carte graphique > AMD Radeon 6550M. > > Aussi, plus de fglrx sous stretch. J'utilise une carte AMD Radeon HD5770 sous Sid. À la fin de l'année 2015, après sortie de Jessie, AMD a sorti son dernier driver fglrx, qui n'a pas reçu de mise à jour depuis, d'où le manque de support. Le driver libre alternatif est le pilote radeon, les cartes gpu plus récentes peuvent aussi avoir besoin du pilote amdgpu: $ lsmod | grep radeon radeon > J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfree" > et "xserver-xorg-video-ati". Avec une HD6550M, le paquet xserver-xorg-video-radeon devrait résoudre votre problème. En espérant que ça aide, À plus, -- Étienne Mollier
Pilote carte vidéo AMD Radeon 6550M stretch
Bonjour, Depuis l'upgrade de Jessie vers Stretch, je n'arrive plus à faire fonctionner ma carte graphique AMD Radeon 6550M. Aussi, plus de fglrx sous stretch. J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfree" et "xserver-xorg-video-ati". Les pilotes sur le site AMD ne veulent pas s'installer, car déclarés non compatible avec xorg. Que faire ? et merci... André
Re: Plantage bizarre
Daniel Caillibaud a écrit : > Le 11/04/18 à 09:34, BERTRAND Joël a écrit : > […] > BJ> > - ça fonctionne bien depuis mon portable, qui est aussi sous stretch, > BJ> > avec le même ssh/openssl/clé ssh (et la même connexion, j'ai même été > BJ> > jusqu'à lui coller même mac, en utilisant le même cable RJ45 sur le > BJ> > même port de la même box) > BJ> > > BJ> > => le pb vient donc de la gestion du réseau par mon desktop vs > BJ> > laptop. Vu que les deux ont la même debian, reste > BJ> > - le driver de la carte réseau, et je comprends vraiment pas comment > BJ> > ça peut influer sur des échanges chiffrés (à priori lui n'agit que > BJ> > sur la couche réseau, pas applicative). > BJ> > - le (dé)chiffrement AES par le cpu > BJ> > > BJ> > Y'a moyen de changer des paramètres du kernel pour modifier la > BJ> > gestion AES du cpu ? > BJ> > > BJ> > Vous voyez une autre piste ? > BJ> > BJ> Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de > BJ> suite. Mais si ce n'est pas une histoire de chiffrement, ça peut > BJ> ressembler à une histoire de chemin. > > Ça pourrait, mais ici ip route me donne la même chose depuis desktop et > laptop, ça passe par la même box donc les mêmes routes (j'ai vérifié avec > un traceroute). Je pensais à un truc plus tordu dans les options du noyau (les rp_filter et consorts). > Ça je suis d'accord, si on élimine des cipher dans openssl, faut aussi > virer leur usage dans les paquets qui l'utilisent (mais y'en a bcp), et ça > ne devrait se faire que d'une debian à la suivante (mais ça je suppose que > c'était le cas). > Mais à priori tous les outils qui utilisent openssl commencent par lui > demander quels sont les ciphers dispos, donc ça devrait pas poser pb. > > Mais dans ton cas, ton sendmail devait utiliser les cipher mis à dispo par > openssl, ce sont les smtp en face qui devaient pas savoir les gérer. Et c'est bien le cas. Le fait de virer chez Debian des ciphers arbitrairement fait qu'on peut avoir de sérieux effets de bord avec les serveurs distants. JKB
Re: Plantage bizarre
Le 11/04/18 à 09:34, BERTRAND Joël a écrit : […] BJ> > - ça fonctionne bien depuis mon portable, qui est aussi sous stretch, BJ> > avec le même ssh/openssl/clé ssh (et la même connexion, j'ai même été BJ> > jusqu'à lui coller même mac, en utilisant le même cable RJ45 sur le BJ> > même port de la même box) BJ> > BJ> > => le pb vient donc de la gestion du réseau par mon desktop vs BJ> > laptop. Vu que les deux ont la même debian, reste BJ> > - le driver de la carte réseau, et je comprends vraiment pas comment BJ> > ça peut influer sur des échanges chiffrés (à priori lui n'agit que BJ> > sur la couche réseau, pas applicative). BJ> > - le (dé)chiffrement AES par le cpu BJ> > BJ> > Y'a moyen de changer des paramètres du kernel pour modifier la BJ> > gestion AES du cpu ? BJ> > BJ> > Vous voyez une autre piste ? BJ> BJ> Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de BJ> suite. Mais si ce n'est pas une histoire de chiffrement, ça peut BJ> ressembler à une histoire de chemin. Ça pourrait, mais ici ip route me donne la même chose depuis desktop et laptop, ça passe par la même box donc les mêmes routes (j'ai vérifié avec un traceroute). BJ> > BJ> Si c'est bien ce à quoi je pense, il faudrait que des BJ> > BJ> gens qui ne comprennent pas les implications de leurs patches BJ> > BJ> arrêtent de les imposer... BJ> > BJ> > Sur la suppression de certains ciphers d'openssl, c'est un choix BJ> > délibéré je suppose, interdire les connexions qui paraissent BJ> > sécurisées mais ne le sont pas car utilisant des ciphers vulnérables. BJ> > BJ> > C'est le choix de firefox & chrome par ex, ils refusent désormais les BJ> > connexions https vers des sites qui ne font pas de TLS ou utilisent BJ> > des ciphers trop faibles. BJ> BJ> C'est surtout très bête dans le cas d'une bibliothèque générale. BJ> Lorsque tu ne peux plus envoyer de mails à la moitié du monde, tu es en BJ> général content (d'autant que les gars qui ont patché cela n'ont pas BJ> patché les outils utilisant cette bibliothèque pour leur permettre de BJ> rester isofonctionnels). Ça je suis d'accord, si on élimine des cipher dans openssl, faut aussi virer leur usage dans les paquets qui l'utilisent (mais y'en a bcp), et ça ne devrait se faire que d'une debian à la suivante (mais ça je suppose que c'était le cas). Mais à priori tous les outils qui utilisent openssl commencent par lui demander quels sont les ciphers dispos, donc ça devrait pas poser pb. Mais dans ton cas, ton sendmail devait utiliser les cipher mis à dispo par openssl, ce sont les smtp en face qui devaient pas savoir les gérer. Ou alors un pb de conf perso, qui indique une suite de cipher préférés, liste qui n'aurait pas été mise à jour suite à l'évolution des ciphers disponibles dans openssl. Du coup tu annonces des ciphers que tu ne peux pas gérer ensuite. Je dis ça parce que j'ai des smtp qui causent avec pas mal d'autres et j'ai pas eu ce pb lors des ≠ upgrades (depuis sarge ou etch). -- Daniel Pour marcher au pas d'une musique militaire, il n'y a pas besoin de cerveau, une moelle epiniere suffit. Albert Enstein.
Re: GRUB : listes de blocs, erreur : résolu
Le mercredi 11 avril 2018, 11:31:27 CEST andre_deb...@numericable.fr a écrit : > On Tuesday 10 April 2018 18:50:13 andre_deb...@numericable.fr wrote: > > # grub-install /dev/sda1 > > me donne ce long message : > > "Le système de fichiers NTFS ne prend ps en charge l'empaquetage. > > Grub ne doit pas être installé sur cette configuration qu'en utilisant la > > liste de blocs, qui ne sont pas FIABLES donc déconseillées. > > Erreur, refus de continuer avec les listes de blocs" > > Il fallait taper : > # grub-install /dev/sda > > Désolé pour mon alerte. > > Je ne me souviens plus si avant je tapais /dev/sda1, > peut-être une modification du dernier paquet grub ? Salut, Pour installer grub, il faut toujours /dev/sdx, ce n'est pas nouveau Klaus
Re: GRUB : listes de blocs, erreur : résolu
On Tuesday 10 April 2018 18:50:13 andre_deb...@numericable.fr wrote: > # grub-install /dev/sda1 > me donne ce long message : > "Le système de fichiers NTFS ne prend ps en charge l'empaquetage. > Grub ne doit pas être installé sur cette configuration qu'en utilisant la > liste de blocs, qui ne sont pas FIABLES donc déconseillées. > Erreur, refus de continuer avec les listes de blocs" Il fallait taper : # grub-install /dev/sda Désolé pour mon alerte. Je ne me souviens plus si avant je tapais /dev/sda1, peut-être une modification du dernier paquet grub ?
Re: Plantage bizarre
Daniel Caillibaud a écrit : > Le 10/04/18 à 23:12, BERTRAND Joël a écrit : > BJ> Daniel Caillibaud a écrit : > BJ> > Le 10/04/18 à 15:43, BERTRAND Joël a > BJ> > écrit : > BJ> > BJ> Je ne sais pas sur quoi agit l'option -4 (hormis le fait > BJ> > BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que > BJ> > BJ> même interrogés en IPv4, certains DNS renvoient des résolutions > BJ> > BJ> IPv6 et c'est au soft de faire le tri dans les réponses. Mais > BJ> > BJ> encore une fois, je ne sais pas si ssh est assez subtil pour > BJ> > BJ> cela. > BJ> > > BJ> > Je pense quand même que même si la requête dns lui renvoyait du , > BJ> > il n'utiliserait que les champs A pour se connecter. > BJ> > > BJ> > BJ> Peux-tu poster ici un dump réseau complet de quelque > BJ> > BJ> chose qui fonctionne et d'une transaction qui échoue ? Par > BJ> > BJ> complet, c'est avec les options -v et -e. > BJ> > > BJ> > Avec git on ne peut pas activer -e > BJ> > BJ> Je pensais à un tcpdump bien senti. > > J'avais mis un résumé dans un mail précédent (04/04/18 à 08:35), pour la > totale c'est là > > - connexion git+ssh qui foire > > https://framadrop.org/r/V20FQ0lVJQ#hUYB/LRdm74/ytm+wl4LllfHIYrIq0QdMsoDY/az4jA= > > - connexions du browser qui déconnent aussi > > https://framadrop.org/r/iLXjIVEK69#xiJSfmU3WB7bDZWvO9WUJAqHz5t5lvYyJvdvAEOdRT4= > > BJ> > La même commande > BJ> > env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers=aes256-ctr" git pull > BJ> > sur le dépôt qui plante (1) et un qui fonctionne (à condition > BJ> > d'imposer le cipher) (2) > BJ> > BJ> Rhohh... Idée ! J'ai eu un truc similaire avec les concetés > BJ> debianesques. Il y a des chiffrements qui ont disparu de certaines > BJ> versions récentes d'OpenSSL qui m'empêchaient d'envoyer des mails à > BJ> certains (gros) domaines. Il m'a fallu patcher sendmail pour contourner > BJ> le problème !... > BJ> > BJ> Peux-tu compiler un OpenSSL officiel (non patché par Debian) ? > > Pas la peine, le pb ne peut pas venir de là car > - en imposant le cipher, on voit que le handshake ssh se passe bien donc > ils ont trouvé un cipher commun > - ça fonctionne bien depuis mon portable, qui est aussi sous stretch, avec > le même ssh/openssl/clé ssh (et la même connexion, j'ai même été jusqu'à > lui coller même mac, en utilisant le même cable RJ45 sur le même port de > la même box) > > => le pb vient donc de la gestion du réseau par mon desktop vs laptop. Vu > que les deux ont la même debian, reste > - le driver de la carte réseau, et je comprends vraiment pas comment ça > peut influer sur des échanges chiffrés (à priori lui n'agit que sur la > couche réseau, pas applicative). > - le (dé)chiffrement AES par le cpu > > Y'a moyen de changer des paramètres du kernel pour modifier la gestion AES > du cpu ? > > Vous voyez une autre piste ? Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de suite. Mais si ce n'est pas une histoire de chiffrement, ça peut ressembler à une histoire de chemin. > BJ> Si c'est bien ce à quoi je pense, il faudrait que des gens qui > BJ> ne comprennent pas les implications de leurs patches arrêtent de les > BJ> imposer... > > Sur la suppression de certains ciphers d'openssl, c'est un choix délibéré > je suppose, interdire les connexions qui paraissent sécurisées mais ne le > sont pas car utilisant des ciphers vulnérables. > > C'est le choix de firefox & chrome par ex, ils refusent désormais les > connexions https vers des sites qui ne font pas de TLS ou utilisent des > ciphers trop faibles. C'est surtout très bête dans le cas d'une bibliothèque générale. Lorsque tu ne peux plus envoyer de mails à la moitié du monde, tu es en général content (d'autant que les gars qui ont patché cela n'ont pas patché les outils utilisant cette bibliothèque pour leur permettre de rester isofonctionnels). Cordialement, JKB