Hi Marco,

thank you for reporting the issue!

It would be great if you followed the steps here https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-problems/#_my_printer_doesnt_print_correctly_or_at_all_but_i_can_see_the_printer_in_print_dialog and provided the requested information.

Thank you in advance!


The error you've got is telling us a backend couldn't communicate with the printer - I have to find out the device uri your printer uses, that will tell us more. My suspicion is it uses .local hostname and your .local resolving doesn't work right now...

Created attachment 1886507 [details]
cups_wholw_log

cups_wholw_log

Created attachment 1886508 [details]
lsusb

Hi Dohnal,
it's seems so.
... 
   cupsdProcessIPPRequest: printer-uri uri 'ipp://localhost/printers/Epson-Stylus-SX430'
....
[Client 13] Returning IPP client-error-not-found for Get-Notifications (/printers/) from localhost.

Ok, so it is really connected to mdns resolving - the mdns hostname of your uri "Epson%20Stylus%20SX430._pdl-datastream._tcp.local" gets resolved as "socket://EPSON022C7A.local:9100", which is device uri, not a specific hostname/IP to connect to. CUPS calls there Avahi right off the bat, so the culprit is either nss-mdns, Avahi or systemd-resolved.

Do you have nss-mdns installed or do you use systemd-resolved for .local address resolving (providing you've set this in systemd-resolved and NetworkManager)?

Before I reassign the issue, I would like to have as much as possible amount of logs for nss-mdns/Avahi/systemd-resolved maintainers - would you mind running the following commands and sharing their output here (avahi-browse will need avahi-tools):

$ lpinfo -l -v

$ avahi-browse -avrt

================================================================================

Then I would like to ask you to enable debug logging for avahi-daemon by:

1) $ sudo cp /usr/lib/systemd/system/avahi-daemon.service /etc/systemd/system
2) (add '--debug' at the end of lines ExecStart and ExecReload) to look this way:

ExecStart=/usr/sbin/avahi-daemon -s --debug
ExecReload=/usr/sbin/avahi-daemon -r --debug

3) sudo systemctl daemon-reload && sudo systemctl restart avahi-daemon

and then for systemd-resolved by:

1) $ sudo mkdir /etc/systemd/system/systemd-resolved.service.d/
2) create a .conf file (f.e. debug.conf) in the dir with content:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

3) sudo systemctl daemon-reload && sudo systemctl restart systemd-resolved

, cancel all current jobs by:

$ cancel -a

enable the queue if needed:

$ cupsenable Epson-Stylus-SX430

and then try to print again - now we should have avahi and resolved logs in journal - please get them by:

$ journalctl -u avahi-daemon > avahi_log.txt
$ journactl -u systemd-resolved > resolved_log.txt

and attach it to this bugzilla together with the exact time when you sent the job.


Thank you in advance!

Created attachment 1887266 [details]
lpinfo

Created attachment 1887267 [details]
awahi-browse

Created attachment 1887268 [details]
avahi_log

Created attachment 1887269 [details]
resolved_log

Ok, so since no resolving regarding 'Epson%20Stylus%20SX430._pdl-datastream._tcp.local' hostname seems to happen in resolved log, my guess is that you use the default nss-mdns+Avahi for mDNS resolving (I have hoped Avahi log shows the exact hostname it resolves at the time, but it doesn't seem to be the case - it just tracks there was a resolver object created, so we know some resolving happened).

And I'm able to reproduce with my local dnssd://Officejet%20Pro%208500%20A909a%20%5B43FD8E%5D._pdl-datastream._tcp.local/ - I checked the /etc/nsswitch.conf and it hasn't contained changes for nss-mdns running correctly. nss-mdns changed their RPM scriptlets to use:

%posttrans
authselect enable-feature with-mdns4

but it seems does not work correctly on upgraded machines - probably you need to run 'sudo authselect apply-changes' as well...

Marco, what does your /etc/nsswitch.conf look like?

Once I did:

$ sudo authselect enable-feature with-mdns4
$ sudo authselect apply-changes

CUPS was able to find the printer.

But it would be great if the scriptlet was updated.

Created attachment 1887888 [details]
nsswitch.conf

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.