Cette espace vous permet de voir toutes les Messages réalisées par ce membre. Vous ne pouvez voir que les Messages réalisées dans les espaces auxquels vous avez accès.
Merci pour le tuyau ! En revanche cette restriction ne correspond pas à mon cas : elle s'applique aux imprimantes USB uniquement, et j'utilise la mienne via le réseau. L'explication pourrait venir de la réponse à une commande 'hp-check', qui m'informe que Leap 15.3 n'est pas supporté (Leap 15.2 si). Avec au passage une liste de dépendances obligatoires non satisfaites, notamment vers du Qt4 qui n'est plus dans les dépôts. Avis aux amateurs de Leap et d'imprimante/scanner HP : mieux vaut peut-être attendre un peu avant de monter de version 15.2 vers 15.3 ?
Bon, 3ème soirée de galère, mais j'y suis arrivé. Au prix d'une réinstall complète de Leap A force de tenter des trucs, j'ai fini par faire un 'snapper rollback' pour revenir à un état propre. Sauf que... après le rollback, snapper ne voyait plus aucune snapshot, et des snapshots j'en avais un paquet, y compris avant l'upgrade en 15.3 Disque presque plein, plus moyen d'effacer les snapshots... crise, puis réinstall complète.
Après une fresh install 15.3, le scanner ne scanne toujours pas. Manque encore le plugin. La commande 'hp-plugin' échoue lamentablement, prétendument parce que le plugin téléchargé est corrompu. C'est fou à quel point ce machin est créatif pour échouer toujours pour des raisons différentes Là, je ressors mon astuce déjà utilisée 2 fois : juste après la fin du téléchargement du plugin dans /home/[user]/.hplip, et juste avant son effacement, j'en fais une copie. C'est un fichier ".run", donc un petit chmod+x dessus, on l'exécute... et il s'installe
Aujourd'hui, je reviens sur ma machine en Leap 15.2, mise à jour 15.3, et re-re-problème d'install de plugin
Et à chaque fois des erreurs différentes. Ça commence à être fatigant !
Après passage de 15.2 à 15.3 (zypper dup), je ne sais pas pourquoi mais hplip n'était plus installé. Je le réinstalle, l'imprimante revient. Mais pas le scanner, qui me réclame toujours ce fichu plugin. Quand j'essaie de l'installer avec 'hp-plugin', il plante. Cette fois-ci, la dernière erreur affichée est : PermissionError: [Errno 13] Permission non accordée: '/bin/sh'
Pourtant, je ne vois pas de pb de permission. En suivant les liens symboliques:
Bon alors, problème résolu, mais, comment dire... pas vraiment de manière académique !
1/ récupérer le plugin Quand on lance Xsane, l'installeur HP propose gentiment de mettre à jour automatiquement le plugin. Puis il le télécharge dans /home/[user]/.hplip, tente de l'installer, échoue, et finalement le supprime. Entre la fin du téléchargement et la suppression se passent quelques courtes secondes pendant lesquelles on peut faire une copie du fichier. Pas trivial, il m'a fallu plusieurs tentatives
2/ installation On relance Xsane, l'installeur HP demande à nouveau l'installation du plugin Sélectionner alors l'option "installer un plugin local (avancé)" plutôt que "télécharger automatiquement (recommandé)" Là... attention - si on sélectionne le plugin dans son emplacement initial (/home/[user]/.hplip/hplip-3.20.11-plugin.run), il supprime le fichier et se plaint "fichier non trouvé" (gonflé, quand même ) - si on renomme le fichier, le bouton "next" est désactivé, pas possible d'aller plus loin Il faut donc copier le fichier dans un autre répertoire, mais sans le renommer ( !?!) Là on peut cliquer sur "Next" et on voit l'install du plugin commencer. Ca se termine par 2 messages contradictoires indiquant et l'échec et le succès de l'opération. Allez comprendre. Mais le plugin est installé et le scanner scanne
Décidément, plus ça va et plus hplip regorge de surprises, pas toujours agréables !
Il n'y a pas si longtemps que ça (1 ou 2 semaines) mon scanner réseau HP fonctionnait encore sans problème avec Xsane. Comme cela arrive parfois après des mises à jour, lorsque je lance Xsane il me demande d'installer un plugin... mais cette fois-ci l'installation foire avec un message peu éloquent, du genre "ça marche pas".
Je sais que lorsqu'il télécharge ce plugin il le range dans /home/[user]/.hplip. En l'occurrence : hplip-3.20.11-plugin.run En faisant une copie du plugin avant que celui-ci ne soit supprimé, j'arrive à le lancer à la main et à avoir un message d'erreur plus clair, bien que très suprenant : "Error importing HPLIP modules. Is HPLIP installed?"
Ben oui il est installé, hplip... en version 3.20.11-2.5 d'après Yast. Ca semble cohérent.
J'ai essayé de télécharger la dernière version depuis le site de HP, mais il m'informe que tumbleweed n'est pas supporté.
Le lâche contournement, bien que pas très satisfaisant intellectuellement, semble très bien fonctionner. J'enchaîne les reboots les uns après les autres, dans l'objectif de reconfigurer mes logs en mémoire volatile. Parce que je sais que les avis sont partagés sur la question, mais je suis de ceux qui pensent que les logs verbeux qui fusillent les SSD sont malheureusement une réalité.
Plus de problème de blocage à l'extinction Mais si déplacer les logs en mémoire non volatile était un jeu d'enfant, dans l'autre sens ça l'est beaucoup moins ! Il ne suffit pas de supprimer la ligne "Storage=persistent" dans /etc/systemd/journald.conf Pas non plus de la remplacer par "Storage=volatile", conformément au "man journald.conf" Il faut, en plus de ça, supprimer le répertoire /var/log/journal ouf !
Peut-être quelque chose du côté de PAM ? Il y a eu des mises à jour ces jours ci me semble-t-il As-tu essayé de redéfinir le mdp root comme suggéré par oh!rocks ?
D'autres ont manifestement eu le même problème. On me demande sur le forum FreeCAD quel est le moyen de remonter le problème côté OpenSUSE... De fait, mieux vaudrait ne pas laisser cette version dans les dépôts, si elle s'avère instable dans l'environnement Tumbleweed. Sauriez-vous comment faire ?
récente, récente... pas vraiment : août 2018 Dois-je comprendre qu'une petite réinstall complète de temps en temps ne ferait pas de mal ? Je dois reconnaître être un peu frileux. La réinstall n'est pas un problème en soi, mais tout reconfigurer ça pourrait être un peu long
ça ne se présente pas très bien Si j'en crois Yast mon chip wifi est un "Centrino Advanced-N 6205 AGN", mentionné explicitement ici dans un ticket "CLOSED WILL_NOT_FIX" qui ressemble beaucoup à mon problème. Trop vieux matériel, plus de corrections. Mon pc est un portable de gamme professionnelle d'occasion, un excellent rapport qualité/prix. Mais évidemment, pas tout jeune.
En l'état je ne vois pas cinquante solutions : - je pense à couper manuellement le wifi avant d'éteindre la machine. Pas fiable, vous rendez-vous compte... il faut penser ! - je cherche sur le net une carte wifi compatible, et je démonte la machine (un avantage des machines pro : démontage très facile) - je me demande si je n'ai pas au fond d'un tiroir un vieux dongle wifi USB, mais ça me ferait perdre un port USB sur la machine. Et il faudrait encore que ça marche, il doit être plus vieux que mon pc ! - j'espère que ça va disparaître tout seul au gré des mises à jour
Pas enthousiasmant, tout ça
Après, il y a le lâche contournement... un script pour couper le wifi quand on ferme la session, dans /home/[user]/.config/plasma-workspace/shutdown/
On va voir ce que ça donne. Semble régler le problème sur quelques redémarrages successifs, mais difficile de savoir si c'est fiable compte tenu du côté non systématique du problème. On verra dans le temps. Par ailleurs ça ne règle en rien le problème si la machine s'éteint suite à une command 'poweroff' (ou shutdown, reboot...) par root. Uniquement sur une extinction depuis l'interface graphique de KDE...
Ben... moi aussi ! (voir le titre du post). Je mentionne la doc de Leap parce que c'est là que j'ai trouvé la méthode pour rendre les logs persistants, du coup je n'ai pas cherché plus loin
Bon, alors journalctl était clairement une bonne piste, merci ! C'est marrant, d'après la doc de Leap, les logs sont bien volatils par défaut : "The journal stores log data in /run/log/journal/ by default. Because the /run/ directory is volatile by nature, log data is lost at reboot"
M'enfin bon, la méthode pour obtenir des logs permanents est décrite, il suffit d'ajouter la ligne suivante dans la section "[journal]" de /etc/systemd/journald.conf:
Je vais vous épargner (pour l'instant au moins !) la copie complète des logs, mais j'ai déjà un peu de matière pour chercher, le problème étant lié au wifi:
mai 06 10:50:21 linux-4y8j kernel: iwlwifi 0000:02:00.0: Error sending REPLY_SCAN_ABORT_CMD: time out after 2000ms. mai 06 10:50:21 linux-4y8j kernel: iwlwifi 0000:02:00.0: Current CMD queue read_ptr 28 write_ptr 29
J'utilise opensuse sur plusieurs machines à la maison, celle-ci est la seule sur laquelle le wifi a fonctionné "out of the box", sans install de driver complémentaire. Je vais regarder de ce côté là...
Oui, mon système est à jour (je fais les mises à jour Tumbleweed quasi quotidiennement).
Merci pour les conseils d'utilisation de journalctl, je vais lire tout ça... Je confirme que mes logs sont volatils (je ne sais pas bien où c'est configuré), je n'ai rien dans journalctl avant le dernier boot, donc rien sur la dernière extinction
Sûrement une question bête ... tu n'as qu'un utilisateur qui a les droits root ? Tu peux vérifier que chacune des 2 commandes ci-dessous (en root...) ne te renvoie qu'une ligne
faudrait peut être voir du côté des logs avec journalctl.
Jamais bien compris comment ça marchait, journalctl... A priori mes logs sont volatiles : je n'ai aucune trace dans le journal de ce qui s'est passé avant le boot. Alors quand le problème se produit à l'extinction, ben ça aide pas beaucoup !
Citer
ça a a disparu aussi étrangement que c'était apparu.
Je vais peut-être essayer ça alors On peut toujours espérer, au gré des mises à jour...
!?!)
