Re: Re : bulleye et vieille carte graphique nvidia
Bonjour, Le 03/02/2022 à 20:20, Jose CHARTERS a écrit : Bonsoir, Quelque soit la version du pilote nvidia proriétaire, j'ai un affichage dégradé. Mais je crois avoir anticiper cette réponse, voir plus haut dans mon mail. Idem pour nvidia-detect. Normal puisque seule la version 304 supporte ta carte. https://www.nvidia.fr/Download/driverResults.aspx/123849/fr Donc si tu n'arrives pas à faire fonctionner le pilote nouveau correctement, l'installation de ce pilote propriétaire sous Bullseye est un peu compliquée car il faut downgrader Linux kernel 4.13 et X.Org Server 1.19. Au cas où... : https://forums.debian.net/viewtopic.php?t=14 Et le README peut être utile pour configurer : http://us.download.nvidia.com/XFree86/Linux-x86_64/304.137/README/index.html Luc.
Re: Re : bulleye et vieille carte graphique nvidia
Le 08/02/2022 à 12:19, Olivier a écrit : @Luc J'avais compris que la principale raison de l'abandon par Nouveau des vieilles cartes graphiques était l'impossibilité d'implémenter des fonctions comme l'hibernation. J'ai pour ma part une GeForce 8400 GS Rev. 2: - dont le firmware ne se charge pas dans Bullseye - qui fonctionne normalement (pour l'utilisation très simple que j'en ai) - mais qui m'affiche un écran gris illisible en sortie de mise en veille (au point de devoir re-démarrer) Cette carte est supporté par la version 340.108 https://www.nvidia.fr/Download/driverResults.aspx/156196/fr Dois-je comprendre que dans ce cas de figure, les pilotes fournis par NVidia sont plus complets ou bien au contraire, qu'ils sont au même niveau fonctionnel que ceux de Nouveau ? Je ne suis pas un spécialiste et sachant que ces pilotes évoluent indépendamment, je ne sais pas quelles fonctions sont implémentés dans l'un et pas dans l'autre. Pour ma part, quand j'ai trop de problèmes avec le pilote nouveau j'installe le pilote proprio pour voir si cela résout les problèmes. En l’occurrence, la version 340 compile avec le kernel 5.0. A essayer après avoir jeté un œil au README qui mentionne que l'ACPI (S3) et (S4) sont gérés : http://us.download.nvidia.com/XFree86/Linux-x86_64/340.108/README/index.html Bonne soirée, Luc.
Re: bulleye et vieille carte graphique nvidia
On Tuesday 08 February 2022 15:44:35 nicolas.patr...@gmail.com wrote: > Le 08/02/2022 15:24:46, ajh-valmer a écrit : > > > nvidia-legacy-340 ne marche plus avec Bullseye, > > elle a marché jusqu'à Buster incluse. > > Me semble t-il, apt-cache search nvidia-legacy-340 sous Bullseye, > > ne montre plus ce paquet. > Je le vois dans Sid : > > apt policy nvidia-legacy-340xx-driver > nvidia-legacy-340xx-driver: > Installé : (aucun) > Candidat : 340.108-12 > Table de version : > 340.108-12 500 Oui, mais dans Sid... pas Bullseye. J'ai tenté de l'installer sur bullseye : échec.
Re : bulleye et vieille carte graphique nvidia
Le 08/02/2022 15:24:46, ajh-valmer a écrit : > nvidia-legacy-340 ne marche plus avec Bullseye, > elle a marché jusqu'à Buster incluse. > Me semble t-il, apt-cache search nvidia-legacy-340 sous Bullseye, > ne montre plus ce paquet. Je le vois dans Sid : > apt policy nvidia-legacy-340xx-driver nvidia-legacy-340xx-driver: Installé : (aucun) Candidat : 340.108-12 Table de version : 340.108-12 500 500 http://ftp.fr.debian.org/debian unstable/non-free i386 Packages nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Re: bulleye et vieille carte graphique nvidia
On Tuesday 08 February 2022 14:05:15 didier.gau...@gmail.com wrote: > Le mardi 08 février 2022 à 13:57 didier gaumet a écrit : > j'ai répondu un peu vite: le pilote nvidia-legacy-340 n'est pas proposé > dans Debian mais il est toujours téléchargeable chez Nvidia: > https://www.nvidia.fr/Download/driverResults.aspx/156196/fr > par contre je me demande si il ne pose pas problème avec Bullseye vu > que debian ne le propose pas (c'est le legacy-390 qui est proposé) nvidia-legacy-340 ne marche plus avec Bullseye, elle a marché jusqu'à Buster incluse. Me semble t-il, apt-cache search nvidia-legacy-340 sous Bullseye, ne montre plus ce paquet.
Re: Re : bulleye et vieille carte graphique nvidia
Le mardi 08 février 2022 à 13:57 +0100, didier gaumet a écrit : [...] > Quant à la question de savoir si le driver nvidia est plus ou moins > performant que le driver nouveau: c'est simple, pour ta carte et ton > OS, nvidia ne fournit pas de driver j'ai répondu un peu vite: le pilote nvidia-legacy-340 n'est pas proposé dans Debian mais il est toujours téléchargeable chez Nvidia: https://www.nvidia.fr/Download/driverResults.aspx/156196/fr par contre je me demande si il ne pose pas problème avec Bullseye vu que debian ne le propose pas (c'est le legacy-390 qui est proposé)
Re: Installer un scanner Canon MX320 sous Buster
une petite recherche "scangear deb" amène sur le site canadien de Canon où la version scangear2 4.10 relativement récente (2020) est téléchargeable, comprenant les versions 32 et 64 bits: https://canoncanadafr.custhelp.com/app/answers/answer_view/a_id/1034243/~/scangear-mp-v.-4.10-for-linux-%28debian-packagearchive%29
Re: Re : bulleye et vieille carte graphique nvidia
Le mardi 08 février 2022 à 12:19 +0100, Olivier a écrit : > @Luc > J'avais compris que la principale raison de l'abandon par Nouveau des > vieilles cartes graphiques était l'impossibilité d'implémenter des > fonctions comme l'hibernation. > > J'ai pour ma part une GeForce 8400 GS Rev. 2: > - dont le firmware ne se charge pas dans Bullseye > - qui fonctionne normalement (pour l'utilisation très simple que j'en > ai) > - mais qui m'affiche un écran gris illisible en sortie de mise en > veille (au point de devoir re-démarrer) > > Dois-je comprendre que dans ce cas de figure, les pilotes fournis par > NVidia sont plus complets ou bien au contraire, qu'ils sont au même > niveau fonctionnel que ceux de Nouveau ? > > > [ 42.401020] nouveau :01:00.0: firmware: failed to load > nouveau/nv98_fuc084 (-2) > [ 42.401029] firmware_class: See https://wiki.debian.org/Firmware > for information about missing firmware Je ne comprends pas ta réflexion sur le pilote "nouveau" et son abandon supposé des anciennes cartes graphiques: ce pilote gère toujours beaucoup d'anciennes cartes graphiques Concernant la gestion de l'alim de la carte, la tienne (groupe MV50) est marquée WIP (en cours de réalisation) donc pas implémentée, au moins pour le moment https://nouveau.freedesktop.org/FeatureMatrix.html Quant à la question de savoir si le driver nvidia est plus ou moins performant que le driver nouveau: c'est simple, pour ta carte et ton OS, nvidia ne fournit pas de driver
Re: Re : bulleye et vieille carte graphique nvidia
@Luc J'avais compris que la principale raison de l'abandon par Nouveau des vieilles cartes graphiques était l'impossibilité d'implémenter des fonctions comme l'hibernation. J'ai pour ma part une GeForce 8400 GS Rev. 2: - dont le firmware ne se charge pas dans Bullseye - qui fonctionne normalement (pour l'utilisation très simple que j'en ai) - mais qui m'affiche un écran gris illisible en sortie de mise en veille (au point de devoir re-démarrer) Dois-je comprendre que dans ce cas de figure, les pilotes fournis par NVidia sont plus complets ou bien au contraire, qu'ils sont au même niveau fonctionnel que ceux de Nouveau ? [ 42.401020] nouveau :01:00.0: firmware: failed to load nouveau/nv98_fuc084 (-2) [ 42.401029] firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware Le lun. 7 févr. 2022 à 18:26, Luc Novales a écrit : > > Bonsoir, > > Le 03/02/2022 à 20:20, Jose CHARTERS a écrit : > > Le 02/02/2022 à 09:32, nicolas.patr...@gmail.com a écrit : > > Le 01/02/2022 21:11:30, Jose CHARTERS a écrit : > ... > > nvidia-detect, et celui ci me dit : > Detected NVIDIA GPUs: > 04:00.0 VGA compatible controller [0300]: NVIDIA Corporation G72 > [GeForce 7200 GS / 7300 SE] [10de:01d3] (rev a1) > Checking card: NVIDIA Corporation G72 [GeForce 7200 GS / 7300 SE] > (rev a1) > Your card is only supported by the 304 legacy drivers series, which is > only available up to stretch. > > nvidia-ndetect a raison, ta carte n'est plus supportée dans le legacy-340. > > La dernière version du pilote qui la supporte est le 304, si le pilote > nouveau ne te suffit pas, celui ci devrait convenir. > > https://www.nvidia.fr/Download/driverResults.aspx/123849/fr > > Bonne soirée, > > Luc. > >
Re: Installer un scanner Canon MX320 sous Buster
J'ai vu la même chose que toi: des pilotes canon mais pour une machine i386 alors que la mienne est x86_64. Par chance, la machine à laquelle est connecté ce scanner héberge des VM (KVM). Peut-être qu'en dédiant une VM 32 bits à ça, je pourrai retomber sur mes pattes. Le lun. 7 févr. 2022 à 21:04, Christophe Musseau a écrit : > > > > Le lun. 7 févr. 2022 à 19:55, Olivier a écrit : >> >> Bonjour, >> >> J'ai une vieille multi-fonction Canon MX320 dotée d'une interface USB. >> Je souhaite, dans un premier temps, l'utiliser comme scanner en ligne >> de commande sur une machine sous Buster (les fonctions d'impression ne >> m'intéressent pas). >> >> Elle est correctement détectée : >> # scanimage -L >> device `pixma:04A91736_154338' is a CANON Canon PIXMA MX320 >> multi-function peripheral >> >> Par contre : >> # scanimage -d "pixma:04A91736_154338" > /tmp/foo.bar >> scanimage: sane_read: Error during device I/O >> ou >> $scanimage -d "pixma:04A91736_154338" > /tmp/toto >> scanimage: sane_read: Error during device I/O >> >> Dans mes logs je vois aussi quand j'allume le scanner: >> systemd-udevd[11797]: Process '/bin/setfacl -m g:scanner:rw ' failed >> with exit code 2. >> >> 1. Quelqu'un a-t-il utilisé avec succès la fonction scanner sous >> Buster/x86_64 avec une machine Canon Pixma quelconque ? et sous >> Bullseye ? >> >> 2. Un conseil ? >> >> Slts >> >> > >> Bonjour > > > Sur le site de Canon on trouve divers pilotes pour des machines sous > Gnu/Linux. Y compris des paquets .deb. J'ai pu (et encore aujourd'hui) > utiliser trois ou quatre modèles Pixma avec Debian, sans souci. Pour le > modèle MX320 j'ai vu (rapidement) qu'il n'y avait que des pilotes pour i386. > > Bonne journée >
Re: Re : Re: Remettre le fichier GRUB à neuf
Bonjour à tous, J'ai été confronté à ce problème il y a quelques années et je partais d'un disque SSD vierge (120 Go). Donc effectivement, je l'ai formaté en GPT (128 partitions disponibles), une petite partition de 100 Mo a été créée en tête de disque, qui contenait EFI. Ensuite, j'ai installé une Debian stable, comportant Grub. Par la suite, j'ai installé d'autres distributions en parallèle et, comme le dit Pierre, il est important de ne plus installer de Grub sur ces distributions "secondaires" (ce n'est pas toujours évident, car suivant le mode d'installation, c'est parfois fait automatiquement). Pour éliminer ce problème, j'ai installé rEFind sur ma Debian stable. Il s'agit d'un boot manager qui prend la main dès le démarrage et auquel on peut passer des commandes permettant de modifier l'ordre de boot. Cela m'a grandement simplifié la vie... Bonne journée, Marc Le 08/02/2022 à 02:52, k6dedi...@free.fr a écrit : Bonjour à tous, J'ai plusieurs OS Linux sur la même machine. J'ai galéré pour les réinstaller dernièrement. Et je pense que cela provient de la manière dont chaque distribution s'est mise à gérer l'EFI. Il y a des approches très différentes. Certains disent que la partition EFI doit être immédiatement positionnée après la GPT, d'autres disent que la partition EFI doit être montée dans le répertoire /boot, d'autres disent que EFI ne peut qu'être un répertoire, soit une cacophonie qui donne divers résultats. J'ai dû mettre chaque distribution sur un disque séparé pour arriver à pouvoir les faire fonctionner. (installation en branchant chaque fois un seul disque.) Est-ce une piste qui peut aider à résoudre le problème, je vous le souhaite. Cassis - Mail d'origine - De: Pierre Meurisse À: debian-user-french@lists.debian.org Envoyé: Sat, 05 Feb 2022 11:31:58 +0100 (CET) Objet: Re: Remettre le fichier GRUB à neuf Bonjour à tous, j'ai plusieurs systèmes sur toutes mes machines et je n'ai pas eu d'ennuis particuliers avec grub. Il me semble important d'installer grub sur _un seul_ système, celui-ci appelant les autres systèmes installés. Il suffit, lors d'une nouvelle installation de refuser l'installation de grub et de redémarrer celle contenant _le_ grub pour faire un update-grub. Hope this helps. Le Sat, Feb 05, 2022 at 08:37:52AM +0100, Pierre Malard a écrit : Bonjour, Je vois quelques informations qui me semblent étranges : 1) Erreurs UUID === La seule partition utilisée lors d’un boot est la partition Swap principale. Lister les UUID avec un « blkid » et vérifier dans le /etc/fstab qu’il n’y a pas d’erreur. Éventuellement forcer l’utilisation de la Swap dans le fichier « /etc/initramfs-tools/conf.d/resume » avec une ligne comme ça : RESUME=UUID= Au besoin régénérer les UUID si besoin (copie d’une autre installation par exemple) Avec un système de fichiers EXTn, la commande est : # tune2fs -U $(uuidgen) /dev/ Avec une partition XFS : # xfs_admin -U $(uuidgen) /dev/ Clearing log and setting UUID writing all SBs new UUID = X----X Avec une partition SWAP : # mkswap -U $(uuidgen) /dev/ mkswap: /dev/ : avertissement : effacement de l'ancienne signature swap. Configure l'espace d'échange (swap) en version 1, taille… pas d'étiquette, UUID=X----X Avec une partition FAT : # mlabel -N $(uuidgen) /dev/ 2) Régénération du GRUB avec « update-grub » et UEFI Si le boot s’appuie sur UEFI cela devrait être accompagné d’un partitionnement GPT et non MSDOS. Il est peut-être préférable de le dire à « update-grub » et que le système ait le paquet nécessaire (« grub-efi »). Il faut également que la partition EFI soit montée sur /boot/efi. Ensuite avec sdX le disque où se trouve le système : # grub-install —modules=part_gpt --target=x86_64-efi \ --efi-directory=/boot/efi --bootloader-id=debian \ --recheck --debug /dev/ Vérifier qu’il existe un répertoire « /boot/efi/EFI/boot », le créer au besoin. Copier le fichier « grubx64.efi » dedans : # cp /boot/efi/EFI/debian/grubx64.efi \ /boot/efi/EFI/boot/bootx64.efi Chez moi ça fonctionne… (https://wiki.debian-fr.xyz/Debian_%26_UEFI) En espérant vous aider Le 4 févr. 2022 à 23:15, didier gaumet a écrit : Le vendredi 04 février 2022 à 22:47 +0100, ajh-valmer a écrit : [...] Est-ce que je peux ou dois effacer le contenu de "/etc/grub.d" ? car faire le ménage dans les fichiers de /etc/grub.d/ = pas facile. surtout pas! ce sont des fichiers indispensables au fonctionnement de Grub2 le contenu des fichiers 40_custom et 41_custom doit être le suivant (à modifier si ce n'est pas le cas): didier@hp-notebook14:~$ cat /etc/grub.d/40_custom #!/bin/sh exec tail -n +3 $0 # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the
