No suitable destination host found by cups browsed ошибка

I have a similar answer to @burnedfaceless that I came upon somewhat by accident. Since I was not comfortable removing a service that came with the system (Pop!_OS 20.04), I ran

systemctl stop cups-browsed

I then manually searched for and added the printer via Settings > Printers > Add…

At that point I was able to print normally, and only the one, manually-added, instance of my printer was visible. To test this further, I rebooted, expecting cups-browsed to restart itself (it did) and a second instance of the same printer to appear via the cups-browsed service (it did not, happily). So far so good. I am not sure why cups-browsed did not automatically add its own instance of the printer, but glad it did not.

One difference I have noted since doing this is that if I run:

lpstat -t
scheduler is running
system default destination: <short printer name>
device for <short printer name>: dnssd://<full url-encoded printer name>._ipp._tcp.local/?uuid=e...

If I recall correctly, the device URI was implicitclass://<printer name>, or something like that, when cups-browsed added it. Now it is dnssd://.... Perhaps this makes sense to someone who understands CUPS and/or systemd much better than I do.

В разных компаниях чаще всего компьютерные сети построены с использованием серверных версий Windows. Работать в таких сетях на компьютере с Ubuntu вполне можно. В этой статье полезная информация, описание настроек.

В статью внесены правки, всё сказанное актуально для Ubuntu версии 20.04.

Пользователи

При таком раскладе будет как минимум два вида пользователей:

1. Пользователи непосредственно у вас на компьютере. Вы создаёте первого пользователя, когда устанавливаете Ubuntu. Под ним вы работаете у себя на компьютере.
2. Пользователи сети Windows. Для вас такого пользователя заводит системный администратор компании. Используя данные этого пользователя вы получаете доступ к сети компании. Уровень доступа этого пользователя в сети определяется администратором. Кроме каких-то общих сетевых ресурсов у вас скорее всего будет личный каталог и т.д.

Пользователь сети Windows заводится для определенного домена. Например, WORKGROUP или что-то более осмысленное. Название домена тоже необходимо будет указывать при доступе к сетевым ресурсам. В больших компаниях может использоваться несколько доменов, тогда и пользователей второго вида может быть несколько.

Работа в сети

Полное правильное название сетей Windows – это «Microsoft Windows Network», в русском языке – «Сети Microsoft Windows». Работа с такими сетями осуществляется с использованием протокола SMB (Server Message Block). Ранее протокол имел название CIFS (Common Internet File System). С его помощью можно получить удалённый доступ не только к файлам, но и принтерам.

Файловый менеджер Ubuntu под названием «Файлы» довольно функционален. Он умеет работать по протоколу SMB. Для открытия сетевого ресурса нажмите «Другие места» и внизу вы увидите поле, куда нужно ввести адрес для подключения, можно ввести например:

smb://company-diskstation/dir

В случае необходимости у вас будут запрошены данные для доступа — имя пользователя, пароль, домен.

Обычно в компаниях организованы какие-то общие хранилища, куда имеют доступ пользователи и где находится личный каталог. Такие хранилища удобно монтировать сразу при запуске Ubuntu. Тогда во всяких файловых менеджерах, вроде «Файлы», Double Commander и т.д. вы будете сразу видеть эти ресурсы. С ними удобно будет работать. Также, как и с обычным каталогами на локальном диске. Не надо будет вводить пароль и прочее.

Монтировать сетевые ресурсы лучше через файл /etc/fstab. Здесь всё это можно настроить один раз и забыть. Работает очень стабильно. Я у себя на рабочем компьютере последний раз открывал этот файл более года назад.

Пример подключения сетевого каталога:

//company-diskstation/dir /mnt/company/diskstation cifs credentials=/home/kornev/.smbuser,uid=1000 0 0

Здесь:

• //company-diskstation/dir — сетевой ресурс SMB вместе с подкаталогом.
• /mnt/company/diskstation — каталог на локальном диске, куда он будет смонтирован.
• /home/kornev/.smbuser — файл, в котором записаны данные для доступа (см. ниже).
• uid=1000 — id пользователя у вас на компьютере (см. ниже).

Файл /home/kornev/.smbuser не является обязательным. Это для удобства. Чтобы не писать каждый раз одни и те же данные. Ведь подобных строчек для подключения сетевых ресурсов может быть много. А еще этот же файл можно будет использовать из разных скриптов, которые тоже подключаются к SMB-ресурсам. Понадобится потом изменить данные доступа, это придется сделать только один раз, в этом файле.

Файл может иметь любое имя и расположение, внутри:

username=имя_пользователя_windows
password=пароль_пользователя_windows
domain=WORKGROUP

Что касается id пользователя. Это необходимо, чтобы сетевой ресурс монтировался в нормальном режиме, чтобы мы могли с ним полноценно работать. Без этого у меня получался режим «только чтение». Есть ещё gid=1000 – параметр id группы, который тоже можно добавить. Но у меня и без него все работало.

Узнать uid и gid для пользователя kornev можно командами:

id -u kornev
id -g kornev

Пример скрипта script.sh, с подключением и отключением ресурса SMB:

#!/bin/bash

# Переменные
dir_local=/mnt/work_dir
dir_smb=//remote/dir/in/windows/network

# Подключение
/sbin/mount.cifs $dir_smb $dir_local -o credentials=/home/kornev/.smbuser,uid=1000 0 0

# Запуск некой обработки

# Отключение
umount $dir_local

Принтер и МФУ

С сетевыми принтерами всё очень просто. Доступные в сети принтеры у вас сами появятся в настройках. Необходимо только выбрать, какой из них вы хотите использовать по умолчанию.

У меня компьютер работает без выключения днями, иногда неделями. При этом часто бывает, что я отправляю на печать, но печать не идёт. В активных заданиях видно, что печать документов приостановлена. Иногда видно сообщение «No suitable destination host found by cups-browsed». Не знаю, связанно ли это как-то с проблемой.

Для быстрого решения можно перезапустить компьютер и тогда печать сразу будет работать. Если не торопиться, то можно подождать, через некоторое время документы все же распечатаются. Ещё одно быстрое решение:

sudo systemctl stop cups-browsed
sudo systemctl start cups-browsed

Либо:

sudo systemctl restart cups-browsed

Если принтер — это МФУ и требуется на нём сканировать, то необходимо выполнить дополнительные настройки. Суть в том, что после сканирования готовые документы должны куда-то складываться. Обычно это настраивается через веб-интерфейс МФУ. Куда складывать?

• Это может быть каталог вашего пользователя в сети. Тогда вам ничего делать не нужно, настройка такой работы – это забота администратора. Вы только можете смонтировать свой каталог, как было описано выше, чтобы вам проще было работать с отсканированными документами.
• Второй вариант – это настроить у себя на компьютере каталог с доступом по SMB или FTP. Мне больше нравится вариант с SMB. Не использую FTP нигде очень давно.

Устанавливаем Samba, если ещё не установлена:

sudo apt install samba

Лучше создать нового отдельного пользователя специально для этих нужд, данные которого потом сообщить администратору. Он внесёт их в МФУ.

Назовём этого пользователя share-user:

sudo useradd -d /dev/null share-user

Задаём пароль этому пользователю, иначе он будет недоступен:

sudo passwd share-user

Пользователя и пароль также внесём в базу данных Samba:

sudo smbpasswd -a share-user

Каталог у себя на компьютере, например /mnt/company/kornev_share, создавайте от имени и группы этого пользователя.

Пример конфига /etc/samba/smb.conf:

[global]
security = user
passdb backend = tdbsam
workgroup = WORKGROUP
server min protocol = NT1
server string = MyPC Samba

[kornev_share]
path = /mnt/company/kornev_share
valid users = @share-user
force group = share-user
create mask = 0771
directory mask = 0771
writable = yes

Здесь стоит обратить внимание на параметр server min protocol = NT1. Дело в том, что есть разные версии протокола SMB. Часто бывает, что даже не сильно старые МФУ не поддерживают новые версии протокола. Данным параметром мы разрешаем подключение с использованием SMB v1. Попробуйте. Если без этого параметра у вас всё будет работать, то лучше не ставить его.

Перезапуск Samba для применения изменений:

sudo service smbd restart

Если администратор со свой стороны все настроил, то можно пользоваться:

This article covers all non-specific (ie, not related to any one printer) troubleshooting of CUPS and printing drivers (but not problems related to printer sharing), including methods of determining the exact nature of the problem, and of solving the identified problem.

Debug log

The best way to get printing working is to set LogLevel in /etc/cups/cupsd.conf to:

LogLevel debug

And then viewing the output from /var/log/cups/error_log like this:

# tail -n 100 -f /var/log/cups/error_log

The characters at the left of the output stand for:

• D=Debug
• E=Error
• I=Information
• And so on

These files may also prove useful:

• /var/log/cups/page_log — Echoes a new entry each time a print is successful
• /var/log/cups/access_log — Lists all cupsd http1.1 server activity

Print a document and watch error_log to get a more detailed and correct image of the printing process.

Problems resulting from upgrades

Issues that appeared after CUPS and related program packages underwent a version increment

CUPS stops working

The chances are that a new configuration file is needed for the new version to work properly. Messages such as «404 — page not found» may result from trying to manage CUPS via localhost:631, for example.

To use the new configuration, copy /etc/cups/cupsd.conf.default to /etc/cups/cupsd.conf (backup the old configuration if needed) and restart CUPS to employ the new settings.

All jobs are «stopped»

If all jobs sent to the printer become «stopped», first check the error log at /var/log/cups/error_log. If it does not yield any useful hints to what is the source of the issue, delete the printer and add it again.
Using the CUPS web interface, go to Printers > Delete Printer.

To check the printer’s settings go to Printers, then Modify Printer. Copy down the information displayed, click ‘Modify Printer’ to proceed to the next page(s), and so on.

All jobs are «The printer is not responding»

On networked printers, you should check that the hostname in the printer’s URI resolves to the printer’s IP address via DNS, e.g. if your printer’s connection looks like this:

lpd://BRN_020554/BINARY_P1

then the hostname ‘BRN_020554’ needs to resolve to the printer’s IP from the server running CUPS. If Avahi is being used, ensure that Avahi’s hostname resolution is working.

Alternatively, replace the hostname used in the URI with the printer’s IP address.

The PPD version is not compatible with gutenprint

Run:

# /usr/bin/cups-genppdupdate

And restart CUPS (as pointed out in gutenprint’s post-install message).

Issues Relating to Upgrade 2.3.3 -> 2.4.0

CUPS now officially supports AirPrint and Mopria clients (including Windows 10) by reporting required attributes and DNS-SD TXT record keys. It includes also limited support for huffy iOS clients. This obsoletes the need for Avahi service files for propagation of CUPS shared printers to mobile devices. The following list of new functions has been taken from CUPS release note:

• New ReadyPaperSizes directive that specifies the «loaded» (ready) media for each printer; the actual list is based on the supported media sizes for the printer, and allows the user to pick a size from a short list. Default list is based on locale (A4, etc. everywhere but North America which uses Letter, etc.)
• Proper URF/urf-supported values for image/urf.
• Other attributes/keys as needed.

