… treiben mich - wieder mal - in d(i|)e(|n) (Verzweiflung|Wahnsinn).
Nachdem sich die meisten Trümmer, die diese updates hinterlassen hatten und die mich über Wochen intensiv frustrierend beschäftigt hielten, schließlich durch Abwarten (weiterer automatischer Aktualisierungen) “von selbst” aufgeräumt haben …
… verweigert der Drucker hartnäckig seinen Dienst.
Der Drucker schaut in den “Einstellungen” fast perfekt aus - das System scheint ihn zu kennen - aber schon der Ausdruck einer Testseite ist entweder
quasi-ausgegraut/nicht möglich oder
führt zum Ausdruck “unendlich”(?) vieler (>30) Seiten mit jeweils einer Fehlermeldung (“unbekannt”)
Bei 1. steht bei “Adresse” (Netzwerk~ (?)) “(null)”
Bei 2. wird zwangsweise ein “CUPS+Gutenprint”-Treiber (über HPGL(?)) verwendet
Es handelt sich um einen Kyocera ECOSYS P5021cdn, dessen passende ppd bei der Installation in /etc/cups/ppd gelandet ist.
Jeder Versuch, dem die Netzwerkadresse unter der z.B. Kyoceras “Command Center” ihn findet, mitzugeben resultiert in “2.”(s.o.)
2/3. x-mal gemacht (aus den “Einstellungen” heraus)
Absolut nervig, muss bei der Suche nach einem passenden Treiber, die halt minutenlanges Scrollen braucht mehrfach wieder den Passcode eintippen … absolut nervig!
… und führt dazu, dass er dann diesen “CUPS+Gutenprint-Treiber” einbaut, den ich nicht angewählt habe und der sich beim Versuch eine Testseite auszudrucken nicht stoppen lässt und einen Berg Papiermüll produziert.
4/5. x-mal neu gestartet. CUPS ist erreichbar und läuft … und:
Ich finde bei “CUPS für Administratoren” nur eine überwältigende Menge an allgemeiner Dokumentation, keine Stelle mit Informationen zum aktuellen Drucker und dessen Konfiguration.
In “Einstellungen - Drucker” finde ich keinen passenden Treiber, die ppd stammt aus dem AUR.
Der Druck hatte ja früher via KPDL perfekt funktioniert, iirc ohne weiteren Treiber.
Ich selbst nutze keinen Kyocera und kann daher nicht weiter helfen. Meine HP-Drucker funktionieren problemlos unter Linux, aber ich kann verstehen, dass es bei anderen Herstellern manchmal Schwierigkeiten geben kann. Da CUPS bei dir läuft, liegt die Vermutung nahe, dass es sich um ein Treiberproblem handelt.
Du hast erwähnt, dass du die PPD-Datei aus dem AUR bezogen hast. Das ist grundsätzlich ein guter Ansatz, aber manchmal sind die Treiber dort nicht ganz aktuell. Hast du schon überprüft, ob es für deinen Kyocera eine aktuelle PPD auf der Kyocera-Website gibt? Wenn ja, deinstalliere den aktuellen Treiber aus dem AUR und versuche diesen.
Die Treiber in der von Dir verlinkten .zip sind mit dem, den ich habe identisch - d.h. ich hatte die internationale Version, während in der .zip auch einer dabei ist, die deutsch spricht.
Ich nehme an, dass es nicht am Treiber liegt, sondern beobachte, dass der Zugriff über das Netz nicht funktioniert. (Der Zugriff (per web-Interface) funktioniert z.B. für Kyoceras “Command Center” aber eben nicht für Druckaufträge.) Seltsamerweise ist dieser Zugriff mit den falschen “CUPS+Gutenprint”-Treibern möglich aber damit eben kein Ausdruck.
Und das hatte ja jahrelang mit dem KPDL-Treiber perfekt funktioniert.
Es würde mir schon helfen, wenn ich die Installation per cli (also in der Konsole) machen könnte und nicht zig mal den Passcode bei “Einstellungen” eintippen müsste.
Dafür steht wohl alles was es braucht in der Dokumentation, die das CUPS Interface anbietet. Aber die ist für mich wie gesagt überwältigend, (noch?) nicht bewältigt.
Z.B. erzeugt lpinfo -m eine Antwort mit mehr als 14000 Zeilen, von denen ja höchstens eine brauchbar sein könnte, in der Tat aber keine, die zum Drucker passt.
lpinfo liefert offensichtlich keine Information über das aktuelle System, sondern lediglich über die Vorkehrungen des OS um einen (theoretisch alle möglichen, praktisch einen von 14000 - in meinem Fall 0 von 14000) Drucker zu installieren.
Die einzige Information, die ich daraus ziehen kann ist, dass für meinen Drucker ein Eintrag, z.B. in der foomatic-db (was auch immer das ist) fehlt.
Hallo nitja,
ja, lpinfo -m listet dir sämtliche Treiber. Möchtest Du nur den Treiber für deinen Kyocera sehen, hilft dir lpinfo --make-and-model -m "DRUCKER"
weiter, wobei DRUCKER die Bezeichnung für deinen Drucker ist, also irgendwas mit Kyocera ECOSYS_P5021cdn. Dies kannst Du mit lpinfo -v
herausfinden. Sofern der Drucker schon erkannt wurde taucht u.a. eine Zeile mit Kyocera auf. Für meinen Brother sieht es so aus:
…
file cups-brf:/
network https
network ipp
network ipps
network lpd
direct usb://Samsung/ML-1610?serial=3921BAFY302523M.
network socket
direct hp
…
bei dir hoffentlich mit Kyocera, z.B.
…Kyocera/ECOSYS_P5021cdn o.ä.
das kannst Du übernehmen lpinfo --make-and-model -m "ECOSYS_P5021cdn"
aber eigentlich ist das alles Pipifax, weil Du erstens die ppd-Datei schon kennst und auch schon an ihren Platz /usr/share/cups/model kopiert hast. Und zweitens sollten so fast alle Drucker nach 2010 eigentlich mit IPP Everywhere treiberlos funktionieren. https://wiki.archlinux.org/title/CUPS#Printer_drivers
Da es offenbar Probleme mit der Drucker-Adresse gibt, kann es auch sein, dass Avahi nicht läuft, bzw. bei systemd der Dienst systemd-resolved nicht gestartet ist. Mehr kann ich nicht dazu sagen, nur, sieh dir mal die CUPS-Seite von Arch an. https://wiki.archlinux.org/title/CUPS
Die Hilfe von CUPS ist nett, aber doch zu weitschweifig.
Ein Blick in /var/log/cups/error_log könnte auch hilfreich sein: sudo tail -n50 /var/log/cups/error_log | grep -i filter
vielleicht hängt es am fehlenden/falschen Druckerfilter.
Dank Dir für die vielversprechenden Anregungen. Leider hat sich mein Kampf durch den Dschungel etwas hingezogen (und dauert an), was meine Antwort “etwas” verzögert hat.
funktioniert nicht, aber …
lpinfo --make-and-model Kyocera -m
liefert jetzt! (nachdem ich 2 Einträge von /etc/cups/ppd nach /etc/cups/model kopiert habe?) unter 932 Einträgen für Kyocera tatsächlich 2, die passen sollten:
Die letzte Zeile zeigt korrekt die ip, unter der z.B. Kyoceras “Command Center” den Drucker erreicht. ¹⁾
Mein Kampf durch den Dschungel der ArchWiki-Seiten brachte noch keinen wirklichen Durchbruch, aber der Hinweis auf /var/log/cups (der o.g. Befehl produziert bei mir keine Ausgabe) förderte u.a. ein error_log.1 von vor ein paar Tagen ans Licht: ²⁾
E [23/Jul/2024:13:19:17 +0200] Kyocera_ECOSYS_P5021cdn: Unable to connect to KM3CE71D.local:443: Name or service not known
E [23/Jul/2024:13:19:17 +0200] [Client 56] Returning IPP server-error-device-error for CUPS-Create-Local-Printer (ipp://localhost/) from localhost.
E [23/Jul/2024:13:38:24 +0200] [CGI] ippfind (PID 280229) stopped with status 2!
E [23/Jul/2024:13:43:42 +0200] [CGI] ippfind (PID 284758) stopped with status 2!
E [23/Jul/2024:13:43:42 +0200] [cups-deviced] PID 284752 (driverless) stopped with status 2!
E [23/Jul/2024:14:07:25 +0200] Kyocera_ECOSYS_P5021cdn: Unable to connect to KM3CE71D.local:443: Name or service not known
E [23/Jul/2024:14:07:25 +0200] [Client 206] Returning IPP server-error-device-error for CUPS-Create-Local-Printer (ipp://localhost/) from localhost.
E [23/Jul/2024:14:07:26 +0200] Kyocera_ECOSYS_P5021cdn: Unable to connect to KM3CE71D.local:443: Name or service not known
E [23/Jul/2024:14:07:26 +0200] [Client 207] Returning IPP server-error-device-error for CUPS-Create-Local-Printer (ipp://localhost/) from localhost.
Schaut mir so aus, als ob cups nicht nach der ip sucht, sondern nach dem Namen des Druckers, (der|dessen Zuordnung) irgendwann während der updates verloren ging.
¹) Mittlerweile ist durch missglückte Versuche seit heute Mittag der Zugriff auf das web-IF des Druckers ganz verloren gegangen.
²) Was mich dabei in den Wahnsinn treibt: für jeden Klick in der Datei-Verwaltung (Nemo) muss ich jetzt den Passcode eintippen, wenn ich einen Ordner “als Administrator” geöffnet habe und alle paar Sekunden auch zwischendurch. Das war vor den updates anders (so wie auch andere Funktionalitäten dabei verloren gingen).
Ja und das suchen über den Namen ist auch der Normalfall. Ist den Avahi installiert und läuft Avahi bei dir? Ohne können keine mDNS Anfragen gestellt werden.
systemctl status avahi-daemon.service
Falls der nicht “enabled” ist,
systemctl enable --now avahi-daemon.service
Und das ist auch gut so. Lass die Finger davon. Es gibt überhaupt keinen Grund Nemo als Administrator zu verwenden.
Na gut dass ich jetzt über den Normalfall Kenntnis habe. Spielte halt bis vor den updates keine Rolle, da beides - wo auch immer - korrekt eingetragen war.
Avahi läuft und hat nichts zu beanstanden.
Aha: kein Grund in das Filesystem zu schauen und dort ggf. in Dateien, wie z.B. die relevanten ppd anzeigen zu lassen. … oder cups’ error logs? Wofür gibt’s die dann überhaupt? Und wie hätte ich an die enthaltene Info kommen sollen? Bitte erkläre mir das!
Das Frage ich mich auch. Total unnötig und in den meisten Fällen sehr gefährlich. Damit ist die Sicherheit vom Linux System hin und du kannst auch gleich Windows verwenden.
Erstmal Nemo ohne Admin Recht verwenden. In viele Ordner kannst du auch so reinschauen. Nicht immer alle Dateien öffnen, aber zumindest den Inhalt des Ordners auflisten. Und z.B. cups error log Dateien können auch ohne Admin Rechte gelesen werden.
Aber Grundsätzlich, es ist dein System und mache wie du es für richtig hältst.
Um Nemo zu starten, benötigst du kein sudo! Merke: Nutze NIE sudo für grafische Anwendungen wie z.B. Nemo, das ist keine gute Idee, weil es ein hohes Sicherheitsrisiko darstellt und Rechte-Inkonsistenzen verursachen kann. Solltest du sudo für solche GUI-Anwendungen genutzt haben, könntest du dein System beschädigt haben.
Deine Aussage
für jeden Klick in der Datei-Verwaltung (Nemo) muss ich jetzt den Passcode eintippen, wenn ich einen Ordner ‘als Administrator’ geöffnet habe und alle paar Sekunden auch zwischendurch…
lässt sich anders nicht interpretieren.
Du solltest zunächst überprüfen, ob deine Rechte unter deinem /home-Verzeichnis noch alle korrekt sind und ob es möglicherweise Dateien gibt, die nun root gehören.
Ich habe Nemo ja nicht als admin gestartet. Aber wenn ich z.B. die ppd-Datei anschauen will (oder irgendetwas außerhalb des eigenen home-Verzeichnisses) um z.B. die von Dir in post 4 dieses threads verlinkte mit der vorhandenen zu vergleichen, muss ich wohl drauf klicken. Vor den updates wurde das einfach im read-only-modus geöffnet - jetzt verlangt er bei jedem Klick den Passcode.
Was ist die Alternative um z.B. solche Dateien zu vergleichen?
Übrigens habe ich gerade festgestellt, dass ich auf den Drucker doch noch zugreifen kann (in Kyoceras “Command Center”). Aber nur, indem ich durch FRITZ!Box’ Heimnetz»Mesh gehe. Es öffnet sich dann das Web-IF und in der Adressleiste des Browsers steht die bekannte ip. Wenn ich aber versuche die direkt im Browser zu öffnen, was gestern noch funktionierte, kriege ich einen 404.
Übrigens habe ich gerade festgestellt, dass ich auf den Drucker doch noch zugreifen kann (in Kyoceras “Command Center”). Aber nur, indem ich durch FRITZ!Box’ Heimnetz»Mesh gehe. Es öffnet sich dann das Web-IF und in der Adressleiste des Browsers steht die bekannte ip. Wenn ich aber versuche die direkt im Browser zu öffnen, was gestern noch funktionierte, kriege ich einen 404.
Was meinst du damit? Kannst du das Webinterface deines Druckers nicht erreichen? In dem Fall, überprüfe, ob die IP-Adresse deines Druckers korrekt ist. Am besten legst du diese fest.
Die ip-Adresse ist und war festgelegt (nicht dynamisch) und bekannt - mittlerweile (nachdem ich einmal durch die FRITZ!Box-Seite dahin gekommen bin) geht der Zugriff wieder, sowohl über den Namen (Hostname des Druckers) als auch die ip.
Gibt es eine mir unbekannte Verbindung/Abhängigkeit der Rechte für /etc oder /var zu denen auf /home/ᐸuserᐳ?
Für letztere brauche ich keine Passcodes nachdem ich eingeloggt bin, bzw. nur dann, wenn ich sie ausdrücklich und ausnahmsweise selbst spezifiziert habe.
Wenn meine Abfrage oben leer ist, benötigst du unter /home/USER kein sudo-Passwort. Andernfalls müsstest du das mit einem sudo-Befehl beheben. Für alles unter root (/) benötigst du je nach chmod-Einstellung sudo, zum Lesen in der Regel jedoch nicht. Wenn du also mit deinem Dateibrowser Nemo (den ich nicht kenne) beim Öffnen der Datei nach deinem sudo-Passwort gefragt wirst, stimmt in der Tat etwas nicht. Obwohl ich betonen muss, dass ich den Desktop Gnome und Nemo nicht nutze und dies eine Eigenschaft sein könnte. Unter KDE und dem Dateibrowser Dolphin kann ich diese Dateien lesen (also schreibgeschützt öffnen).
Egal wie, ich nutze für sowas nur “cat” zum Anschauen oder “sudo nano”, wenn ich solch eine Datei editieren möchte, was selten vorkommt.
