De nouveau xsane ne trouve plus le scanner Lide 110 Canon

Support Debian
#1

Bonjour à tous,
désolé d’y revenir, mais je ne trouve pas…

Avant, ça marchait, maintenant ça ne marche plus! (sous Buster, avec jessie, ça marche encore)

ce que j’ai pu faire:

  • des essais pour utiliser Lide300, (qui ne marche pas avec Sane)

Ce que je viens d’essayer pour arranger les choses:

  • relire les discussions précédentes, et entre autre:
    SCANNER Lide 110 / 220
  • ajout de la ligne adéquate dans les règles udev de canon
  • reboot

Ce que j’ai exploré (avant d’ajouter la règle udev):

$lsusb

Bus 002 Device 003: ID 04a9:1909 Canon, Inc. CanoScan LiDE 110

sane-find-scanner:

  # sane-find-scanner will now attempt to detect your scanner. If the
  # result is different from what you expected, first make sure your
  # scanner is powered up and properly connected to your computer.

  # No SCSI scanners found. If you expected something different, make sure that
  # you have loaded a kernel SCSI driver for your SCSI adapter.

...

found USB scanner (vendor=0x04a9 [Canon], product=0x1909 [CanoScan]) at libusb:002:003
...
  # Your USB scanner was (probably) detected. It may or may not be supported by
  # SANE. Try scanimage -L and read the backen«Aucun périphérique disponible»d's manpage.

  # Not checking for parallel port scanners.

  # Most Scanners connected to the parallel port or other proprietary ports
  # can't be detected by this program.

  # You may want to run this program as root to find all devices. Once you
  # found the scanner devices, be sure to adjust access permissions as
  # necessary.

groups:

laguilde adm disk lp dialout cdrom floppy sudo audio dip www-data video plugdev staff users netdev bluetooth lpadmin scanner

grep genesys /etc/sane.d/dll.conf:

genesys

grep -A1 « LiDE 110 » /etc/sane.d/genesys.conf:

# Canon LiDE 110
usb 0x04a9 0x1909

après avoir ajouté la règle udev suivante:
$grep 1909 /etc/udev/rules.d/80-canon_mfp2.rules:

ATTR{idVendor}=="04a9", ATTR{idProduct}=="1909", MODE="666"

$mlocate dll | egrep sane:

/etc/sane.d/dll.conf
/etc/sane.d/dll.d
/etc/sane.d/dll.d/hplip
/etc/sane.d/dll.d/libsane-extras
/usr/lib/x86_64-linux-gnu/wine/fakedlls/sane.ds
/usr/local/bin/playonlinux/wineversion/1.5.14/lib/wine/fakedlls/sane.ds
/usr/local/bin/playonlinux/wineversion/1.5.14/lib64/wine/fakedlls/sane.ds
/usr/share/man/man5/sane-dll.5.gz

Maintenant, le messages d’erreur:

xsane:

«Aucun périphérique disponible»

J’ai nécessairement oublié quelque chose…
merci de m’aider à m’y retrouver.

Rkhunter: 5 warnings, 2 fichiers suspects, possible rootkits: 1... que faire?
#2

Il faut que le nom d’utilisateur dont tu te sers fasse aussi partie du groupe saned :

# usermod -a -G saned ton-utilisateur

1 J'aime
#3

Grand merci, Gilles2, c’est bien ça!

#4

Le problème revient!

Après avoir appliqué la solution de Gilles, ajouté l’utilisateur au groupe saned, j’ai pu utiliser le scanner.

Je ne comprenais pas comment ce groupe avait pu exclure l’utilisateur. (et je ne comprend toujours pas).

Ce matin, la même panne réapparaît.
À ma connaissance, le seul évènement depuis hier a été la fermeture de 2 instances de mate-terminal alors que je ne pensais en fermer qu’une seule.
Le groupe saned accueille bien encore l’utilisateur, comme l’indique la commande groups

J’ai redémarré, sans effet.

#5

saned n’avait pas l’utilisateur dans son groupe jusqu’à récemment et cela n’empêchait pas les scanners de fonctionner, mais il y a quelques semaines, j’ai dépanné le fonctionnement de mon scanner en mettant mon utilisateur dans le groupe saned.

Non seulement cela, mais sur debian-facile j’ai dépanné deux autres personnes, avec entre autres pannes en plus, en leur faisant mettre l’utilisateur dans le groupe saned.

Qu’est-ce que tu utilises comme sources.list ?

