Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. add a new printer usiing a dnssd: url 2. try to print the test page Actual results: You get an unable to late printer error Expected results: the test page should print Additional info:
that should have said unable to locate printer.
I realize this is pre-alpha quality software, but wanted to get this in early because this issue, if it still exists at beta time, should probably block the beta.
Hi Bill, thank you for reporting this issue! Would you mind clarifying how you add a new printer, what url do you use? Anyway, would you mind following steps here https://fedoraproject.org/wiki/How_to_debug_printing_problems and attach the requested archive?
And please add output of following commands into a output file: $ ping <IP of the printer> $ nmap <IP of the printer> $ /usr/lib/cups/backend/snmp $ sudo /usr/lib/cups/backend/dnssd $ /usr/lib/cups/backend/snmp <IP of the printer> $ lpinfo -v $ avahi-browse -a -v -t -r $ avahi-browse -a -v -c -r $ ifconfig $ route
I am away form the location where I have this issue, but I will add what I can and provide the rest of the info probably later on today. The printer was added the way I always have added it. I used the system-config-printer GUI and just took all the defaults, so the URL was that that was created by this utility. I also tried copying a working /etc/cups/printers.conf file from a fedora28 system and that failed with the same error. I will attach the printers.conf file as well as the rest of the information asked for when I get back home.
I should have also mentioned that printing using an IP address seems to work just fine. However, one of my printers seems to have no method of configuring a static IP so printing by IP address on that device would mean redoing the cups config after every power outage.
Created attachment 1475665 [details] My printers.conf file
Created attachment 1475666 [details] Output from commands requested by needinfo
Created attachment 1475667 [details] Output from commands requested by needinfo I guess it would be more useful with the missing packages installed.
Created attachment 1475670 [details] Output from commands requested by needinfo for Office printer Output from requested commands for the "Office" printer. The previous output was for the default "Kitchen" printer.
I should mention neither one works. both have worked for several back versions of fedora configured exactly the same way in cups.
Like I said this is not a problem with printing. I can't print on these printers if i use IP addresses this is an issue with dnssd it does not seem to be able to find the printer IP address from the name.
Thank you for the files! Would you mind attaching cups log when you tried to print the test page (all things you need to do are described in the how to link mentioned above)? I would like to know what CUPS actually says when you try to print.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
Created attachment 1475812 [details] cups daemon log
Created attachment 1475813 [details] cups-broswed log
Hmm and yet another wrinkle in this I updated another external usb drive from fedora28 to rawhide and it does not show this issue. the one that does was installed form rawhide live media. Both should obviously work. I have not been able to ascertain the difference yet.
What cups versions are on both systems?
The system that has the issue was built from a fedora rawhide live image from July 25th.
I already tried disabling firewalld but that did not help
On the upgraded from fedora28 image deleting the printer and re-adding using system-config-printer results in a working printer. I am sort of at a loss here. it seems this is only an issue if you start with a rawhide live image. Both system have been upgraded to latest rawhide and also done a dnf repoquery --extras and downgrading or uninstalling as appropriate. they should be equivalent.
Can you please tell me what cups versions are on both systems? IIUC you have two systems - one with rawhide live image, second with system, which was Fedora 28 and you upgraded it to rawhide. Then if I understood it correctly, please do '$ rpm -q cups' on both systems and show output here. I need to see if their versions differ (because live image can contain older builds - but I'm not so sure about it, I'm not the guy who takes care of live images). If they don't differ, then error can be deeper.
(In reply to Zdenek Dohnal from comment #22) > Can you please tell me what cups versions are on both systems? IIUC you have > two systems - one with rawhide live image, second with system, which was > Fedora 28 and you upgraded it to rawhide. > > Then if I understood it correctly, please do '$ rpm -q cups' on both systems > and show output here. I need to see if their versions differ (because live > image can contain older builds - but I'm not so sure about it, I'm not the > guy who takes care of live images). If they don't differ, then error can be > deeper. OK so this is from the one that was upgraded from fedora28. cups-2.2.8-2.fc29.x86_64
and form the one that does not work. like I said I upgraded form both the fedora28 and the live image install to the latest versions of everything from today and downgraded anything on both versions that had been backed out. both version should be the same so here is from the other version cups-2.2.8-2.fc29.x86_64 looks the same to me as I said it was originally. It is fine if being able to print from upgrading from fedora 28 works but if a fresh install from a live image of fedora29 can not print that is not so good. this might not be a cups issue at all but it would be great if you could find something looking at all the information you asked for to determine where the issue lies.
I see from logs: Aug 14 06:52:02 rawhide.wg9s.com cupsd[2819]: Unable to locate printer \"EPSON050E62.local\". This message comes from dnssd backend, but I'm not sure why the printer doesn't print - all other outputs - like avahi-browse or dnssd finds printer correctly. You can check config file in /etc/cups - maybe you made some changes in the past (on machine which you upgraded to F29), so dnf creates new conf files (with .rpmnew suffix) if there were changes and cups still uses the old ones. But on fresh install you don't have any old configs, so it uses the current ones. That can be one source of different behavior.
OK I figured what is wrong here. the following changed had to be made to /etc/nsswitch.conf and to make it clear I did NOT have to do this on the fedora28 system that was upgraded vie dnf system-upgrade to rawhide. This was only needed to be done on the system that I installed form the rawhide live image. My understanding is this change should have been made by system-config-printer when I added the first printer with a dnssd url. I had to change the line: hosts: files dns myhostname to: hosts: files mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname
OK I figured what is wrong here. The following change had to be made to be made to /etc/nsswitch.conf and to make it clear I did NOT have to do this on the fedora28 system that was upgraded via dnf system-upgrade to rawhide. This was only needed to be done on the system that I installed form the rawhide live image. My understanding is this change should have been made by system-config-printer when I added the first printer with a dnssd url. I had to change the line: hosts: files dns myhostname to: hosts: files mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname
OK I figured what is wrong here. The following change had to be made to /etc/nsswitch.conf and to make it clear I did NOT have to do this on the fedora28 system that was upgraded via dnf system-upgrade to rawhide. This was only needed to be done on the system that I installed from the rawhide live image. My understanding is this change should have been made by system-config-printer when I added the first printer with a dnssd url. I had to change the line: hosts: files dns myhostname to: hosts: files mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostname
Thank you for finding out this one! I found out the option: mdns_minimal [NOTFOUND=return] is added to /etc/nsswitch.conf when when nss-mdns is installed. It was installed by default in F27 and previous Fedoras, but it seems it is no longer installed - and users who upgrades from older Fedoras have still old working config. Currently I'm not sure what dragged nss-mdns to system, because rpm requires are the same on F27 and F28, and CUPS or system-config-printer or other printing packages don't require it. The fix will be adding nss-mdns as Requires of a package - probably CUPS - but I would like to find out why that line isn't there anymore and what change caused it.
My case was different than what you describe. nss-mdns WAS installed, yet the hosts line did not include the above. I backed out my changes to /etc/nsswitch.conf and did a "dnf reinstall nss-mdns" and that correctly added the mdns_minimal [NOTFOUND=return]. The only thing I can think of is that somehow the package was installed too early and /etc/nsswitch.conf was recreated after nss-mdns was installed.
OK I found the real underlying issue here. installing from the rawhide live image resulted in a /etc/nsswitch.conf file that was under control of authselect such that had editing of the files outside of authselect (like what the nss-mdns install does) is subject to being overridden by authselect redoing its saved configuration. I am not sure why this is and if the correct fix is to not allow authselect to control this file or if it is that things like nss-mdns need to see if the file can be edited directly or if it is under control of authselect and do its changes accordingly.
Created attachment 1476421 [details] /etc/nsswitch.conf file if install from rawhide live image
Created attachment 1476422 [details] /etc/nsswitch.conf file if update from fedora28
Created attachment 1476423 [details] output from authselect check on system installed form rawhide live image
authselect check on the system upgraded from fedora28 gets no errors.
This really seems like something outside of printers... maybe authselect maintainer will know more. I'll reassign it to authselect.
There has been lots of comments here and I want to make sure that I understand it correctly. There seems to be two cases - upgrade from F28 to rawhide and direct installation of rawhide through live cd. 1) Upgrade from F28 to rawhide: nsswitch.conf has correct values 2) Direct installation: nsswitch.conf has INcorrect values It this true?
Yes, that is correct
During installation, Anaconda calls "authselect select sssd --force" which *previously* overwrote any changes to nsswitch.conf. This is not called on upgrade. If mdns is pulled as a dependency during packages installation, it makes changes to nsswitch.conf upon installation and these changes are then overwrote by Anaconda authselect call. However, there is a new feature in authselect 1.0 which is already in F28 (testing, waiting to be pushed) and rawhide which should solve this. See [1]. I pushed this version few days after this BZ was created. Please, if possible, retest this with recent rawhide. Additionally, I plan to provide a unified way to package maintainers to modify nsswitch.conf in F30 scope, see [2]. [1] https://github.com/pbrezina/authselect/wiki/Design-Document:-nsswitch.conf-modification [2] https://github.com/pbrezina/authselect/issues/77
Bill, could you please test it with current rawhide?
(In reply to Pavel Březina from comment #40) > Bill, could you please test it with current rawhide? Not sure at all what you are asking here. If you want me to reinstall from a new rawhide to make sure this does not happen, that is too big an ask. I finally have this computer running as expected and have no interest in having to spend another week doing it over again. If you could provide the old script that was run to update nsswitch.conf and the new one I could verify that the change to the script fixes my issue without having to trash my entire fedora installation as you seem to be wanting me to do.
Yes, the test would be to reinstall from current rawhide. It is OK if you are not willing to do it, I fully understand that. I am closing this bug as resolved as it should be fixed per comment #39. Feel free to reopen it if you run into it again.
Sorry, I thought I had cleared the needinfo.