Inzwischen wird die Firmware zwar wieder zum Drucker geschickt, doch Druckvorgänge sind trotzdem noch nicht wieder möglich.
Die Vorgehensweise mittels Buster-eigenem HPLIP funktioniert allerdings genauso wenig, wie die mit dem von HP direkt beschafften HPLIP; im ersteren, also dem Buster-eigenen, pfuscht GPG dazwischen, da ein Key-Server nicht kontaktiert werden kann, im zweiteren, dem HP-eigenen, funzt auch als Root keines der in der entpackten HP-Software vorhandenen Shell-Scripte.
Die andere Variante mittels der sorgsam gehüteten separaten Firmware funzt zwar genauso, wie bei Jessi. Da sich die Jessi-Festplatte aber energieseitig verabschiedet hat, (irgendwas darin bekommt keinen Strom mehr), kann ich nicht auf die alten Konsolenaufrufe zurückgreifen, die in der Jessi-Root-Bash-Historie gespeichert waren.
Ich weiß, daß es schon bei Jessi Rechteprobleme hatte, und auch da der User nicht einfach drucken konnte, obwohl systemseitig "alles" dafür eingestellt zu sein schien; wie genau dieser dafür nötige Konsolenaufruf lautet, ist mir aber entfallen.
Edit:
Da der Drucker ja ein USB-Drucker ist, wurde mittels
versucht, dem User Rechte zum Drucken zu geben.
Mittels Editor Kate wurde eine "TXT"-Datei erstellt, die via Konsole mittels dem "print"-Kommando an "dev/usb"lp0" gesendet worden ist; Reaktion der Konsole darauf:
Code: Alles auswählen
Error: no "print" mailcap rules found for type "inode/directory"
Error: no such file "x.txt"
Diese obige Reaktion der Konsole kam sowohl via User, als auch via Root; auch Root kann demnach nicht drucken, obwohl die Firmware zuvor erfolgreich zum Drucker gesendet worden ist. (Hinweis: "erfolgreich" = grüne LED, "nicht erfolgreich" = rote LED.
Diese "x.txt" hat es freilich genau an dem Ort, der dem "print"-Konsolenaufruf als Quelle mitgegeben worden ist.
Eigentlich sollte man ein System, das man weiterentwickelt, dabei verbessern, oder?
Zwischen Jessi und Buster vermag ich hier nur einen Rückschritt festzustellen.