Das Symptom
Der Drucker steht da, ist eingeschaltet, hängt am selben Netz oder direkt am
USB-Anschluss — und in der Druckerliste ist nichts. Kein Gerät, keine Auswahl,
kein passender Treiber. Die Einrichtungsoberfläche zeigt eine leere Liste und
schweigt dazu, warum. Und irgendwo öffnet sich in diesem Moment eine Suchmaske
mit der Frage nach einem Linux-Treiber für ein Modell, das seit acht Jahren
gebaut wird.
Die „Layer 8“-Wahrheit
Die Treibersuche ist der Fehler, nicht die Lösung. Die Handbuchseite des
Werkzeugs, mit dem man unter Linux Treiber auflistet, trägt seit einiger Zeit
einen bemerkenswerten Zusatz im Namen: abgekündigt. In den Anmerkungen steht es
ausbuchstabiert — Druckertreiber und Backends von CUPS werden in einer künftigen
Version nicht mehr unterstützt. Wer also nach dem Treiberpaket für sein Modell
sucht, sucht nach einem Konzept, das gerade abgebaut wird.
An seine Stelle ist etwas getreten, das im Grunde die Umkehrung ist: Der Drucker
beschreibt sich selbst. Das Modell heißt in der Handbuchseite schlicht
everywhere, und was dabei passiert, steht dort ebenso schlicht: Es fragt den
Drucker unter der angegebenen IPP-Adresse ab. Kein Hersteller, kein Paket, kein
Zufallsfund im Netz — ein Befehl, eine Adresse, fertig. Nach Darstellung des
ArchWiki können das die meisten Geräte ab etwa 2010.
Damit verschiebt sich die eigentliche Fehlerursache an eine Stelle, an der
niemand sie vermutet. Wenn der Drucker in keiner Liste auftaucht, fehlt fast nie
ein Treiber. Es fehlt die Diensterkennung: CUPS findet Netzwerkdrucker über
DNS-SD, und dafür muss laut ArchWiki der Avahi-Dienst laufen — systemd-resolved
genügt an dieser Stelle ausdrücklich nicht. Ein Dienst, der nicht läuft, macht
ein vollkommen intaktes Gerät unsichtbar, und die Oberfläche sagt dazu nichts,
weil sie nichts zu sagen hat: Sie zeigt eine leere Liste, und leere Listen sind
sprachlos.
Das ist der Grund, warum Drucker hier einen eigenen Schweregrad haben. Bei jedem
anderen Gerät wäre die Frage „ist es da oder nicht“ beantwortbar. Beim Drucker
braucht es dafür drei Befehle, zwei Dienste und die Bereitschaft, ein Protokoll
zu lesen.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.Erst klären, ob der Druckdienst überhaupt läuft
Bevor man Geräte sucht, prüft man den Dienst, der sie verwalten soll. Die CUPS-Handbuchseite nennt dafür einen eigenen Schalter, der anzeigt, ob der CUPS-Server läuft. Auf systemd-Systemen heißt die Einheit cups; sie kann alternativ auch über Socket-Aktivierung erst bei Bedarf starten.
lpstat -r
systemctl status cups
2.Nachsehen, welche Ziele CUPS überhaupt sieht
Die Handbuchseite beschreibt einen Schalter, der alle verfügbaren Ziele im lokalen Netz anzeigt — das ist die ehrlichste Antwort auf die Frage, ob der Drucker gefunden wird. Erscheint er hier, ist er erreichbar und es fehlt nur die Warteschlange. Erscheint er nicht, ist die Erkennung das Problem und nicht der Treiber.
lpstat -e
lpstat -t
3.Die Diensterkennung im Netz sicherstellen
Netzwerkdrucker melden sich über DNS-SD an. Nach der Dokumentation des ArchWiki sollten AirPrint- und IPP-Everywhere-Drucker ohne weitere Konfiguration gefunden werden, sofern avahi-daemon.service läuft; für DNS-SD unterstützt CUPS ausdrücklich kein systemd-resolved. Wer den Avahi-Dienst nicht laufen hat, sucht vergeblich.
systemctl status avahi-daemon.service
4.Die Geräteadresse ermitteln
Für eine Warteschlange braucht CUPS eine Geräte-URI. Für Netzwerkgeräte ergibt sie sich aus der Erkennung, für USB-Geräte listet lpinfo die angeschlossenen Geräte auf. Achtung, dieser Weg ist abgekündigt: Die Handbuchseite führt lpinfo ausdrücklich als deprecated.
lpinfo -v
5.Die Warteschlange treiberlos anlegen
Der heute richtige Weg. Die Handbuchseite von lpadmin beschreibt die Schalter genau: -p benennt die Warteschlange, -E gibt sie frei und nimmt Aufträge an, -v setzt die Geräte-URI, -m wählt das Modell. Das Modell everywhere fragt laut Handbuchseite den unter der angegebenen IPP-Adresse erreichbaren Drucker selbst ab und baut die Beschreibung daraus — kein Treiberpaket, keine Suche nach dem passenden PPD.
sudo lpadmin -p Buero -E -v "ipp://drucker.local/ipp/print" -m everywhere
lpstat -p Buero
6.Die neue Warteschlange zum Standard machen und testen
Damit Programme sie ohne Nachfrage benutzen, wird sie als Standardziel gesetzt. Anschließend eine Testseite schicken und die Warteschlange kontrollieren — die Handbuchseite von lpstat zeigt mit -d das aktuelle Standardziel und mit -p, ob der Drucker zum Drucken freigegeben ist.
sudo lpadmin -d Buero
lpstat -d -p
7.Bleibt es dunkel, das Protokoll befragen
Wenn die Warteschlange steht und trotzdem nichts geschieht, liegt die Antwort im Protokoll. Das ArchWiki empfiehlt dafür, in /etc/cups/cupsd.conf die Zeile LogLevel debug zu setzen und danach /var/log/cups/error_log mitzulesen. Die Zeilen sind vorne gekennzeichnet, D für Debug, E für Error, I für Information — man druckt also einmal und sieht dabei zu.
sudo tail -n 100 -f /var/log/cups/error_log