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
Grand merci, Gilles2, c’est bien ça!
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.
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/*
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.
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
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
Ça peut arriver à tout le monde, et ça n’a pas fait mal, au contraire, tant que ça instruit 
Là on a un beau suspect !
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é?
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à?
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
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
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?
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.
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?
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)
Merci nam1962
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 ?
Il faut surtout que ton proposed se retrouve avec un pin = -1
Maintenant, il m’étonnerait que le forum ne recèle pas une bonne âme qui a déjà fait ça sous Debian 