Re: Écran noir après mise à jour Debian 11
On Sunday 02 January 2022 21:22:34 Romain P. wrote: > Au début de l'automne, suite à la mise à jour vers Debian 11, au > redémarrage, après GRUB, après des lignes de texte, l'écran reste noir. > "Ctrl Alt Suppr" permet de faire apparaître les ligne de texte qui > précédent l'arrêt. > Lors de la mise à jour il y a eu un message d'avertissement concernant > l'affichage ou les pilotes NVidia. > Je ne retrouve pas la capture d'écran que je croyais avoir enregistrée. > Je n'avais ni pilote Nvidia constructeur, ni les pilotes génériques par > défaut, mais d'autres alternatifs. > Comment remettre le pilote graphique par défaut ou un autre qui fonctionne ? > Dans les options de démarrage GRUB, si je choisi les 2 plus anciennes > version, ça démarre . Désolé, je ne réponds pas au problème. Le mien est proche : je n'arrive plus à lancer le bureau graphique (que la console en mode login). (Xorg ne semble pas se lancer). Ma carte vidéo est une Nvidia geforce GE 6150 nforce 430. Quel est le mode opératoire avec "xserver-xorg-video-nouveau" ? (je n'ai rien trouvé de fonctionnel sur la toile malgré bien des recherches). Je rame depuis des jours... Faut-il installer d'autres paquets et lesquels ? Merci d'un site explicatif (howto) qui donne la bonne solution. A. Valmer je suis sous Bullseye 64 bits (Debian 11).
Écran noir après mise à jour Debian 11
Bonsoir ☺ Au début de l'automne, suite à la mise à jour vers Debian 11, au redémarrage, après GRUB, après des lignes de texte, l'écran reste noir. "Ctrl Alt Suppr" permet de faire apparaître les ligne de texte qui précédent l'arrêt. Lors de la mise à jour il y a eu un message d'avertissement concernant l'affichage ou les pilotes NVidia. Je ne retrouve pas la capture d'écran que je croyais avoir enregistrée. Je n'avais ni pilote Nvidia constructeur, ni les pilotes génériques par défaut, mais d'autres alternatifs. Comment remettre le pilote graphique par défaut ou un autre qui fonctionne ? Dans les options de démarrage GRUB, si je choisi les 2 plus anciennes version, ça démarre . Merci Romain
Nettoyage du spam : décembre 2021
Bonjour, Comme nous sommes en janvier, il est désormais possible de traiter les archives du mois de décembre 2021 des listes francophones. N'oubliez bien sûr pas d'ajouter votre nom à la liste des relecteurs pour que nous sachions où nous en sommes. Détails du processus de nettoyage du spam sur : https://wiki.debian.org/I18n/FrenchSpamClean
Re: Paquet gksu
Parfait! Merci à vous Le 02/01/2022 à 17:30, Jean-Pierre Giraud a écrit : Bonjour, Le 02/01/2022 à 17:12, Klaus Becker a écrit : Am 02/01/2022 um 16:08 schrieb Thierry: Bonjour et bonne année à tous je viens de constater que le paquet gksu (pour la commande gksudo) n'est plus disponible depuis Buster. Pour quelle raison? et y a-t-il une commande équivalente? Son développement s'est arrêté dans Debian vers 2014 et il a été supprimé de testing et d'unstable en 2018. Merci $ apt-cache search lxqt-sudo lxqt-sudo - frontal graphique en Qt pour sudo pur lxqt-sudo-l10n - paquet de langue pour lxqt-sudo bonne année Klaus Une autre alternative : gexec Amicalement, jipege
Re: Paquet gksu
Bonjour, Le 02/01/2022 à 17:12, Klaus Becker a écrit : Am 02/01/2022 um 16:08 schrieb Thierry: Bonjour et bonne année à tous je viens de constater que le paquet gksu (pour la commande gksudo) n'est plus disponible depuis Buster. Pour quelle raison? et y a-t-il une commande équivalente? Son développement s'est arrêté dans Debian vers 2014 et il a été supprimé de testing et d'unstable en 2018. Merci $ apt-cache search lxqt-sudo lxqt-sudo - frontal graphique en Qt pour sudo pur lxqt-sudo-l10n - paquet de langue pour lxqt-sudo bonne année Klaus Une autre alternative : gexec Amicalement, jipege
Re: Paquet gksu
Am 02/01/2022 um 16:08 schrieb Thierry: Bonjour et bonne année à tous je viens de constater que le paquet gksu (pour la commande gksudo) n'est plus disponible depuis Buster. Pour quelle raison? et y a-t-il une commande équivalente? Merci $ apt-cache search lxqt-sudo lxqt-sudo - frontal graphique en Qt pour sudo pur lxqt-sudo-l10n - paquet de langue pour lxqt-sudo bonne année Klaus
Paquet gksu
Bonjour et bonne année à tous je viens de constater que le paquet gksu (pour la commande gksudo) n'est plus disponible depuis Buster. Pour quelle raison? et y a-t-il une commande équivalente? Merci
Re: Acquisition VHS to usb : august vgb350 : compilation, je suis en terrain inconnu
Le dimanche 02 janvier 2022 à 12:58 +0100, Greg a écrit : > Hello, > > meilleurs vœux a tout ! > > j'ai reçu ceci , je ne sais pas trop quoi en faire > > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-audio.c > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-camera.c > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-cards.c > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-core.c > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-dvb.c > linux_kernel_4.11_em28xx_EVB_20190515/em28xx.h > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-i2c.c > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-input.c > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-reg.h > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-v4l.h > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-vbi.c > linux_kernel_4.11_em28xx_EVB_20190515/em28xx-video.c > > > j'ai déjà fait (la compilation est ma bête noir) > apt install linux-source-5.10 > apt install linux-headers-$(uname -r) > ( linux-headers-5.10.0-10-amd64 ) > > J'ai tenté un truc "crade" amd64-x86-ia64 (juste pour voir s'il y a > risque de plantages pour des includes des 3 kilomètres de longs) > > gcc -Wall -c em28xx-audio.c \ > -I /usr/src/linux-headers-5.10.0-10-common/include \ > -I /usr/src/linux-headers-5.10.0-10-amd64/include \ > -I /usr/src/linux-headers-5.10.0-10- > amd64/arch/x86/include/generated/ \ > -I /usr/src/linux-headers-5.10.0-10-common/arch/x86/include/ > \ > -I /usr/src/linux-headers-5.10.0-10-common/arch/ia64/include/ > \ > -I /usr/src/linux-headers-5.10.0-10- > common/arch/ia64/include/uapi \ > > > > Ben en fait, peut-être ai-je une vue déformée de la situation mais, en gros, comment se sont déroulés vos échanges? Je veux dire par là que si par exemple tu sollicites le constructeur en lui disant "j'ai un problème avec le module em28xx sous Linux", qu'un commercial transmet en le déformant le souci à un technicien, tu finis par recevoir les sources d'un module dèjà présent dans les sources du noyau de ta Debian et tu recompiles une vieille version alors qu'un module binaire est déjà là. En gros tu orientes la réponse d'une personne non-qualifiée en lui posant ta question d'une certaine manière. Tout ça sans savoir réellement si le module em28xx correspond à ta carte et au chipset embarqué dessus, et si ton matériel est compatible linux, finalement? le fait que le module em28xx prenne en charge certains chipsets Empia ne signifie pas forcément que ton chipset particulier soit supporté par ce module. Tu pourrais éventuellement jeter un oeil au fichier em28xx.h qui t'a été transmis pour voir si il mentionne une reférence à ta carte particulière et si il est différent du fichier em28xx actuel présent dans les sources du noyau Linux: https://github.com/torvalds/linux/blob/master/drivers/media/usb/em28xx/em28xx.h sous la marque August ta carte n'est pas indiquée comme prise en charge par le module dans les sources officielles, peut-être sous une autre référence. Tu avais chargé le module avec le N° de carte 51 (EM2880_BOARD_TERRATEC_HYBRID_XS_FR): où t'as-t-on conseillé cela? Ta carte August est-elle une autre carte rebadgée? Et de plus si tu regardes le site August, ta carte n'est pas mentionnée comme compatible linux, au contraire de certaines de leurs autres cartes... Enfin bon, c'est peu-être moi qui suis pessimiste: je te le souhaite :-)
Re: Acquisition VHS to usb : august vgb350 : compilation, je suis en terrain inconnu
Hello, meilleurs vœux a tout ! j'ai reçu ceci , je ne sais pas trop quoi en faire linux_kernel_4.11_em28xx_EVB_20190515/em28xx-audio.c linux_kernel_4.11_em28xx_EVB_20190515/em28xx-camera.c linux_kernel_4.11_em28xx_EVB_20190515/em28xx-cards.c linux_kernel_4.11_em28xx_EVB_20190515/em28xx-core.c linux_kernel_4.11_em28xx_EVB_20190515/em28xx-dvb.c linux_kernel_4.11_em28xx_EVB_20190515/em28xx.h linux_kernel_4.11_em28xx_EVB_20190515/em28xx-i2c.c linux_kernel_4.11_em28xx_EVB_20190515/em28xx-input.c linux_kernel_4.11_em28xx_EVB_20190515/em28xx-reg.h linux_kernel_4.11_em28xx_EVB_20190515/em28xx-v4l.h linux_kernel_4.11_em28xx_EVB_20190515/em28xx-vbi.c linux_kernel_4.11_em28xx_EVB_20190515/em28xx-video.c j'ai déjà fait (la compilation est ma bête noir) apt install linux-source-5.10 apt install linux-headers-$(uname -r) ( linux-headers-5.10.0-10-amd64 ) J'ai tenté un truc "crade" amd64-x86-ia64 (juste pour voir s'il y a risque de plantages pour des includes des 3 kilomètres de longs) gcc -Wall -c em28xx-audio.c \ -I /usr/src/linux-headers-5.10.0-10-common/include \ -I /usr/src/linux-headers-5.10.0-10-amd64/include \ -I /usr/src/linux-headers-5.10.0-10-amd64/arch/x86/include/generated/ \ -I /usr/src/linux-headers-5.10.0-10-common/arch/x86/include/ \ -I /usr/src/linux-headers-5.10.0-10-common/arch/ia64/include/ \ -I /usr/src/linux-headers-5.10.0-10-common/arch/ia64/include/uapi \
Re: Re : Re: [HS] Choix d’un chipset compatible avec un APU AMD Ryzen 7
Encore une colle ;-) Franchement, même si je pense que oui, je n'en sais rien (je n'ai pas su chercher/trouver l'info): les spécifications de PCIe 4.0 semblent avoir été finalisées en 2017 puis 2020. Si je me base sur ce qui s'est passé pour le wifi, des specs sous forme de brouillon ont été implémentées dans les OS bien avant que ces specs soient officielles. Debian étant basé sur le noyau Linux, de mon point de vue c'est ce dernier qui détermine la compatibilité PCIe: ce qui importe n'est pas d'avoir telle distribution (Debian, Fedora, Archlinux...) mais la version du noyau (je crois que la compatibilité générale PCIe a été introduite avec une sous version de Linux 2.6)
Re : Re: [HS] Choix d’un chipset compatible avec un APU AMD Ryzen 7
Bonjour, Le dimanche 2 janvier 2022 à 10:57, didier gaumet a écrit : > Bonjour, > > Je ne m'y connais pas vraiment alors d'autres mieux informés corrigeront ou > préciseront mes propos, j'espère. > > Pour moi la chaîne "PCIe 4.0" est limitée par un seul de ses maillons > > compatible "PCIe 3.0". Le fonctionnement souhaité en PCIe 4.0 nécessiterait > donc: > > - un CPU (ou APU) compatible PCIe 4.0 (pour te dire quel est mon manque de > niveau à ce sujet, je pensais que le facteur compatibilité PCIe n'intervenait > pas dans un CPU, seulement dans le chipset) > - un chipset (nortbridge) compatible PCIe 4.0 > - un SSD NVMe compatible PCIe 4.0 > - un BIOS/UEFI compatible PCIe 4.0 > - un OS compatible PCIe 4.0 Une Debian stable, c'est un OS compatible PCIe 4.0 ? Merci d'avance, -- Benoit
Re: [HS] Choix d’un chipset compatible avec un APU AMD Ryzen 7
Bonjour, Je ne m'y connais pas vraiment alors d'autres mieux informés corrigeront ou préciseront mes propos, j'espère. Pour moi la chaîne "PCIe 4.0" est limitée par un seul de ses maillons compatible "PCIe 3.0". Le fonctionnement souhaité en PCIe 4.0 nécessiterait donc: - un CPU (ou APU) compatible PCIe 4.0 (pour te dire quel est mon manque de niveau à ce sujet, je pensais que le facteur compatibilité PCIe n'intervenait pas dans un CPU, seulement dans le chipset) - un chipset (nortbridge) compatible PCIe 4.0 - un SSD NVMe compatible PCIe 4.0 - un BIOS/UEFI compatible PCIe 4.0 - un OS compatible PCIe 4.0 Donc sous toutes réservers, avec ce processeur particulier, tu serais limité en PCIe 3.0