As a side-effect of the new ready media propagation IOS clients may show wrong media types (e. g. US letter instead of DIN/ISO A4). The best way to get ISO media types is to set DefaultPaperSize in /etc/cups/cupsd.conf to:

DefaultPaperSize A4

for ISO. In addition, the system-default paper size should be configured correctly.

Note: CUPS provides IOS clients only with a set of main media sizes. This set is matched from a default set of media sizes {see ReadyPaperSizes) and sizes from the PPD or the DefaultPaperSize if none of the sizes match.

Issues Relating to Upgrade 2.3.3-3 -> 2.3.3+106+ga72b0140e-1

As a side-effect of switching Arch’s CUPS upstream from Apple’s senescent original to the actively-developed OpenPrinting fork in November 2020, the names of the CUPS systemd services were changed. The changes map as follows:

• org.cups.cups-lpd.socket→cups-lpd.socket
• org.cups.cups-lpd@.service→cups-lpd@.service
• org.cups.cupsd.socket→cups.socket
• org.cups.cupsd.service→cups.service
• org.cups.cupsd.path→cups.path

The CUPS install file for that upgrade recommends:

Cups systemd socket and service files have been
renamed by upstream decision. Please make sure
to disable/reenable the services to your need.
hint: "pacman -Ql cups | grep systemd" and
"ls -lR /etc/systemd/ | grep cups"

