Reprise du message précédent :

Très légère.    
 

Plus maintenu par nvidia.  
On peut peut-être bricoler mais non merci. Dans tous les cas il n'y aura plus de correctif de sécurité.

 
De ce que je comprends, c'est nvidia qui construit/compile son blob pour être compatible avec le noyau linux. Donc si nvidia arrête de supporter un modèle de GPU (et donc de founir le blob adapté aux nouvelles version de linux), ben on est coincés, on ne peut plus non plus mettre à jour le noyau linux.
 

 
 
C'est sûr que c'est vieux mais bon, c'est dommage qu'un matos qui fonctionne et répond encore à un besoin doive être mis à la poubelle juste parce que le constructeur ne produit plus le driver.

Par contre mes Intel GMA 900 devrait toujours être maintenu. Dommage qu'ils soient à la peine sur de la vidéo 720p

Edith : @Ivy : Le dev ça coute du pognon, et maintenir un GPU bas de gamme 12 ans d'âge pour 3 pélos...

D'ou l’intérêt des pilotes openSource.

C'est dev gratuitement donc c'est nul

T'iras dire ça aux dev AMd qui travaillent sur les pilotes openSource.

Sur un Thinkpad T23 et son PIII-M à 1GHz, ça divisait à peu près les perfs de lecture/écriture par deux.
 

Souci que Nvidia a décidé que ce n'était plus nécessaire de les supporter, et qu'on ne dispose pas des sources du driver.
Il y a encore quelques années, on avait pas vraiment le choix quand on avait besoin d'un minimum de puissance, vu que les drivers ATI (le proprio comme le libre) étaient moisis.
Aujourd'hui, la question ne se pose plus.

Juste par curiosité, avais-tu essayé d'installer le .run du dernier pilote supportant ton gpu avec un kernel récent ?
https://download.nvidia.com/
De mémoire, il fallait avoir linux-header d'installé puis au reboot, lancer en tty le .run.

j'ai aussi \o/ un vieux "nettop" de marque zotac avec 2G de ram. ca me faisait un petit serveur/routeur à l'époque
ca faisait bien le boulot, mais sans aes, mes connexions vpn effondraient le cpu à chaque foi

Nop pas essayé, mais comme évoqué, même si ça passe, ça veut quand même dire garder les failles ad viternam.