$ grep ^[^#] /etc/apt/sources.list /etc/apt/sources.list.d/*

#6

Merci Gilles2

$grep -v '^#' /etc/apt/sources.list
deb http://deb.debian.org/debian-security/ buster/updates contrib main non-free
deb http://deb.debian.org/debian/ buster contrib main non-free
deb http://deb.debian.org/debian/ buster-updates contrib main non-free
deb http://deb.debian.org/debian buster-proposed-updates contrib main non-free
deb http://deb.debian.org/debian buster-backports contrib main non-free
deb http://security.debian.org/debian-security/ buster/updates main
deb https://repo.protonvpn.com/debian unstable main

Protonvpn a été ajouté à sources.list et installé le 30 mai, mais la panne date de quelques jours avant.

De nouveau, le scanner fonctionne sans que j’ai compris ni agi (consciemment) après cette 2e panne inexpliquée.

#7

Bonjour

La commande apt ne prendra en compte que les fichiers dont le nom d’extension est list

Certains fichiers contenus dans le répertoire /etc/source.list.d/ pourraient avoir un autre nom d’extension (par exempe : save)

Donc, il vaudrait mieux spécifier le nom d’extension :

grep -n ^[^#] /etc/apt/{sources.list,sources.list.d/*.list} 2>/dev/null
#8

merci encore
le répertoire sources.list.d/ est vide, et j’ai bricolé ma commande juste pour limiter cet envoi à l’essentiel, sachant bien ce que j’y ai mis.
Mais la leçon de rigueur est toujours bienvenue.

PS et j’ai répondu un peu vite, avant d’avoir lu cette ligne de commande

#9

@ josephtux

Désolé ,
j’avais oublié de préciser que mon précédent message était pour gilles2

#10

Ça peut arriver à tout le monde, et ça n’a pas fait mal, au contraire, tant que ça instruit :slight_smile:

#11

Là on a un beau suspect !

#12

Surprise, puisque ça vient de debian.org, je pensais que c’était béton.

Qu’est-ce que je risque à le laisser ou à le supprimer, maintenant qu’il a été régulièrement sollicité?

#13

je viens de lire

Donc, je crois avoir compris qu’il s’agit des prochaines mises à jour, donc un peu moins «stable»; est-ce bien celà?

#14

Le problème est qu’il aura permis l’installation de versions ultérieures aux versions stables.
Si tu vire juste le dépôt, les versions instables resteront jusqu’à ce qu’une version plus avancée arrive dans les dépôts stables ou backport.

Je sais virer les paquets issus de proposed sous Ubuntu, mais il faudra une bonne âme pour la méthode debian :slight_smile:

C’est en tous cas un bon coupable pour tes aléas et de toutes façons, une analyse de problème se fait sur un système stabilisé !

La résolution de problème est toujours un pas-à-pas !

1 J'aime
#15

Merci,

donc rien à craindre (de plus) à supprimer cette ligne, et si elle a installé des problèmes, ils ont une chance de se réparer avec les mises à jours suivantes?

#16

Sur le principe oui, mais il est mieux de nettoyer (en particulier quand l’auteur du proposed met un numéro baroque, mais là je revient peut-être aux bizarreries Ubuntu…)
On peut dans tous les cas nettoyer après avoir supprimé un dépôt.

#17

Est-ce qu’il suffit de supprimer le dépôt et de faire un «update - upgrade», ou faut-il forcer ce nettoyage avec apt ou aptitude?

#18

Il faut forcer le nettoyage.
Un peu comme au point 2 là : https://dolys.fr/forums/topic/tuto-supprimer-les-depots-proposed/

Ne l’ayant jamais fait sur une Debian, il faudrait un conseil avisé pour l’adapter (ou indiquer une autre soluce spécifique debian)

#19

Merci nam1962

#20

Donc, dans un fichier

/etc/apt/preferences.d/99-downgrade-proposed

mettre les lignes suivantes, supprimer ce dépôt dans sources.list et faire update puis full-upgrade.

Je suppose que le pin priority standard est 1000, si je comprend bien la manoeuvre.

Package: *
Pin: release a=buster
Pin-Priority: 1001

Package: *
Pin: release a=buster/updates
Pin-Priority: 1001

Package: *
Pin: release a=buster-updates
Pin-Priority: 1001

Package: *
Pin: release a=buster-backports
Pin-Priority: 1001

et je suppose que le dépôt protonvpn ne touche à rien, et n’a pas besoin de surcharger le présumé coupable

pour mémoire, c’est:

repo.protonvpn.com/debian unstable main

protonvpn ne propose que ‹ unstable › mais assure que ça marche (et ça semble marcher)

PS: j’ai trouvé ici

PPS:
apt-cache policy

donne la réponse:

les pin sont 500, sauf backport qui est à 100 (donc sans effet pour les packages de Buster, mais sans doute qu’il en propose de nouveaux|futurs

Dans ce cas, on peut sans doute remplacer la valeur 1001 par 501 ?