So, if one had org.cups.cupsd.service enabled, one would disable it with immediate effect (#systemctl --now disable org.cups.cupsd.service) and enable its successor, also with immediate effect (#systemctl --now enable cups.service).

In addition to disabling the services under their own name and re-enabling them under the new, if you have made any non-standard modifications such as drop-in files (e.g., /etc/systemd/system/org.cups.cupsd.service.d) or adding the services as Wants= to target or other custom services, those will need to be moved over as well.

Networking issues

Unable to add printer or message «print in progress» but nothing happens

In GNOME Printer settings for example, you could find troubles adding your printer, even though you have installed the drivers. You can try installing system-config-printer and executing it via terminal, and adding the printer from there (for instance using LPD/LPR queue ‘PASSTHRU’).

Unable to locate printer

Even if CUPS can detect networked printers, you may still end up with an «Unable to locate printer» error when trying to print something. The solution to this problem is to enable Avahi’s .local hostname resolution. See CUPS#Network for details.

This problem may also arise when you have a firewall. You may need to disable your firewall or set the right rules. Using system-config-printer to detect network printers will do that automatically.

Similarly, being connected to a VPN may also cause CUPS to be unable to locate the printer. Disabling any VPN connections temporarily for printing can help fixing it.

Old CUPS server

As of CUPS version 1.6, the client defaults to IPP 2.0. If the server uses CUPS <= 1.5 / IPP <= 1.1, the client does not downgrade the protocol automatically and thus cannot communicate with the server. A workaround is to append the version=1.1 option documented at [1] to the URI.

Unable to locate PPD file

/var/log/cups/error_log

Cannot connect to remote printer ipp://HP079676.local
copy_model: empty PPD file

Make sure Avahi is set up correctly. In particular, make sure nss-mdns is installed and set up in /etc/nsswitch.conf.

Finding URIs for Windows print servers

Sometimes Windows is a little less than forthcoming about exact device URIs (device locations). If having trouble specifying the correct device location in CUPS, run the following command to list all shares available to a certain windows username:

$ smbtree -U windowsusername

This will list every share available to a certain Windows username on the local area network subnet, as long as Samba is set up and running properly. It should return something like this:

 WORKGROUP
	\REGULATOR-PC   		
		\REGULATOR-PCZ              	
		\REGULATOR-PCPublic         	
		\REGULATOR-PCprint$         	Printer Drivers
		\REGULATOR-PCG              	
		\REGULATOR-PCEPSON Stylus CX8400 Series	EPSON Stylus CX8400 Series

What is needed here is first part of the last line, the resource matching the printer description. So to print to the EPSON Stylus printer, one would enter:

smb://username:password@REGULATOR-PC/EPSON%20Stylus%20CX8400%20Series

as the URI into CUPS.

USB printers

Conflict with SANE

If you are also running SANE, it is possible that it is conflicting with CUPS. To fix this create a Udev rule marking the device as matched by libsane:

/etc/udev/rules.d/99-printer.rules

ATTRS{idVendor}=="vendor id", ATTRS{idProduct}=="product id", MODE="0664", GROUP="lp", ENV{libsane_matched}="yes"

Conflict with usblp

USB printers can be accessed using two methods: The usblp kernel module and libusb. The former is the classic way. It is simple: data is sent to the printer by writing it to a device file as a simple serial data stream. Reading the same device file allows bi-di access, at least for things like reading out ink levels, status, or printer capability information (PJL). It works very well for simple printers, but for multi-function devices (printer/scanner) it is not suitable and manufacturers like HP supply their own backends. Source: here.

Warning: As of cups version 1.6.0, it should no longer be necessary to blacklist the usblp kernel module.
If you find out this is the only way to fix a remaining issue please report this upstream to the CUPS bug tracker and maybe also get in contact with Till Kamppeter (Debian CUPS maintainer). See upstream bug for more info.

If you have problems getting your USB printer to work, you can try blacklisting the usblp kernel module:

/etc/modprobe.d/blacklistusblp.conf

blacklist usblp

Custom kernel users may need to manually load the usbcore kernel module before proceeding.

Once the modules are installed, run:

# journalctl -f

Then plug in the printer and inspect the output to see if it was detected.

If you are using usblp, the output should indicate that the printer has been detected like so:

Feb 19 20:17:11 kernel: printer.c: usblp0: USB Bidirectional
printer dev 2 if 0 alt 0 proto 2 vid 0x04E8 pid 0x300E
Feb 19 20:17:11 kernel: usb.c: usblp driver claimed interface cfef3920
Feb 19 20:17:11 kernel: printer.c: v0.13: USB Printer Device Class driver

If you blacklisted usblp, you will see something like:

usb 3-2: new full speed USB device using uhci_hcd and address 3
usb 3-2: configuration #1 chosen from 1 choice

USB autosuspend

The Linux kernel automatically suspends USB devices when there is driver support and the devices are not in use. This can save power, but some USB printers think that they are disconnected when the kernel suspends the USB port, preventing printing. This can be fixed by deactivating autosuspend for the specific device, see Power management#USB autosuspend.

Bad permissions

Check the permissions of the printer USB device. Get the bus and device number from lsusb:

$ lsusb

Bus <BUSID> Device <DEVID>: ID <VENDOR>:<PRINTERID> Hewlett-Packard DeskJet D1360

Check the ownership by looking in devfs:

# ls -l /dev/bus/usb/BUSID/DEVID

The cups daemon runs as user «cups» and belongs to group «lp», so either this user or group needs read & write access to the USB device. If you think the permissions look wrong, you can change the group and permission temporarily:

# chgrp lp /dev/bus/usb/BUSID/DEVID
# chmod 664 /dev/bus/usb/BUSID/DEVID

Then check if cups can now see the USB device correctly.

To make a persistent permission change that will be triggered automatically each time the USB device is attached, add the following line:

/etc/udev/rules.d/10-local.rules

SUBSYSTEM=="usb", ATTRS{idVendor}=="VENDOR", ATTRS{idProduct}=="PRINTERID", GROUP:="lp", MODE:="0664"

After editing, reload the udev rules with this command:

# udevadm control --reload-rules

Each system may vary, so consult udev#List the attributes of a device wiki page.

HP issues

CUPS: «/usr/lib/cups/backend/hp failed»

Try adding the printer as a Network Printer using the http:// protocol.

Note: There might need to set permissions issues right.

CUPS: Job is shown as complete but the printer does nothing

This happens on HP printers when you select the (old) hpijs driver (e.g. the Deskjet D1600 series). Use the hpcups driver instead.

Some HP printers require their firmware to be downloaded from the computer every time the printer is switched on. If there is an issue with udev (or equivalent) and the firmware download rule is never fired, you may experience this issue. As a workaround, you can manually download the firmware to the printer. Ensure the printer is plugged in and switched on, then run:

# hp-firmware -n

CUPS: ‘»foomatic-rip» not available/stopped with status 3’

If receiving any of the following error messages in /var/log/cups/error_log while using a HP printer, with jobs appearing to be processed while they all end up not being completed with their status set to ‘stopped’:

Filter "foomatic-rip" for printer printer_name not available: No such file or director

or:

PID pid (/usr/lib/cups/filter/foomatic-rip) stopped with status 3!

make sure hplip has been installed.

CUPS: «Filter failed»

A «filter failed» error can be caused by any number of issues. The CUPS error log (by default /var/log/cups/error_log) should record which filter failed and why.

Missing ghostscript

Install ghostscript (/usr/lib/cups/filter/gstoraster needs it to run).

Missing foomatic-db

Install foomatic-db and foomatic-db-ppds. This fixes it in some cases.

Avahi not enabled

Start, and enable the avahi-daemon service.

Out-of-date plugin

This error can also indicate that the plugin is out of date (version is mismatched) and may occur after a system upgrade, possibly showing up as a Plugin error message in the logs.
If you have installed hplip-plugin^AUR you will need to update the package, otherwise re-run hp-setup -i to install the latest version of the plugin.

Outdated printer configuration

As of hplip-plugin^AUR v3.17.11 hpijs is not longer available. If you have printers using hpijs they will fail to print. You must modify them and select the new hpcups driver instead.

You can check if this is your case looking at cups error_log:

$ grep hpijs /var/log/cups/error_log

...
D [09/Jan/2018:14:32:58 +0000] [Job 97] sh: hpijs: command not found
...

Client and host both run CUPS with hpcups

Note: The following issue has been described on FreeBSD forum. Read more here.

A bug seems to affect CUPS when a host shares a physically connected HP printer using hpcups drivers from hplip, and a client adds the shared printer in is own CUPS server through IPP, using hpcups driver too. On every attempt to print a page from the client, the jobs page from the client returns indefinitly «Sending data to printer» while the same page from the host returns «Filter failed». It appears that the job runs through the CUPS filter twice: a first time on client-side, and a second time on host-side, which makes it fails on host-side. The same bug should not be observed when printing from a Windows client, or when printing directly on the host. There are some workarounds here (use only one method):

• Use Generic IPP Everywhere Printer driver on the client. When selecting the driver in the CUPS Web Interface, you should find it in the Generic manufacturer.
• Modify the PPD used on the client side so the job does not goes through the filter client-side. Find the right PPD in /usr/share/ppd/HP and copy it in your home directory. Edit the copy : replace the line *cupsFilter: "application/vnd.cups-raster 0 hpcups" with *cupsFilter: "*/* 0 -". Now, add your printer on the client CUPS, selecting your custom PPD located in your home directory.
• Create a raw queue on the host: when you add the printer in the CUPS interface of the host, do not select the specific PPD of your printer, but choose Raw queue from Raw manufacturer. You should be able to add this shared printer on the client, using this time the specific PPD of the printer. With this method, the host is not able to print directly a document because it does not run the filter. However, if the host is a small headless embedded device such as a Raspberry Pi, you might notice an important decrease of the response time with this method compared to the two previous ones, especially with large documents, because it saves a lot a CPU usage.

CUPS: prints only an empty and an error-message page on HP LaserJet

There is a bug that causes CUPS to fail when printing images on HP LaserJet (in my case 3380). The bug has been reported and fixed by Ubuntu.
The first page is empty, the second page contains the following error message:

 ERROR:
 invalidaccess
 OFFENDING COMMAND:
 filter
 STACK:
 /SubFileDecode
 endstream
 ...

In order to fix the issue, run the following command as root:

# lpadmin -p printer -o pdftops-renderer-default=pdftops

CUPS: «File «/usr/lib/cups/filter/rastertospl» not available

After the printer is connected by other means to the network, setting up the HP 107w Laser printer is possible through the CUPS web interface; but this error prevents printing.

It seems that support for this printer is not provided by hplip. However, drivers can be installed using HP’s install scripts and PPD file found at the HP downloads page.

Extract the .zip and read this gist for further details and instructions.

In case this problem appeared after a PPD package (like foomatic-*) update, check if there are new PPDs for the printer, and try to use the new ones.

As of January 2022, the new driver for Samsung M283x has PXL in the name and the PPD does not reference rastertospl, and the printer works again. Fetching the rastertospl via the above method did not work because the arguments are passed in the wrong order.

HPLIP 3.13: Plugin is installed, but HP Device Manager complains it is not

The issue might have to do with the file permission change that had been made to /var/lib/hp/hplip.state. To correct the issue, a simple chmod 644 /var/lib/hp/hplip.state and chmod 755 /var/lib/hp should be sufficient. For further information, please read this link.

hp-toolbox: «Unable to communicate with device»

# hp-toolbox
# error: Unable to communicate with device (code=12): hp:/usb/printer id

Virtual CDROM printers

This can also be caused by printers such as the P1102 that provide a virtual CD-ROM drive for MS Windows drivers. The lp appears in /dev/ and then disappears. In that case, try the usb_modeswitch package, that lets one switch off the «Smart Drive» (udev rules included in said package).

Networked printers

This can also occur with network attached printers using dynamic hostnames if the avahi-daemon is not running. Another possibility is that hp-setup failed to locate the printer because the IP address of the the printer changed due to DHCP. If this is the case, consider adding a DHCP reservation for the printer in the DHCP server’s configuration.

hp-setup asks to specify the PPD file for the discovered printer

Furthermore, when selecting a PPD file in hp-setup’s graphical mode, the field does not update and no error message is shown.

Or, if in interactive (console) mode, you may encounter something similar to this even when providing a correct path to a valid ppd file:

 Please enter the full filesystem path to the PPD file to use (q=quit) :/usr/share/ppd/HP/hp-deskjet_2050_j510_series.ppd.gz
 Traceback (most recent call last):
   File "/usr/bin/hp-setup", line 536, in <module>
     desc = nickname_pat.search(nickname).group(1)
 TypeError: cannot use a string pattern on a bytes-like object

The solution is to install and start cups before running hp-setup.

hp-setup: «Qt/PyQt 4 initialization failed»

Install python-pyqt4^AUR, which is an optdepend of hplip. Alternatively, to run hp-setup with the command line interface, use the -i flag.

hp-setup: finds the printer automatically but reports «Unable to communicate with device» when printing test page immediately afterwards

This at least happens to hplip 3.13.5-2 for HP Officejet 6500A through local network connection. To solve the problem, specify the IP address of the HP printer for hp-setup to locate the printer.

hp-setup: «KeyError: ‘family-class'»

If adding a printer fails silently in the UI or you receive a KeyError: 'family-class' traceback from hp-setup, the /usr/share/hplip/data/models/models.dat may need to be manually updated.
Check if family-class=Undefined is defined the section for your printer, if not add it:

/usr/share/hplip/data/models/models.dat

[hp_laserjet_pro_mfp_m225dw]
...
family-class=Undefined

Broken pipe

If /var/log/cups/error_log contains the HTTP_STATE_WAITING Closing for error 32 (Broken pipe) error, you probably need to install the hplip-plugin^AUR and restarts the cups service.

Other

Printer «Paused» or «Stopped» with Status «Rendering completed»

Low ink

When low on ink, some printers will get stuck in «Rendering completed» status and, if it is a network printer, the printer may even become unreachable from CUPS’ perspective despite being properly connected to the network. Replacing the low/depleted ink cartridge(s) in this setting will return the printer to «Ready» status and, if it is a network printer, will make the printer available to CUPS again.

Note: If you use third-party ink cartridges, the ink levels reported by the printer may be inaccurate. If you use third-party ink and your printer used to work fine but is now getting stuck on «Rendering completed» status, replace the ink cartridges regardless of the reported ink levels before trying other fixes.

If a remote printer requests authentication CUPS will automatically add an AuthInfoRequired directive to the printer in /etc/cups/printers.conf. However, some graphical applications (for instance, some versions of LibreOffice [2]) have no way to prompt for credentials, so printing fails.
To fix this include the required username and password in the URI.
See [3], [4].

Unknown supported format: application/postscript

Comment the lines:

application/octet-stream        application/vnd.cups-raw        0      -

from /etc/cups/mime.convs, and:

application/octet-stream

in /etc/cups/mime.types.

Print-Job client-error-document-format-not-supported

Try installing the foomatic packages and use a foomatic driver.

If that does not fix, you maybe have to remove the printer from your printer list, then manually search for your printer driver (usually you can find it on AUR), and then add the printer again.

Unable to get list of printer drivers

(Also applicable to error «-1 not supported!»)

Try to remove Foomatic drivers or refer to CUPS/Printer-specific problems#HPLIP for a workaround.

lp: Error — Scheduler Not Responding

If you get this error, ensure CUPS is running, the environmental variable CUPS_SERVER is unset, and that /etc/cups/client.conf is correct.

«Using invalid Host» error message

Try adding ServerAlias * into /etc/cups/cupsd.conf.

Cannot print from LibreOffice

If you can print a test page from the CUPS web interface, but not from LibreOffice, try to install the a2ps package.

Printer output shifted

This seems to be caused by the wrong page size being set in CUPS.

Printer becomes stuck after a problem

When an issue arises during printing, the printer in CUPS may become unresponsive. lpq reports that the printer is not ready, and it can be reactivated using cupsenable. In the CUPS web interface, the printer is shown as Paused, and can be reactivated by resuming the printer.

To automatically have CUPS reactivate the printer, change ErrorPolicy from the default stop-printer to retry-current-job.

Samsung: URF ERROR — Incomplete Session by time out

This error is usually encountered when printing files over the network through IPP to a Samsung printer, and is solved by using the samsung-unified-driver^AUR package.

Note: The corresponding error code 11-1112 corresponds to an internal wiring problem with the printer, so contacting Samsung’s tech support is futile.

Brother: Printer prints multiple copies

Sometimes the printer will print multiple copies of a document (for instance a MFC-9330CDW printed 10 copies). The solution is to update the printer firmware.

Regular user cannot change properties of the printer or remove certain jobs

If a regular user needs to be able to change the printers properties or manage the printer queue, the user may need to be added to the sys group.

Cannot login into web interface

Check if there is more than one cupsd process running. If this is the case then stop cups.service, kill all processes named cupsd and start cups.service again.

No Suitable Destination Found

If a printer prefers ipps (ipp-secure), Cups will store the printer’s certificate in /etc/cups/printers/ssl. However, these certificates are never removed, even if invalid. There are several ways for a certificate to become invalid, apart from expiring: for example, if you switch from standard, self signed, printer certificates to official SSL-certificates; if your printer software is upgraded and it generates a new certificate; or if a printer is simply changed for a new one with the old name. In any of these situations, Cups will not renew the cached certificate, but will only complain with a rather generic message «no suitable destination found».

This is, unfortunately, *not* fixed by removing and re-installing the printer: even then, the invalid certificates are kept on the file system. The only way to fix this is to manually remove the certificates. (Note: the exact way of doing this, i.e. if it is enough to just wipe /etc/cups/printers/ssl or if you need to stop cups and/or remove the affected printer first, is lost in history — please feel free to add this information).

I have a server with two USB printers and multiple clients with Debian Bullseye. Clients are spread across LAN with same IP subnet and WLAN with a different subnet. The server shares both printer via CUPS share this printer option. The router reflects MDNS packets across these subnets.

A printer is detected on all clients as http://localhost:631/printers/Samsung_ML_2010_myserver (myserver being the server hostname)

Connection is displayed as: implicitclass://Samsung_ML_2010_myserver/

Printer is automatically going to status Paused. When I click Resume printer its status goes to Idle — «No suitable destination host found by cups-browsed.».

When trying to print the status goes to Paused — «No destination host name supplied by cups-browsed for printer «Samsung_ML_2010_myserver», is cups-browsed running?»

When I delete the printer locally it immediately appears again with status Idle but still doesn’t work. The only way I found so far to make the printer work again is to reboot the client.

I tried this to reset CUPS to a clean state but it doesn’t help:

systemctl stop cups-browsed
systemctl stop cups

rm -fv /var/cache/cups/cups-browsed-options-*

systemctl start cups
systemctl start cups-browsed

1. How to restart/reset CUPS to make it correctly detect the «new» printer again? Having a workaround as a shell script would help a bit.
2. How to actually fix the problem of the printer becoming invalid?

Brother MFC-J430w^[1] is a wireless network printer and scanner. It connects to my home network as a remote device.

On OpenSuSE 13.1, I use the official drivers^[2]. Both Ubuntu 18.04LTS and 20.04 LTS have build-in printer support but need to install the official scanner driver. There are some issues with 20.04LTS.

1. Setup MFC-J430w
2. Adding Firewall Rules
3. Print on Ubuntu 20.04 LTS
4. Print on OpenSuSE 13.1
5. Scan on Ubuntu 20.04 LTS
6. Scan on OpenSuSE 13.1
7. The Error Code 46 Issue

Setup MFC-J430w

Get the MAC

I have enabled the MAC management on my home router. I need J430w’s MAC and add it to the allow list before connecting.

Use the J430w’s control panel to get its MAC:

[Menu]→[Network]→[MAC Address]

Join the SSID and connect

Use the J430w’s control panel to connect to the router:

[Menu]→[Network]→[Setup Wizard]

Get the assigned IP

Use the J430w’s control panel to get the assigned IP:

[Menu]→[Network]→[TCP/IP]→[IP Address]

It can be found on the router administration tool by comparing the MAC, too.

The IP used in the post is 192.168.1.10

Adding Firewall Rules

Allow these ports^[3] for [Scan] on J430w:

1. Inbound: UDP Port 54925
2. Outbound: TCP Port 54921

I add these bi-direction rules because the one-way rules don’t work properly. There are more ufw commands to learn^[4].

$sudo ufw allow 54925/udp
$sudo ufw allow 54921/tcp

Print on Ubuntu 20.04 LTS

Ubuntu 18.04LTS and 20.04LTS may automatically identify J430w within the same network. But there are some print issues with 20.04LTS,  it fails to print sometimes.

Here is a summarized table to compare:

Issues

CUPS fails to find J430w and would mark unfinished jobs completed. There is a similar bug report.^[5]

After several tests, I found it happen when:

1. J430w is sleeping
2. Printer connection is changed

Possible error messages and result:

1. “No suitable destination host found by cups-browsed”.
2. “No destination host name supplied by cups-browsed for printer “Brother_MFC_J430W’, is cups-browsed running?”.
3. Job completed but print nothing.

Most can be solved by restarting CUPS to re-initialize the connection:

$sudo systemctl restart cups.service

If it doesn’t help, remove the printer in GNOME Settings. Then turn-off and turn-on the WiFi. A new printer would be installed.

J430w is sleeping

When the printer is in sleep mode, CUPS might unable to communicate. There is a J430w in GNOME Settings but the [Additional Printer Settings…] button shows nothing. Use the built-in administrative tool of CUPS daemon at ‘http://localhost:631/printers’ finds no printer, either.

Solution 1: wake up the printer and restart CUPS. The printer should be identified automatically.

Solution 2: wake up the printer and switch off/on WiFi. The printer should be identified automatically.

If J430w is found but the job is held with “No suitable destination host found by cups-browsed”, the connection is lost. It won’t be able to print even after waking up the printer manually.

It seems to be related to the printer idle time. The longer it is, the fewer chance that CUPS may restore the connection.

Solution 1: wake up the printer and restart CUPS. Release the held job to print in CUPS.

Solution 2: wake up the printer and restart Ubuntu. Release the held job to print in CUPS.

Printer connection is changed

The official document suggests installing LPR printer driver^[6] before CUPSwrapper printer driver^[7] and modifying the connection string. Both are bad ideas on 20.04LTS.

If I change the default connection to LPD/LPR with ‘lpd://192.168.1.10/binary_p1’, a new network printer would be added. The modified printer won’t print anything but the job is marked as completed.

Restoring the old connection string won’t make it work again.

It makes no difference to modify the “/etc/printcap” file.

Solution 1: delete the modified printer and restart CUPS. The new network printer will be disappeared. CUPS will create a new printer as it founds for the first time.

Solution 2: delete the modified printer and restart Ubuntu. The new network printer will be disappeared. CUPS will create a new printer as it founds for the first time.

Removing installed drivers

Removing official drivers in the following order else it would fail. They are not necessary with 20.04LTS.

$sudo apt-get remove mfcj430wcupsweapper
$sudo apt-get remove mfcj430wlpr

Print on OpenSuSE 13.1

Use the official drivers

1. Download and install LPR printer driver (rpm package)
2. Download and install CUPSwrapper printer driver (rpm package)

Configure in YaST

1. Launch Printer in YaST. “MFCJ430W” is installed in “Printer Configurations”.
2. [Edit] this configuration.
3. Use [Connection Wizard] to provide the IP: [Access Network Printer or Printserver Box via]→[TCP Port (AppSocket/JetDirect)]→[IP Address or Host Name].
4. Change the [Default Paper Size of the Current Driver] if necessary.
5. Use [Print Test Page] to check.

Scan on Ubuntu 20.04 LTS

Use the official driver

1. Download and install Scanner driver 64-bit (deb package)^[8].

I didn’t install the Scan-key-tool 64bit (deb package)^[9] because W430j sometimes fails to communicate. This feature is not important to me.

Configure in terminal

1. Run the command to configure the scanner:

   $sudo brsaneconfig4 -a name=Brother_Scanner model=MFC-j430w ip=192.168.1.10
   

Scan from XSane

1. Download and install XSane.
2. Launch XSane to test. Use [Acquire preview] to preview the scannable area, “Type” to specify the image file type, [floppy disk] icon to assign saved destination, and [Scan] to begin.

Scan on OpenSuSE 13.1

Use the official driver

1. Download and install Scanner driver 64bit (rpm package).
2. Download and install Scan-key-tool 64bit (rpm package).

Configure in terminal

1. Run the command to configure the scanner:

   $sudo brsaneconfig4 -a name=Brother_Scanner model=MFC-j430w ip=192.168.1.10
   

2. Run the command to start receiving the [Scan] key signal and data from J430w:

   $sudo brscan-skey
   

3. Run the command to test if the device name is identified:

   $ brscan-skey -l
   Brother_Scanner : brother4:net1;dev0 : 192.168.1.10 Active
   

To remove the existing scanner configuration, run the command:^[10]

$sudo brsaneconfig4 -r Brother_Scanner

Scan from Acquireimages

1. Launch Acquireimages to test.
2. If it’s not installed, use XSane instead. Follow the instructions to install.^[11]
3. Press [SCAN] button→[Scan to Image]→Choose the account you want to scan to →[OK]→[Start] button → choose [1] if there are more pages or [2] to stop.
4. GIMP shall be launched and load the scanned image automatically.

Scan from J430w

1. Run brscan-skey in a terminal.
2. Use the [Scan] button on W430j and follow the instruction to scan. It creates a new image file in the ~/brscan folder.

* The [Scan] button supports color scan only.

** More commands for brscan-key:^[12]

The Error Code 46 Issue

It means the ink absorber pad is full^[13]. I have to replace it or reset the counter.

Entering Maintenance Mode

1. Pull the plug
2. Press and hold the [Color] button. Plug to power socket at the same time.
3. When “Maintenance” is displayed on J430w’s screen, release the button.

Reset Error 46

1. In maintenance mode, press ’80’.
2. Select [PURGE:000XXX] with [Up]/[Down] buttons.
3. Enter ‘2783’ to reset. When success, it will display “PURGE: 000000”
4. Press [Stop] to return to the front page of maintenance mode.
5. Input ’99’ to quit. The machine will reboot automatically.

Style Guide

<?PHP echo''; ?>

$ls -la

Reference

1. 1. Brother: MFC-J430w
   2. Brother: MFC-J430w Downloads
   3. Brother: MFC-J430W: FAQs & Troubleshooting
   4. nixCraft: How To Configure Firewall with UFW on Ubuntu 20.04 LTS
   5. Ubuntu: cups package: Problem with printing in 20.04 version
   6. Brother: LPR printer driver (deb package)
   7. Brother: CUPSwrapper printer driver (deb package)
   8. Brother: Scanner driver 64bit (deb package)
   9. Brother: Scan-key-tool 64bit (deb package)
   10. openSUSE: Forum: Thread: Help With Wireless Scanner
   11. openSUSE: xsane
   12. Brother: Command List of brscan. (Linux)
   13. Brother: How do I clear Machine Error 46?

Published
2014/03/012020/06/15

Foreword

If you are experiencing a problem with printing, please take a look at the common bugs page before filing a bug. If the problem you are seeing is not listed there or none of the workarounds seem to help, please consider filing a bug report to help us make Fedora run better on your hardware.

Identifying your problem area

Printing issues can be fairly complex and active cooperation or lots of data can be requested from reporter by maintainer to helping maintainer to at least understand and (if it is not hardware specific issue) reproduce the issue, so please have a patience and try to narrow the problem as much you are able to for maintainers.

There can be:

• issues with seeing or connecting to the printer (it can be cups backend issues, avahi issues, libusb issues, cups-browsed issues),
• accessibility issues (correct/wrong setup in cupsd.conf or its bad interpretation by cupsd daemon, bad cooperation with NIS, SSSD…),
• printing with help of samba (issues with smb backend, which is part of samba) or with samba authenticated through Kerberos (samba_krb5_printing),
• issues with filters used during filtering the document into document format supported by printer, which influence how or if the document will be printed (issue with filters — pdftops, pdftopdf, pstops, bannertopdf etc. — or issues with binaries or libraries which filters uses — libgs, qpdf, poppler…),
• issues with Postscript Printer Description files, which are old way of defining printers capabilities like supported page sizes, borders etc…

Not mentioning possible limitations or issues in firmware or hardware of printer itself, so any kind of data or narrowing the issue is welcomed.

The best start is to attach files with logs described further down.

CUPS logging

All CUPS logging is redirected to journal by default since Fedora 28 (there was a redirecting of error_log to journal by default before Fedora 28, since Fedora 20). Printing troubleshooter doesn’t have a feature to get logs from systemd journal yet, so CUPS logs need to be acquired by following steps.

We need to define two different ways of capturing incident-bound CUPS whole logs — the one if the broken print queue isn’t provided by HPLIP and the other if it is. They differs in the filter option of journald — if you use non-HPLIP queue for debugging, it is okay to gather the logs from cups systemd unit (by ‘-u cups’), because all error messages are correctly redirected to cups systemd unit logging and they are accessible in the output after unit filtering. HPLIP libraries are not implemented to do the same (upstream is unresponsive to accept a potencial fix into the project and the issue is not critical enough to drag a downstream patch forever), so their messages aren’t marked for cups systemd unit and they’re filtered out after calling journald with ‘-u cups’. For such queues journald log without filtering is required.

Note:

Incident-bound journald log without filtering is required only for HPLIP print queues (their device uri starts with hp://) and it is unwanted for other queues, because it can be hard to read in larger cases. Please attach incident-bound journald log only when it is necessary.

Location of CUPS logging

CUPS logging is located in the system journal by default, but the logging into a file can be set in /etc/cups/cups-files.conf with directive ‘ErrorLog’. If you want to change the default settings, then the name of the logging file is irrelevant, but it is recommended to put the file into path ‘/var/log/cups’, otherwise SELinux will block cupsd from accessing it.

Setting the logging to a file has following cons (without further operations):

• unable to get only logs connected to a job without chaining more commands
• unable to get logs for specified time frame without chaining more commands

For capturing a incident-bound logs ‘tail -f’ can be used e.g.:

tail -f /var/log/cups/error_log

Enable CUPS debug logging

Enable full debugging information with:

sudo sed -i 's,LogLevel warn,LogLevel debug2,' /etc/cups/cupsd.conf

CUPS job log

IMPORTANT If the problem appears when you sent document to print or if you are trying to, capture logs for this job. If the job log is available, its attaching is REQUIRED.

Prepare CUPS for job logging

For being able to see specific job log, please turn on:

PreserveJobFiles Yes

in your /etc/cups/cupsd.conf file and restart cup service. Do not forget to remove the line after you are done with debugging. ‘lpstat -W all’ seems to be empty after printing if you do not enable the directive.

Get a job log for a specific Job ID

To capture job log you need to know Job ID (JID) of the job — it is a number which together with print queue name specifies the job as request ID — for getting logs specific for the job.

Job ID can be seen in terminal if you send a document to print by lp command:

$ lp -d <print_queue_name> <file1> ... <fileN>
request id is <print_queue_name>-<JID> (N file(s))

Or when you list jobs (see man lpstat) — the latest job is at the end:

$ lpstat -W all
...
<print_queue_name>-<JID>           <user>           1024   Wed 11 Jan 2017 05:52:19 PM CET

You can get the latest job logs automatically (if you have awk installed and lpstat -W all returns jobs) by:

$ journalctl -u cups JID=`lpstat -W all | awk '{print $1}' | awk -F '-' '{print $NF}' | tail -n 1` > cups_job_log

Or manually, if you found JID by yourself:

journalctl -u cups JID=<JID> > cups_job_log

Incident-bound cupsd log (broken print queue isn’t HPLIP supported)

Sometimes we cannot bind the error with a specific print job, so the job log is uneffective. Incident-bound cupsd log is needed.

How to start to capture incident-bound cupsd logging

In new terminal/terminal tab, please issue:

journalctl -f -u cups > cups_whole_log

How to get incident-bound cupsd logging

After you trigger the error condition you are trying to diagnose e.g. printing something, try to find a printer via lpinfo etc., you terminate capturing incident-bound cupsd log from step above by ctrl+c.

Incident-bound cupsd log (broken print queue is HPLIP supported)

Unfortunately, HPLIP libraries don’t log into CUPS unit in journal, so if your print queue is installed with HPLIP driver (its device uri starts with hp://), we need incident-bound journal log.

How to start to capture incident-bound journal logging

In new terminal/terminal tab, please issue:

journalctl -f > journal_whole_log

How to get incident-bound journal logging

After you trigger the error condition you are trying to diagnose e.g. printing something, running HP script etc., you terminate capturing incident-bound journal log from step above by ctrl+c.

Turning off debug logging

Please attach cups_job_log for the problematic job, cups_whole_log or journal_log if you caught whole cupsd log during the problematic event to bug report as an attachment.

Then to turn off debugging information, do this:

sudo sed -i 's,LogLevel debug2,LogLevel warn,' /etc/cups/cupsd.conf

More commands for working with systemd-journald

View the log messages with:

journalctl -u cups -e

or:

journalctl -u cups --since=...

To filter out messages relating to a specific job ID, use:

journalctl -u cups JID=...

(tab completion will show you which job IDs have log messages)

cups-browsed logging

cups-browsed daemon was introduced in Fedora around cups-1.5 version. It can browse Bonjour broadcasts, CUPS broadcasts (deprecated) and LDAP servers for printers and create or remove local queues pointing to those printers. It can creates broadcasts of local CUPS queues, but it is marked as deprecated.

For setting debug logging on you need to add:

DebugLogging stderr

to /etc/cups/cups-browsed.conf.

The logs will be available in system journal after cups-browsed restart.

HPLIP scripts debug logging

Python scripts from HPLIP (e.g. hp-setup, hp-clean, hp-scan) have debug logging redirected to the standard error file descriptor, so they are not logged in journal. For getting their debug logging, run the script with -ldebug parameter e.g.:

$ hp-setup -ldebug -i

and reproduce the issue. Then copy the messages from terminal into hp_script_log. Please attach the file to the bugzilla ticket too.

What make and model is my printer?

Each different printer has a model-specific Device ID. You can find out with the lpinfo command:

lpinfo -l -v

This command runs each of the backends in discovery mode, to get them to report devices they can automatically detect. This will output a series of blocks of lines, each one like this:

Device: uri = usb://HP/DESKJET%20990C?serial=U123456789AB
        class = direct
        info = HP DESKJET 990C
        make-and-model = HP DESKJET 990C
        device-id = MFG:HEWLETT-PACKARD;MDL:DESKJET 990C;CMD:MLC,PCL,PML;CLS:PRI
NTER;DES:Hewlett-Packard DeskJet 990C;SN:U123456789AB;S:00808880800010032C100000
0C2000000;P:0800,FL,B0;J:                    ;
        location = 

The line which identifies this particular model type is the long one that starts «device-id =» (shown here wrapping over three lines).

Note that if your printer cannot be automatically detected, you may still be able to find out the Device ID by running the appropriate backend with the printer hostname as the argument. The usb, parallel, snmp, and dnssd backends all try to report the actual Device ID given by the printer.

$ /usr/lib/cups/backend/snmp 10.34.18.3

network socket://10.34.18.3 "HP Color LaserJet CP2025dn" "HP Color LaserJet CP2025dn"
"MFG:Hewlett-Packard;CMD:PJL,PML,PCLXL,POSTSCRIPT,PCL;MDL:HP Color LaserJet CP2025dn;
CLS:PRINTER;DES:Hewlett-Packard Color LaserJet CP2025dn;MEM:MEM=55MB;COMMENT:RES=600x8;" "HP Color LaserJet CP2025dn" 

Device ID is in this case (see backend(7)) the last but one field.

Which print queues are available for me?

The queues on your machine can be permanent ones or temporary. CUPS is capable to list all available print queues on the local network (permanent and temporary queues) by:

$ lpstat -e

For permanent queues you are able to get more info with:

$ lpstat -t

Which driver am I using?

The PPD file for the printer queue can tell you which driver is in use. You can use this command to find out which driver is being used:

grep -H '^*NickName:' /etc/cups/ppd/*.ppd

You can also find this out using the system-config-printer application. Double-click on the icon for the queue and look at the Make and Model field.

To see the available drivers, click on the Change… button next to that field. You might find it useful to try another driver to see if that shows the same problem.

Driverless models

Most printers released since 2010 are capable of AirPrint or IPP Everywhere, which means they don’t need to be installed to work — the device is found by Avahi and the print capabilities are communicated via IPP protocol — they are basically driverless devices. There are two solutions in Fedora which implement IPP everywhere:

• CUPS ‘everywhere’ model
• cups-filters ‘driverless’ driver

CUPS ‘everywhere’ model

It is CUPS implementation of IPP everywhere standard, available as a special printer model. The model is used when you use CUPS temporary queue for your device or if you install your device with as IPP Everywhere model in CUPS web ui or via lpadmin (using -m everywhere).

Because the created PPD file depends on IPP communication with printer, we need info which is gathered from the device. You can use ipptool for that:

$ ipptool -tv <your_printer_device_uri> get-printer-attributes.test &> ipptool_log

Attach the created ipptool_log to the bugzilla ticket if needed.

cups-filters ‘driverless’ driver

Cups-filters special driver which is used for generating PPD according IPP Everywhere standard. The driver is used if you choose driverless model during printer installation.

We need get-printer-attributes request output too:

$ ipptool -tv <your_printer_device_uri> get-printer-attributes.test &> ipptool_log

and debug logs from the driver itself when it generates PPD for your device:

$ driverless -d cat <ipp_device_uri> 2> driverless_debug > created_ppd

Attach all created files to the bugzilla ticket if needed.

Finding where the problem lies

When a print job is processed it is sent through a chain of filters to convert the file into a format the printer can understand, and then finally sent to a backend, a program which can transport the data to the printer. By slightly changing how you print you can try a different printing path to see if that changes anything. If it works around the problem, you know which area the problem was in — include that information in a bug report so that we can fix it.

Application

Try printing from a different application to see if the problem goes away or if it occurs regardless of how a file is printed. Try printing the document from the command line using the lp command.

Document format

If you are having problems printing PDF files, try printing other types of file to see if the problem is with printing anything or if it is specific to printing PDF files. Try converting the file to a different format and printing that.

If the problem relates to printing text files, try removing/installing the paps package. This package provides an alternative text-to-PostScript filter to the one that comes with CUPS.

To inspect the document that was submitted to CUPS for printing, enable the PreserveJobFiles option like this:

cupsctl PreserveJobFiles=yes

Submitted job documents will remain in /var/spool/cups. There are files with two types of names — dXXXXX-YYY and cXXXXX. dXXXXX-YYY is file which goes to CUPS system, unfiltered file — XXXXX is job ID, which is filled with zeros to be 5 characters long, and YYY is sequence number of file in the job. cXXXXX is file which contains printing options for a job specified by job ID in XXXXX. Please attach dXXXXX-YYY to the bug for a job when you experience the issue

Running filters by hand

More advanced users may like to try running the CUPS filters by hand and examining the data file at each step as it is converted between different formats. Here is an example of doing this for a gutenprint queue named pqueue with the CUPS test page which is its own special MIME type, application/vnd.cups-banner:

First you need to know the filter pipeline for application/vnd.cups-banner —> printer/pqueue (output MIME type).
You can either enable debugging, print a test page, look into /var/log/cups/error_log and you’ll find something similar to:

envp[29]="FINAL_CONTENT_TYPE=printer/pqueue"
Started filter /usr/lib/cups/filter/bannertopdf (PID 1111)
Started filter /usr/lib/cups/filter/pdftopdf (PID 1112)
Started filter /usr/lib/cups/filter/gstoraster (PID 1113)
Started filter /usr/lib/cups/filter/rastertogutenprint.5.2 (PID 1114)

or run

/usr/lib/cups/filter/bannertopdf 1 me '' 1 '' </usr/share/cups/data/testprint >bannertopdf.pdf
cupsfilter -e -m printer/pqueue -p /etc/cups/ppd/pqueue.ppd bannertopdf.pdf > /dev/null

and you’ll see:

INFO: pdftopdf (PID 1111) started.
INFO: gstoraster (PID 1112) started.
INFO: rastertogutenprint.5.2 (PID 1113) started.

Now you can run filters by hand:

export PPD=/etc/cups/ppd/pqueue.ppd
/usr/lib/cups/filter/bannertopdf 1 me '' 1 '' </usr/share/cups/data/testprint >bannertopdf.pdf
/usr/lib/cups/filter/pdftopdf 1 me '' 1 '' <bannertopdf.pdf >pdftopdf.pdf
/usr/lib/cups/filter/pdftoraster 1 me '' 1 ''<pdftopdf.pdf >out.ras
/usr/lib/cups/filter/rastertogutenprint.5.2 1 me '' 1 ''<out.ras >out.prn

Here, evince or okular can be used to examine the output after the first two filters, rasterview can be used to examine the output of the third filter, and the last filter’s output must be inspected by hand or sent directly (lpr -oraw out.prn) to the printer.

Driver

If you have access to a different make/model of printer it might be worth trying to see if the problem occurs on both of them or just one. This can give an indication about whether it is a problem with a particular driver, or if it is a more general problem.

Even if you only have access to the one printer there is often a choice of drivers to use for a given printer model, and trying each one in turn can be useful in narrowing down the problem. See above for how to do that.

Foomatic

For Foomatic drivers you can try enabling Foomatic debugging by editing the file /etc/foomatic/filter.conf and adding a line:

debug: 1

Next time you print a job to a queue using foomatic the debugging will be put in /tmp/foomatic-rip.log, and the input file as received by foomatic-rip will be in /tmp/foomatic-rip.ps.

Backend (job transport)

It may be possible for you to try a different backend. Using system-config-printer, double-click on the printer queue icon and click the Change… button next to the Device URI field. You may see a Connection expander arrow near the bottom right hand corner of the window — click that to see which backends are available. For USB-connected HP printers, typically either of the hp and usb backends can be used.

For capturing USB communication:

• find out the bus number where USB device is connected, f.e.:

$ lsusb
Bus 002 Device 010: ID 03f0:012a HP, Inc HP LaserJet M1536dnf MFP
      =

• start USB packet capture:

$ sudo tcpdump -i usbmonN -s0 -w usb.pcap

where N is the bus number.

For network printers you may have different protocols you can try.

• socket is for HP JetDirect (usually port 9100)
• lpd is for older style UNIX print shares
• smb is for CIFS shares from Windows systems
• ipp is for Internet Printing Protocol-enabled devices and also for other CUPS servers
  • You can capture the IPP traffic with tcpdump like this (the interface name may differ from p4p1):

 tcpdump -n -i p4p1 -U -s0 -w ipp.pcap port ipp

• bjnp is for Canon’s proprietary bjnp network protocol (usually port 8611)

Configuration tool

If your problem relates to configuring print queues, try using one of the other methods of doing so. There are four available:

• The GNOME 3 System Settings application (control-center), System Settings > Printers from the GNOME Shell
• system-config-printer, System > Administration > Printing from the GNOME menu
• the CUPS web interface, http://localhost:631/
• the command line tools lpadmin, lpoptions, cupsctl, cupsaccept, cupsenable etc.

User stories

There are several common user stories when it comes to debugging printing issues. I’ll mention some of them with steps how to get necessary information.

I have HP printer and have a problem with HPLIP script

Please follow the steps in the following sections:

• enable CUPS debug logging
• start to capture journal logs
• run the script with enabled debugging
• get the journal logs
• attach the files to the bugzilla ticket and turn off debug logging
• provide printer model name and printer PPD file from /etc/cups/ppd/

I have HP printer, installed it with HPLIP and have a problem with it

HPLIP installed print queue has a device uri starting with hp://.

Please follow the steps in the following sections:

• enable CUPS debug logging
• start to capture journal logs
• trigger your issue
• get the journal logs
• attach the requested files to the bugzilla ticket and turn off debug logging
• provide printer model name and printer PPD file from /etc/cups/ppd/

My printer doesn’t print correctly or at all, but I can see the printer in print dialog

Please follow the steps in the following sections:

• enable CUPS debug logging
• prepare CUPS for job logging
• restart CUPS service
• trigger your issue — print the specific document to the specific print queue you have problem with
• get the job log for the job you have just triggered
• attach the created files to the ticket and turn off debugging
• attach your printer PPD file from /etc/cups/ppd/ if available
• attach the file you wanted to print
• tell what application you printed from
• mention your printer model

CUPS generic issue

For generic issues — printer wasn’t found, segfault — please follow the steps in the following sections (avahi-daemon must run):

• enable CUPS debug logging
• start to capture logs
• trigger the issue — e.g. try to find printers via sudo lpinfo -l -v, do some action in web ui — depends on your problem
• get the logs
• attach created files to the ticket and turn off debugging
• put the output of lpinfo into a file and attach it
• put the output of both lpstat commands into a file and attach it

My printer doesn’t print correctly — I use ‘everywhere’ model

Please follow the steps in the following sections:

• get data from get-printer-attributes request
• follow the steps with CUPS job log user story

I have a generic problem with cups-browsed

Please follow the steps in the following sections:

• enable CUPS debug logging
• enable cups-browsed logging, but don’t restart cups-browsed yet.
• start to capture cupsd logs
• start cups-browsed via systemctl and start to capture its logs:

$ journalctl -u cups-browsed -f > cups_browsed_log

• trigger the issue or wait until cups-browsed triggers the issue itself
• cancel cups-browsed and cupsd log captures
• attach created files cups_whole_log and cups_browsed_log to the ticket and turn off debugging

Printer found by cups-browsed doesn’t print or print badly

The most difficult user story — we need to know how the print queue was created and how it behaves during printing. The print queue found by cups-browsed has a device uri starting with implicitclass://.

Please follow the steps:

• get printer info from get-printer-attributes and PPD file
• enable CUPS debug logging
• enable cups-browsed logging, but don’t restart cups-browsed yet.
• start to capture cupsd logs
• start cups-browsed via systemctl and start to capture its logs:

$ journalctl -u cups-browsed -f > cups_browsed_queue_creation

• give cups-browsed some time to process found devices (depends on how many devices you have in the local network or how many print queues are stored in the location you set with BrowsePoll directive)
• cancel cups-browsed and cupsd log captures — save the files as cups_queue_creation and cups_browsed_queue_creation

Now we need to capture the logs during printing:

• prepare CUPS for job logging
• restart CUPS service
• start to capture cups_browsed logs again:

$ journalctl -u cups-browsed -f > cups_browsed_printing

• trigger your issue — print the specific document to the specific print queue you have problem with
• get the job log for the job you have just triggered and cancel the capture of cups-browsed logging
• attach all gathered log files

Filing a bug report

Deciding which component

Problems involving printing may relate to several components.

The configuration GUI (See above) is either GNOME 3 System Settings application or system-config-printer. These packages also provide the printer applet, handle automatic queue creation, and disable/enable queues when USB printers are disconnected and reconnected.

Most GTK+ applications use the GTK+ print dialog. If the problem occurs when using GTK+ applications but not when printing from the command line or from another non-GTK+ application, the problem should probably be reported against gtk2. If the problem occurs with only one GTK+ application, and other GTK+ applications print fine, the bug should be filed against that particular application.

If the problem only happens with PDF files, the bug may well be in poppler (the CUPS pdftops filter is a wrapper around one of the poppler utility programs).

Report bugs only seen using the smb backend against samba.

For bugs only seen when using the hp backend, or the hpijs or hpcups drivers, select hplip for the component.

For bugs for cups-browsed daemon and its printer discovery, please select cups-filters

Other possibilities, depending on the problem, include:

• foomatic (the Foomatic CUPS filter and driver)
• foomatic-db (the actual printer database used by Foomatic)
• ghostscript (which converts PostScript to other formats)
• gutenprint (a driver that supports very many printers)

For anything else, or if you are not sure, choose cups or use your best guess.

Other information to include

Be prepared to include some information about your system as well. Some of this can be gathered automatically using the printing troubleshooter, but you may also need to include other information.

Before gathering of information

• Please change your OS locale to English. Manual [1].
• Please attach gathered information as archive (example is here, you may need root permissions) to the bugzilla issue.
• Please do not forget to trigger your issue after debug enabling and restarting cups and before information gathering.

Information to gather

• the PPD file for the print queue (from the /etc/cups/ppd directory)
• the document you are attempting to print — if the document is large, please try to see if the problem also occurs with a smaller document
• cupsd journal logs when debug level 2 is turned on. How-to for turning debug2 on and for getting logs from systemd-journald is above.
• if the issue is connected to a print job, attach journal logs for this specific job too. How-to get logs here, example with JID. You can find out JID value by command:

$ lpstat -W all

. Find your job there and JID is a number after ‘-‘.

• If the issue is about f.e. ‘printing from evince prints garbage, but printing from libreoffice works’, then attach two separate files — first will contain logs when you print from evince, latter logs when you print from libreoffice.
• troubleshoot.txt from system-config-printer (BEWARE: it doesn’t contain journal logs — don’t forget to attach them too).
• make and model of printer
• config files — /etc/cups/client.conf (if it contains any changes from default), /etc/cups/cupsd.conf
• if the issue is with cups-browsed and printer’s discovery, attach /etc/cups/cups-browsed.conf and cups-browsed logs gained by how-to above.

Some example documents can be found in the Printing Test Cases category.

Further reading

The main printing page has more information about how printing works in Fedora.

How to debug scanning issues

SANE library, communication libraries and backends can turn on and off debug logging via SANE_DEBUG_* environment variables.

The common environment variables:

• SANE_DEBUG_DLL — enables debugging SANE library
• SANE_DEBUG_SANEI_USB — enables debugging communication library for USB — add the environment variable if your device is connected via USB cable
• SANE_DEBUG_SANEI_TCP — enables debugging communication library for wireless/ethernet — add the environment variable if your device is connected by Wifi or Ethernet

Environment variables for enabling debugging a specific backends have a structure — SANE_DEBUG_<backend_name>, so the environment variable for f.e. HPAIO backend is SANE_DEBUG_HPAIO.

You can find which SANE backend supports your device here. If your device is HP and it isn’t supported by airscan backend or any other SANE backend, it can be supported by hpaio backend from hplip package, see the list of supported devices here.

Before you start debugging

The acquired log files can be quite big in case you use high resolution, do colored scanning, use higher scanning steps etc., so it would be great if you checked whether your issue happens:

• with the lowest scanning step
• with the lowest resolution
• in Lineart mode
• with .pnm as output file format

If the issue happens even with the lowest settings, do use these settings during debugging steps below.

Debugging scanner discovery

If you don’t see your scanner in scanning application, then debugging of discovery process is in order. I prefer using scanimage in the examples, but the similar steps can be applied for every scanning application like xsane, scanadf, simple-scan etc.

You will need to use environment variables when you start a scanning application (scanimage in this case). The environment variables used with scanimage command depends on how your scanner is connected and which backend suppose to support it. So for getting debug logs there is a skeleton:

$ SANE_DEBUG_DLL=255 SANE_DEBUG_<backend>=255 SANE_DEBUG_SANEI_<connection>=255 scanimage -L &> discovery_output

where <backend> is the name of backend which supports your device in capitals (f.e. PIXMA, AIRSCAN, GENESYS, HPAIO). You can find which backend supports your device here. If your device isn’t on the list and you were able to scan in the past or you know your device supports eSCL or WSD, use AIRSCAN. <connection> depends on how your device is connected — strings are TCP or USB.

Please attach the created discovery_output file as an attachment to the bugzilla ticket. If the file is too big (let’s say over 5MB), do follow the steps for dividing the logs.

Debugging scanning process

If the scanner is found, but an issue happens during scanning itself, we need to debug scanning process itself — which means debugging communication between backend and scanner when you start scanning a document.

The debugging scanning itself looks similar as discovery — setup the environment variables before running the command/scanning application and catch logs into a file. The command’s skeleton is (if you use xsane):

$ SANE_DEBUG_DLL=255 SANE_DEBUG_<backend>=255 SANE_DEBUG_SANEI_<connection>=255 xsane &> debug_log

or (once you find out device uri from scanimage -L — see the previous section):

$ SANE_DEBUG_DLL=255 SANE_DEBUG_<backend>=255 SANE_DEBUG_SANEI_<connection>=255 scanimage -d <device_uri> > out.pnm 2> debug_log

, where you substitute <device_uri> for the actual device uri, f.e. ‘hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112’.

<backend> is the name of backend which supports your device in capitals (f.e. PIXMA, AIRSCAN, GENESYS, HPAIO). You can find which backend supports your device here. If your device isn’t on the list and you were able to scan in the past or you know your device supports eSCL or WSD, use AIRSCAN. <connection> depends on how your device is connected — strings are TCP or USB.

Please attach the created file — debug_log — as an attachment to the bugzilla ticket. If the file is too big (let’s say over 5MB), do follow the steps for dividing the logs.

Getting a scanner device uri

This point is basically a manual how to get a scanner uri for debugging scanning itself via scanimage. You don’t need to provide a scanner uri in GUI applications like xsane or simple-scan, because the application will do it for you or you can choose the scanner by a mouse click.

The scanimage -L command returns an output where device uri of the device is shown, f.e.:

$ scanimage -L
device `v4l:/dev/video0' is a Noname Integrated Camera: Integrated C virtual device
device `hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112&queue=false' is a Hewlett-Packard laserjet_m1536dnf_mfp all-in-one

F.e.the string ‘hpaio:/net/laserjet_m1536dnf_mfp?ip=192.168.1.112&queue=false’ is a device uri for for Hewlett-Packard laserjet_m1536dnf_mfp all-in-one scanner.

Debugging HP scanner if it is supported by HPLIP

The hplip package doesn’t have unified logging, so some logs come out of HPAIO backend to standard output and HP internal utilities logs come to journal. So we need to capture both to get the understanding of situation.

It can be done this way:

• start capturing journal logs at background:

$ journalctl -f > journal_logs &

• trigger an action (discovery or scanning)

• kill the journalctl process, f.e. this way (if there is only one journactl process)

$ kill `pidof journalctl`

then attach the created file — journal_logs — as an attachment to the bugzilla ticket. Please do only one action per capture — that means if you are asked to attach log files for HP scanner discovery and scanning supported by hplip, you will attach as an attachment four files — discovery_output, journal_logs for discovery output, debug_logs and journal_logs for debug_logs.

Debugging sane-airscan

If your device supports eSCL or WSD (you can find it out from device specification — look for the mentioned protocols or AirScan), then its scanning functionality is supported by sane-airscan. Regarding debugging, on the top of usual logging sane-airscan gathers a communication dump and output image, which is helpful during investigation.

sane-airscan debugging can be enabled in /etc/sane.d/airscan.conf by setting:

[debug]
trace = /path/to/dir/where/debugfiles/will/be/saved
enable = true

Then do trigger your issue (discovery or scanning), go to the dir you defined in /etc/sane.d/airscan.conf, take all files from there and attach them to the bug ticket.

How to divide the logs

In case your debug log is too big for bugzilla to attach (because your issue doesn’t happen with the lowest settings or logs are big even with the lowest settings), do divide the logs to three files like this:

$ grep dll debug_log > debug_log_dll
$ grep <connection> debug_log > debug_log_connection
$ grep <backend> debug_log > debug_log_backend

<backend> is the name of backend which supports your scanner (pixma, genesys, plustek, hpaio, airscan etc.), <connection> is the type of connection you use for the device (tcp, usb).

The division makes the investigation more difficult (the person needs to have three opened files at the same time), so do divide the logs only if log file is too big.

Known issues

Here are several known issues, which arise with certain circumstances, and there isn’t general solution or upstream didn’t want to add the solution to its project:

cups-browsed

Cannot print due ‘No destination hostname provided by cups-browsed, is it running?’

cups-browsed sometimes loses connection to print server (usually with old ones, like cups-1.4.2) when laptop changes network connection (change of WiFi network or after hibernate/suspend). You can make printing working again with cancelling your jobs and restarting cups-browsed by

$ cancel -a
$ sudo systemctl restart cups-browsed

cups-browsed consumes large amount of CPU

Creating local printer queues takes long time for some printers with larger PPD file, so timeout of http connection will time out and it creates infinite loop of creating local printer queues. To solve this issue, please add

HttpLocalTimeout N
HttpRemoteTimeout N

into /etc/cups/cups-browsed.conf, where ‘N’ is number of seconds after which connection is timed out. Then restart cups-browsed service. This option is currently in Fedora 27 and above.

[SINCE FEDORA 27] cups-browsed creates different printer queue names than before

This issue is connected to remote cups queues, which are advertised by older CUPS version (usually below cups-1.5, e.g. RHEL 6). Cups-browsed creates local print queues named by printer’s DNS-SD ID by default and naming by remote cups queue is enabled again by adding:

LocalQueueNamingRemoteCUPS RemoteName

into /etc/cups/cups-browsed.conf and restart cups-browsed service.

Remote DNS-SD-advertised CUPS queue shredder on host barn.local is raw, ignored.

Server queues don’t appear in desktops.

jourcnalctl -u cups-browsed output shows:

Network interfaces: lo (127.0.0.1, localhost), eno1 (172.16.0.123, desk.example.com, 172
Avahi Resolver: Service 'HP LaserJet 4100 Series @ barn' of type '_ipps._tcp' in domain.....
Avahi-Resolver: Instance: HP LaserJet 4100 Series
Found CUPS queue/class: shredder on host barn.local.
Remote DNS-SD-advertised CUPS queue shredder on host barn.local is raw, ignored.
listening

# Set CreateRemoteRawPrinterQueues to "Yes" to let cups-browsed also
# create local queues pointing to remote raw CUPS queues. Normally,
# only queues pointing to remote queues with PPD/driver are created
# as we do not use drivers on the client side, but in some cases
# accessing a remote raw queue can make sense, for example if the
# queue forwards the jobs by a special backend like Tea4CUPS.

CreateRemoteRawPrinterQueues Yes

uncommenting / switching to Yes in /etc/cups/cups-brosed.conf solves the issue.

cups-filters

Printing takes a long time or doesn’t print at all

When your printer needs a lot of time to do printing (from your POV) or doesn’t print at all (some Xerox printers have such problems with gs renderer, so they are working again only with pdftops renderer), you can try to change the default postscript renderer. The default renderer in Fedora for most printers is gs filter from Ghostscript, but we have pdftops filter from Poppler for Brother, Minolta and Konica Minolta printers — this setup is called hybrid.

Other available renderer setups are gs (from Ghostscript), pdftops and pdftocairo (from Poppler), mupdf (from mupdf) and acroread (from adobe reader, not in Fedora official repositories), then you can set different default renderer for your print queue like this:

# lpadmin -p <printer-name> -o pdftops-renderer-default=gs/pdftops/pdftocairo/mudpf/acroread/hybrid

BEWARE: Most ‘slow’ printing issues are caused by PDF creating applications, which generates bad PDF file — and that bad generated PDF file is mostly the core of problem. To sum it up, slow printing issue can rise again with different PDF file, then it is on user’s decision: if he wants to print fast and probably sometimes change the default renderer, or slow printing is not such critical issue.

CUPS

[Fixed in F33 and later] Firefox, Evince (PDF viewer), GVim, Gedit, Gnome Control Center show a ‘dummy’/duplicate print queue, which doesn’t work

This bug is connected to every application which uses GTK print dialog. GTK dialog decided to take information about available from two sources — mDNS messages from Avahi and CUPS — this dummy/duplicate print queue is a print queue GTK created in its dialog based on Avahi messages, but it doesn’t exist in CUPS, because no one created it, and later GTK behaves like it exists in CUPS. So every time an user wants to print, GTK sends a request to CUPS for this queue, but it gets dropped by CUPS because the queue doesn’t exist.

The feature which GTK is trying to do here is called CUPS temporary queues — GTK developers is currently working on a immediate fix in this bugzilla. The future plan is to use cpdb-backend-cups backend in GTK, but right now we are focusing on the intermediate fix.

CUPS doesn’t take nicely some kinds of FQDN

CUPS sometimes has problems with some kinds of FQDN — that means when you use FQDN in ‘BrowsePoll’ directive in /etc/cups/cups-browsed.conf, CUPS doesn’t recognize it as valid hostname — it is solved by adding:

ServerAlias your.own.fully.qualified.hostname.com

into /etc/cups/client.conf and restarting cups service.

[F33+] Printing via IPPS doesn’t work

Fedora 33 came up with a raised bar regarding crypto-policies, so SSL and older TLS protocols are disabled on system level. The change breaks printing via IPPS to devices which don’t support newer protocols. You can set back legacy crypto support in crypto-policies via:

$ sudo update-crypto-policies --set DEFAULT:FEDORA32

The policy change transitionally has an impact on devices found by cups-browsed, because the daemon prefers IPPS uris if they are reported as available by printer/server.

HPLIP

First I would like to mention that we are not responsible for support HPLIP, which is downloaded and installed from HP website. Please install hplip rpms from official Fedora repositories at most cases.

Hp-plugin: file does not match its checksum. File may have been corrupted or altered

This common error is mostly caused by external causes (server outage, network outage), when wget tries to download plugin, but it returns only error message. It is connected with message:

Plugin download failed with error code = N

where N is return value of wget (man wget), which is used for downloading proprietary plugin. Solutions for this issue may vary — you can wait until servers go up again or try to install plugin, which you download manually from http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ (select «Select and install an existing local copy of the plug-in file» during hp-setup or hp-plugin).

Unable to load cupsext

This error can occur when hplip is installed from HP website, or its dependencies are mixed python2 and python3 packages or installed by pip. This is solved by removing all hplip packages (hplip, hplip-gui, hplip-libs, hplip-common, libsane-hpiao) and installing them again all from repositories.

Missing hplip-gui

GUI tools and GUI parts of HP commands are moved to hplip-gui subpackage, because the main package can work without GUI, so the main package is smaller. The outcome of this decision is HP commands need to be run with ‘-i’ option for interactive mode, or hplip-gui subpackage needs to be installed.

Tools, which need to be run with ‘-i’ option for CLI or need to have hplip-gui installed for GUI:

hp-align
hp-clean
hp-colorcal
hp-diagnose_queues
hp-fab
hp-firmware
hp-info
hp-plugin
hp-sendfax
hp-setup
hp-testpage
hp-unload

Tools, which are in hplip-gui:

hp-check
hp-print
hp-systray
hp-toolbox
hp-devicesettings
hp-faxsetup
hp-linefeedcal
hp-makecopies
hp-printsettings
hp-wificonfig

HP printer isn’t discovered, doesn’t print or doesn’t print well

Some HP printers don’t work well with URIs provided by CUPS (dnssd, usb, ipp) or they need proprietary plugin from HP, which cannot be in Fedora because of licensing issues. For such printers please try to run:

hp-setup -i -g

for interactive mode, or:

hp-setup -g

for graphic mode. This command installs HP printers and HP scanners. If you have issue about HP printer/HP scanner, which isn’t discovered, doesn’t print or doesn’t print well, please try to install it by ‘hp-setup’, if it helps. If it doesn’t help, please file a bugzilla, attach output of hp-setup and mention that you tried ‘hp-setup’.

Device which needs plugin does not work after HPLIP update

Devices which need plugin can stop to work after update to newer HPLIP version — it is due the check for plugin version in the code. The check is necessary to prevent inconsitencies when new features in open sourced HPLIP need new proprietary libraries from plugin. To make your printer work again, just download and install plugin again with:

$ hp-plugin -i

Devices which require a binary plugin stopped to work on Fedora Silverblue/CoreOS

Devices which require a HP close source binary plugin need to have plugin installed every time you start/restart your PC by default. HP closed source script installs the plugins into a readonly directories, so the plugins are removed once you start/restart Fedora.
The workaround is to try if your device supports driverless printing and scanning, try hplip-plugin package from RPMFusion or keep installing the plugin everytime you want to print.

HP USB printer/scanner doesn’t work due a conflict on USB port

HPLIP proprietary binary plugins tends to conflict on the USB port where HP device is connected, if the HP device is capable of using IPP over USB and if ipp-usb package is installed. The solution is to remove hplip and have the device being maintained by ipp-usb and sane-airscan, because it provides newer open sourced protocols and you are not limited by problems caused by closed source plugins (needed to be reinstalled every time there is a new HPLIP version, they don’t work stable on Silverblue/CoreOS).

Terminology for printing and scanning

Printing

Print queue

Abstraction unit in CUPS for a printer — it has a device uri, which represents connection to the device, and can exist with classic driver (PPD file from different package) or without (driverless printing).
The entries you see in print dialogs and settings are those print queues. They can be permanent or temporary.

Permanent print queues

The queues with classic driver or driverless print queue which need to be shared further down the network.

Temporary print queues

The queue which don’t need to be installed at all — they show up during print dialog and they disappear once the printing is done successfully. They rely on driverless printing.

Remote CUPS queue

The queue on the different machine, where other cupsd process is running, than on the local machine. They are usually found in enterprise solutions, where printers aren’t in the same network as users or if admin wants a centralized monitoring above all printers.
In such solutions, users set up cups-browsed to install remote CUPS queue as local queues via BrowsePoll directive, or install a specific queue via GNOME. There can be a solution how to redirect mDNS messages which CUPS server advertises to the networks with users, but I haven’t been to setup this correctly yet.

Classic drivers

Those are the binaries and PPD files, which need to be installed for the device to work. This is older way of supporting devices, which will go away in the future.

Driverless printing (wireless/ethernet)

Most of modern devices (2010+) complies to AirPrint, Mopria or IPP Everywhere standard, which means they don’t need a classic driver for being able to print. Those devices have IPP (Internet Printing Protocol) 2.0+ implemented within, are capable to ‘advertise’ themselves via mDNS and they support document formats like PDF, PCLm, JPEG, Apple Raster or PWG Raster.

There are several prerequitises which need to fulfill in OS to have an access to the driverless feature:

• avahi-daemon must run
• there needs to be a ‘.local’ address resolver active — systemd-resolved or nss-mdns
• the device itself must have IPP port (631) and Bonjour/MDNS enabled
• IPP and MDNS need to be enabled in firewall

How does the driverless printing work under the roof (put it simply):

• CUPS sees the printer in mDNS messages via Avahi
• CUPS will find out the printer capabilities via IPP
• if there is a print job, CUPS will set up the filter chain to convert the incoming file into document format which printer understands (Apple Raster, PDF, PWG Raster, PCLm, JPEG)

In case it is needed, PPD file is generated by PPD generator in CUPS or by driverless binary.

One of the features which use driverless printing is CUPS temporary queues.

See manual how to check if your printer is capable of driverless printing.

Printing using a driver

This printing is similar to driverless printing in matter of setting up a filter chain, but:

• it can use limited mDNS and IPP functionality or it doesn’t use them at all
• all information about device capabilities is taken from PPD (Postscript Printer Description) file
• can use a specialized filters and specialized communication with the device (depends on driver)

The downsides of this approach is to rely on 3rd party drivers, you need to always install a permanent queue for it and it will go away in the future.

Printing raw data

No filters are started during this printing, the data are sent as they are to the target. This approach is usually used for printing to label printers, or, in the past, for printing to remote CUPS queue.
The same as classic drivers, this solution is deprecated and it will be removed in the future.

Printer applications

The binaries which provide support for older devices which aren’t capable of complying to driverless standards. The core idea is they will be capable of accepting the old driver and then advertise itself as a device capable of driverless printing. Then the new CUPS will be able to see them and user will be able to print via them as if they were temporary queues.
The currently available printer applications in Fedora are ippeveprinter (a part of CUPS — see cups-printerapp package) and lprint (provides support for devices which requires raw printing — mostly label printers). I’m planning to package PAPPL, the library for creating printer applications, and ps-printer-app, a printer application for printers which support Postscript.

Driverless printing (USB)

Driverless printing has its variant for devices which are connected via USB — it is covered by ‘IPP over USB’ standard. For make it work, you need ‘ipp-usb’ package, which will register the device with Avahi on localhost — then USB device will look as a wireless/ethernet device. The discovery/printing looks the same as with a wireless/ethernet device with driverless support.

See manual how to check for IPP-over-USB.

Scanning

Classic scanning (via hplip and sane-backends)

The classic scanning works via backends, which are binaries for communication with device. There are several backends, usually created by reverse engineering communication between scanner and MS Windows driver. None of classic backends implements a protocol, which is compatible with most devices available.

Driverless scanning

The driverless scanning uses sane-escl (not built in Fedora) and sane-airscan backends for communicating with newer devices. Those newer devices usually support eSCL (based on AirScan protocol by Apple) or WSD (Web Services for Devices by Microsoft), which sane-airscan is able to use.

Regarding USB scanning, it has the same requirement as printing. The device must support IPP over USB and ‘ipp-usb’ package must be installed to get driverless scanning via USB.

Useful tricks

How to find out whether my printer is capable of driverless printing?

• look for AirPrint among device specification
• Officially certified printers for IPP Everywhere
• check manual for enabling CUPS temporary queues — if your printer is seen in the end in CUPS commands that way, your printer is capable of driverless printing
• [USB devices only] check for IPP over USB (manual here).

How to find out my multifunction device or standalone scanner is capable of driverless scanning?

• check the device specification and look for eSCL/AirScan/WSD — if any of these are mentioned, the device is capable of driverless scanning
• most devices which advertise they can do AirPrint are capable of AirScan too
• [USB devices only] check for IPP over USB (manual here).

How to find out if my USB device supports IPP over USB

Check whether your USB device has a following text in lsusb -v output:

...
      bInterfaceClass         7 Printer
      bInterfaceSubClass      1 Printer
      bInterfaceProtocol      4 
      iInterface              0 
...

If the device has the bInterfaceClass 7, bInterfaceSubClass 1 and bInterfaceProtocol 4 in the sequence, it supports IPP over USB which is critical for USB device driverless printing and scanning.

How to install a print queue

The answer is you don’t have to install at all 🙂 if your device is new enough, is in your local network or is an USB device, has IPP/AirPrint/mDNS enabled and your avahi-daemon is running, CUPS is able to create a temporary queue for you right away in the print dialog, print via it and remove it after successful printing. But there are still use cases when permanent installation is needed like sharing a print queue, different print queue defaults or printer being in different subnet, so I will cover a permanent instalation too.

How to setup CUPS temporary queues with network printer

If your printer is capable of AirPrint, IPP and MDNS is enabled in your printer and printer , then to get CUPS temporary queues working you need:

• have avahi-daemon running:

$ sudo systemctl start avahi-daemon

• have cups.socket enabled and running running:

$ sudo systemctl enable cups.socket
$ sudo systemctl start cups.socket

• enable IPP and MDNS in your firewall settings

After this the temporary queue will appear in the print dialog and you don’t need to install a specific print queue unless you have a reason for it.

You can check if your printer is seen in mDNS messages by (avahi-tools must be installed):

$ avahi-browse -avrt
...
= enp0s25 IPv4 HP LaserJet M1536dnf MFP (42307C)             _ipp._tcp            local
   hostname = [NPI42307C.local]
   address = [192.168.1.10]
   port = [631]
   txt = ["UUID=434e4239-4243-4a42-5859-3c4a9242307c" "Scan=T" "Duplex=T" "Color=F" "note=" "adminurl=http://NPI42307C.local." "priority=10" "product=(HP LaserJet M1536dnf MFP)" "ty=HP LaserJet M1536dnf MFP" "URF=CP99,W8,OB10,PQ3-4-5,DM1,IS1-4,MT1-2-3-5,MT1-2-3-5,RS600" "rp=ipp/printer" "pdl=application/postscript,application/vnd.hp-PCL,application/vnd.hp-PCLXL,application/pdf,image/urf" "qtotal=1" "txtvers=1"]
...

and if CUPS or its backends see the printer by commands:

(lists all existing print queues — permanent or temporary)

$ lpstat -e
HP_LaserJet_M1536dnf_MFP_42307C_

or

(lists all devices, which CUPS sees in the local network or USB)

$ lpinfo -l -v
...
Device: uri = ipp://HP%20LaserJet%20M1536dnf%20MFP%20(42307C)._ipp._tcp.local/
        class = network
        info = HP LaserJet M1536dnf MFP (driverless)
        make-and-model = HP LaserJet M1536dnf MFP
        device-id = MFG:HP;MDL:LaserJet M1536dnf MFP;CMD:PDF,PS,PCL,AppleRaster,URF;
        location = 
...

How to setup CUPS temporary queues with USB printer

USB printers have only one additional prerequisite, installing ipp-usb, which will transform IPP over USB devices to network printer on localhost:

$ sudo dnf -y install ipp-usb

Then you can follow the steps in manual for network printers.

How to install a permanent print queue

1) via CUPS web UI

• start cups.service

$ sudo systemctl start cups

• go to localhost:631 in your browser, and select ‘Administration’ tab
• click on ‘Add printer’ and follow the dialogs

2) via CLI commands

• you will need a device uri — <device_uri>, f.e.:

$ lpinfo -l -v
...
Device: uri = ipp://HP%20LaserJet%20M1536dnf%20MFP%20(42307C)._ipp._tcp.local/
              ================================================================

and a driver name — <driver>, f.e.:

$ lpinfo -m
....
everywhere IPP Everywhere
==========
...

$ lpadmin -p <name> -v <device_uri> -m <driver> -E

where <device_uri> and <driver> are underscored strings from previous commands and <name> is a print queue name, which is chosen by you.

How to install a scanner

Scanners in Linux don’t have to be installed the same way as printers are if they are in the same network or connected via USB — you just need sane-backends to be installed and any scanning application will communicate with scanner/multifunction device via the backend which supports the scanner.

However, the older HP scanners and multifunction devices require an additional package — hplip — and its binary plugins downloaded via hp-plugin -i if they aren’t supported by sane-backends already.

How to make driverless scanning to work

For LAN located and USB devices:

• have avahi-daemon enabled and running

$ sudo systemctl enable avahi-daemon
$ sudo systemctl start avahi-daemon

• enable MDNS in firewall
• [USB devices only] install ipp-usb

For network scanners in a different network:

• set the scanner device uri in /etc/sane.d/airscan.conf — see:

man sane-airscan

How to setup mDNS with systemd-resolved

systemd-resolved is enabled and running by default since F33 and can be setup to work with Avahi on mDNS support which CUPS needs — Avahi does the advertising, registering and sharing devices, and resolved will handle ‘.local’ address resolution. It will work with following steps:

• put ‘MulticastDNS=resolve’ into /etc/systemd/resolved.conf

$ sudo systemctl restart systemd-resolved
$ sudo nmcli connection modify <connection_name> connection.mdns yes connection.llmnr yes
$ sudo systemctl restart NetworkManager

How to compress files

Example:

$ tar -czvf cups-information.tar.gz /etc/cups cups.logs troubleshoot.txt lpinfo.log

Restarting cups service

You restart cups service with:

sudo systemctl restart cups.service