J'ai une appliance à base d'amd neon, ça marche bien ces petits cpus.
(et ça gère l'aes )

Pas faux, mêler de l'ancien plus supporté avec du récent c'est pas top.
Merci aptitude qui m'a pas montré l'écran de confirmation avec le purge nvidia-driver
Bon, je vais tester un ancien .run sur kernel 5.12
C'était quoi ton gpu ?

Vous me comfortez dans ma position "pas de pilotes proprio sur Linux" là.

NVIDIA GeForce GTS 250M
https://www.notebookcheck.biz/NVIDI [...] 030.0.html

J'ai trouvé de l'occupation pour la soirée.
J'arrive même pas à me débarrasser de xserver-xorg-video-nvidia car... il n'est pas installé, et quand j'essaye de l'installer, il arrive pas à l'installer car... il n'est pas installé.  
Et là aptitude qui me dit "Internal Error, No file name for nvidia-driver:amd64"

Quand ca marche, faut plus toucher.

l'erreur en question lors de la suppression:

Pas le temps la (et pas la motivation ), mais tu peux toujours télécharger et décompresser le paquet et chercher d'où vient cette erreur. Le post-removal script doit être open source je suppose donc en clair. https://packages.debian.org/buster/ [...] deo-nvidia

edit: Il doit même déjà être sur ton disque ce script forçement, quelque part...

edit2: Tu n'es PAS en mode graphique la?

Solution trouvée sur https://forums.debian.net/viewtopic [...] 75#p536175
 
Faut faire croire à dpkg que le paquet n'est pas installé, pas joli joli, mais j'ai pas compris comment le script post-removal pouvait envoyer un retour 20 (ou alors c'était pas le bon script que je regardais):

puis apt update, et remove/install comme d'habitude.
Je suis à nouveau sur les drivers 460.

Au pif: Ton 20 c'est un 20 ou un 0x20? Ou alors mauvais script.

non, c'est bien 20, mais je pense que je ne regardais pas le bon script (/var/lib/dpkg/info/xserver-xorg-video-nvidia.postrm)

Bonjour,
 
parlant de trifouillages dans les entrailles, je tente ma chance ici car c'est spécifique Linux quand même: J'ai deux modules FT232H avec une puce FTDI de chez Aliexpress. J'ai besoin de distinguer les deux, l'un doit servir pour le JTAG avec openocd et l'autre comme port série /dev/ttyX. Le problème c'est que les deux sont strictement identiques aux yeux de Linux car même le n° de série est identique (Bonjour les fakes...), du coup openocd essaye d'utiliser le mauvais evidemment et rien ne fonctionne. Une idée comment régler ça? Je ne veux pas utiliser l'utilitaire officiel FTDI pour assigner un n° de série car, vous en avez peut-être entendu parler, FTDI avait sorti un pilote qui briquait les fakes et ces modules valent quand même quelque euros et faux ou pas, en principe ils fonctionnent très bien.
 
J'ai plusieurs idées mais pour l'instant rien qui fonctionne / rien de convainquant:
-Assigner un n° de série unique à chaque module en utilisant un soft FOSS si ça existe.
-Bricoler avec udev pour mettre une espèce d'"alias" à chaque module en fonction du port USB (qui peut changer mais ça serait une solution temporaire au moins), mais cette notion d'"alias" reste floue, je ne sais pas si il y a un paramètre openocd qui va bien.
-...
 
Une idée? Il  y a pas un sujet "électronique manchot" quelque part?  

Pour changer le numéro de série, les autres attributs, ou le VID/PID, tu peux utiliser ftdi-eeprom !
Et pour udev:
ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6014", ATTRS{manufacturer}=="RatDeCombat", ATTRS{product}=="RatDeCombatJTAG", SYMLINK+="ratdecombatjtag"
Du coup, tu auras un device node "/dev/ratdecombatjtag" ...

Question bête, mais cette EEPROM, elle est externe ou interne aux puces FTDI? J'ai installé et lancé ftdi-eeprom (console root) mais il me dit "EEPROM size: -1"...

edit: J'ai bien viré le ftdi_sio avec modprobe -r .

edit3: Ok, RTFM -> EEPROM externe à priori non présente sur mon module...

Je vais voir pour udev.

Merci en tout cas!

edit2: Faudra que je change la commande udev pour prendre en compte le port USB, car justement j'ai DEUX modules FTDI ave le même Vendor:Product...

Dans ce cas, ATTRS{devpath} est ton ami

Dites les pros, question siouplaît.
 
J'ai une VM sur laquelle j'ai mis un peu de sécurité, en particulier l'utilisateur root locké et les partitions chiffrées.
Or une partoche a des soucis de filesystem, et au reboot, Debian passe en mode maintenance et me demande le mot de passe du user root... Qui ne fonctionne pas vu que le compte est bloqué!
 
Du coup, vu que je n'ai jamais fait le truc, c'est possible de booter sur un CD Live, déchiffrer les partitions et réactiver root ?
 
Merci

Oui c'est possible, mais il ne faut pas déchiffrer tout mais simplement "mount"er les partitions et faire ce que tu veux (backups, check file system, ...)

On parle bien d'un chiffrement LUKS? Je peux retrouver les bonnes commandes si tu veux.

Ah mais si c'est une VM il doit y avoir moyen de mounter directement le qcow2 dans le host... Je vais vérifier.

Ah et merci 404 Not Found, je vais regarder ça. Pour l'instant j'en ai marre, les UART c'est vraiment pas fiable du tout, mais en même temps c'est facile à utiliser... Cochonnerie.

Bien sûr.
cryptsetup et chroot FTW !

Bon, déjà ceci https://gist.github.com/shamil/62935d9b456a6f9877b5 fonctionne (je viens de tester) après faudra rajouter quelque trucs à cause du chiffrement, mais je n'ai pas de VM chiffrée sous la main... C'est cryptsetup open <device> <name> qu'il faut je crois.

Je m'en doutais un peu.  
C'est du VMware, et les partoches sont chiffrées avec LUKS je pense, ça a été fait à l'install.
Merci pour vos retours

cryptsetup luksOpen /dev/lapartitionchiffree lenomduvolume
Puis, tu peux trouver le volume "déchiffré" dans /dev/mapper/lenomduvolume, faire ce que tu as à faire puis un coup de cryptsetup luksClose pour fermer proprement ...
 
Et les UART c'est très fiable, rat
J'ai des centaines de machines qui tournent avec une carte qui utilise un couple FTDI/AVR à 2Mbps. Jamais un raté en utilisant le handshaking hardware.
Cerise sur le gâteau, en câblant le deuxième port du FTDI 2232H sur les pins JTAG de l'AVR, je peux les reflasher depuis la machine hôte.

Oui mais toi tu utilises des vrais FTDI pas de chez Aliexpress je suppose?  
Le handshaking hardware j'ai tenté, mais je perd toujours des octets. Après je sais pas si mon code au niveau du FPGA (pas de µC, ça serait trop simple) fonctionne toujours correctement.
Les 2232H j'avais regardé, j'hésite à en prendre mais même sur Ali c'est pas donné de mémoire. Après ça pourrait être pratique. Enfin bref, on est HS ici...

Bon, je reviens sur cette histoire UART et Linux car l'info pourrait servir à éviter bien des ennuis à certains: Les octets que je perdais étaient des 0x11 ou 0x13 - ça parle à quelqu'un? Eh oui, ce sont XON et XOFF (ou l'inverse ) , autrement dit le flow control XON/XOFF est activé par défaut dans le pilote ftdi_sio et peut-être d'autres et cela fait que certains octets justement sont "filtrés". Il faut utiliser stty -F /dev/ttyUSBn $baudrate raw.
 
Avant avec des données bidons (/dev/urandom) je pouvais au maximum transmettre une centaine d'octets en gros, là j'ai pu transmettre 10Mo entre deux FTDI sans aucun bit de changé.
 
Enfin voilà, de rien si ça peut servir ou désolé pour le spam le cas échéant.  
 
Quelqu'un sait si c'est pareil sous Windows?

Tu fais quoi avec tous ces rs232 si c'est ps indiscret ?

C'est pas dans le driver, c'est ton stty.
Si tu fais juste un open() sur le device node, sans utiliser les flags IXON / IXOFF / CRTSCTS de termios.h (via tcsetattr), le port est ouvert "en raw" ...
 

Au boulot, je fais des machines basées sur un CPU x86 avec une carte qui se branche en USB pour gérer toute l'électronique.

Je viens de passer en bullseye 2 PC, et sur l'un des deux (un très moderne Acer Aspire 3100 de 2007 ), vlc ne fonctionne plus depuis. Il se lance, la vidéo commence à se charger, on voit même la durée qui s'affiche, puis tout se ferme. En console on a ceci :
 

 
Je n'ai touché à rien concernant le driver vidéo lors de l'upgrade.
 
 
Identifiant du GPU via lspci :
 

 
Radeon Xpress 200 : https://en.wikipedia.org/wiki/Xpress_200
 

 
qui renvoie vers la page radeon R300. Donc c'est le driver r300 nécessaire dans mon cas.
 
J'ai le package firmware-amd-graphics installé (et à jour), il supporte bien r300 :
 

 
Au boot le binaire pour R300 semble se charger :
 

 
J'ai regardé le problèmes connus pour l'upgrade, rien trouvé qui corresponde.
 
 

peut-être une piste ici :  
https://bbs.archlinux.org/viewtopic.php?id=252428

VLC c'est pourri, seul mpv que je repecte  

À part ça, un mauvais réglage de la sortie vidéo peut aussi provoquer un mauvais fonctionnement. Perso, j’ai dû forcer à « OpenGL » mais il peut être nécessaire de forcer « X11 », aussi.

pluzun.
fut un teps ou j'utilisais vlc, mais j'avais trop de problemes avec.. installé mpv et plus de probleme depuis

Autant pour moi.  
En effet, c'est stty qui par défault utilise "sane" je crois que s'appelle le réglage et ce dernier inclut le flow control XON/XOFF. Idem pour screen qui doit se baser sur stty.

Et perso +1 pour VLC de chez deb-multi.

Il te manque probablement une lib opengl, mesa, whatever.
 
Tu peux aussi tenter avec un autre driver que gl
 
Vérifie aussi que ton VLC provient bien des dépôt Debian et pas d'un dépôt tiers qui ne serait pas à jour.

je viens de passer une de mes VM debian, de buster à bullseye, avec pas mal de trucs dessus (bind, unbound, nginx, heartbeat, postfix et quelques autres truc)..
pas de probleme particulier
 
ne pas oublier le changement de nom pour le repo security, ca marche tout de suite mieux
(deb http://security.debian.org/debian-security bullseye-security main)
 
edit: un truc à fair attention quand on utilise le DNS bind9: le nom du service a changé.
dorénavant il ne s'appelle plus bind mais named  

Unbound aussi change entre Buster et Bullseye, son fichier de config doit commencer par server: maintenant sinon il plante.