Description of problem: After the October 16 CUPS update, neither my HP Deskjet 5650 nor my Officejet 6110 would print until after each had been deleted and re-installed in system-config-printer. The HP Device Manager indicated both printers were there, and idle. It showed in status where the job had been accepted and completed a few seconds later, with no printing done. However, under the device control tab the job was still there, with the printer "stopped." Once the printers were deleted and re-installed, each worked normally. Reproducible: Steps to Reproduce:
Please try to reproduce this. Make an archive of the contents of /etc/cups (including the subdir ppd) with 2.0.2 when it's working, another after the 2.0.4 update when it's not, and finally again after you re-create the queues. Compare the contents of each and see what changed.
William reported the same problem during testing, but nobody else could reproduce it and it wasn't apparent what was going on. He pasted a log error message at one point complaining about the PPD file for his printer in /etc/cups/ppd, but gave no other information about what changed in /etc/cups through each step.
CC: (none) => wilcal.int
(In reply to David Walser from comment #2) > William reported the same problem during testing, but nobody else could > reproduce it and it wasn't apparent what was going on. He pasted a log > error message at one point complaining about the PPD file for his printer in > /etc/cups/ppd, but gave no other information about what changed in /etc/cups > through each step. I saw a similar message somewhere along the way, but do not recall the exact circumstances.
(In reply to David Walser from comment #1) > Please try to reproduce this. Make an archive of the contents of /etc/cups > (including the subdir ppd) with 2.0.2 when it's working, another after the > 2.0.4 update when it's not, and finally again after you re-create the > queues. Compare the contents of each and see what changed. Both printers are connected to the same computer. I will attempt to do this later today with a 64-bit install on the same computer that is not currently up to date. If that doesn't show the problem, I will need instructions on reverting to cups 2.0.2 on the i586 install that has already been updated.
OK, let me see if I can explain what I'm seeing without confusing the entire issue. My 64-bit install shows the same bug. I have examined /etc/cups/ppd after each step and there is a definite difference. Before the update, /etc/cups/ppd contains two files for each printer. One is labeled xxx.ppd, and the other is labeled xxx.ppd.O. There are some differences between the two. (I will attach copies of each file for the Deskjet 5650.) The update appears to leave these unchanged, though I admit I did not study them closely. After the printer is deleted and re-installed, there is only one file for that printer, xxx.ppd, which at a quick glance appears identical to the old xxx.ppd.O file. The xxx.ppd file from cups 2.0.2 is gone. That's as far as I went. I left the 64-bit install with the Officejet ppd files unchanged from the update, in case there's something else you want me to try.
Sorry about the double post. Bugzilla told me there was an error in saving the first one.
Created attachment 7134 [details] cups 2.0.2 ppd file
Created attachment 7135 [details] cups 2.0.2 ppd.O file
Created attachment 7136 [details] cups 2.0.4 ppd file, after deleting a re-installing printer
Created attachment 7137 [details] cups 2.0.4 ppd file, before deleting and re-installing printer
(In reply to Thomas Andrews from comment #7) > Sorry about the double post. Bugzilla told me there was an error in saving > the first one. I had forgotten about the servers being changed. Switching the platform to "all" because I've seen it on both 32-bhit and 64-bit installs, and to generate an email in case those regarding comments 6-11 weren't forwarded when the servers came back.
Hardware: i586 => All
Same issue with an Officejet-4630 reported in the forum: https://forums.mageia.org/en/viewtopic.php?f=24&t=10355
I'm not sure why re-installing the printer under 2.0.4 would write a PPD file with cupsVersion: 1.5, but I guess the contents of these PPD files aren't the problem. Did you note any differences in the ownership/permissions of the PPD files through the process, or any differences in the .conf files in /etc/cups?
CC: (none) => thierry.vignaud
@David: If you're asking for the forum post, the user already re-installed the printer before he could be asked for comparing cups config before and after the update and so on. I'm posting the relevant parts (at least I think those are the relevabt parts, minus the colord stuff as that should not be a problem) of the journalctl log excerpt he posted: Oct 19 00:29:49 eris udev-configure-printer[5712]: Oct 19 00:28:08 eris cupsd[970]: [Job 131] Job stopped due to filter errors; please consult the error_log file for details. Oct 19 00:29:50 eris colord-sane[5739]: io/hpmud/musb.c 2073: Invalid usb_open: Permission denied Oct 19 00:29:49 eris udev-configure-printer[5712]: add usb-001-004 Oct 19 00:29:49 eris udev-configure-printer[5712]: device devpath is /devices/pci0000:00/0000:00:0a.1/usb1/1-2 Oct 19 00:29:49 eris udev-configure-printer[5712]: MFG:HP MDL:Officejet 4630 series SERN:CN39E1W2QD05Y0 serial:CN39E1W2QD05Y0 Oct 19 00:29:49 eris udev-configure-printer[5712]: CheckAndInstallDrivers() Oct 19 00:29:49 eris udev-configure-printer[5712]: CheckInstalledDrivers() Oct 19 00:29:49 eris udev-configure-printer[5712]: MissingDriver() Oct 19 00:29:49 eris udev-configure-printer[5712]: FAIL HERE Oct 19 00:29:49 eris systemd[1]: configure-printer@usb-001-004.service: main process exited, code=exited, status=1/FAILURE Oct 19 00:29:49 eris systemd[1]: Unit configure-printer@usb-001-004.service entered failed state. Oct 19 00:29:49 eris systemd[1]: configure-printer@usb-001-004.service failed. He also mentioned that there was no information in /var/log/cups/error_log file so not sure how we could check for the reason or which filter exactly caused the jobs to be stopped. But I suspect the lower parts about udev-configure-printer to be the cause for this issue, and not the cups update itself. Also the PPDs alone are probably not of much help. It would probably be best to create a tarball of /etc/cups before and after the update to 2.0.4 and attach it here, it's easier to check via recursive diff.
CC: (none) => doktor5000
Created attachment 7151 [details] /etc/cups before update
Created attachment 7152 [details] /etc/cups after update with printers not working
Created attachment 7153 [details] /etc/cups after update and after re-installing Deskjet 5650 printer
(In reply to David Walser from comment #14) > I'm not sure why re-installing the printer under 2.0.4 would write a PPD > file with cupsVersion: 1.5, but I guess the contents of these PPD files > aren't the problem. Did you note any differences in the > ownership/permissions of the PPD files through the process, or any > differences in the .conf files in /etc/cups? I didn't happen to check the ownership or permissions of the files before the update, so I don't know if they've changed. I tend to doubt it, but I suppose stranger things have happened.
Summary: After October 16 CUPS update, HP printers had to be re-installed => After CUPS 2.0.4 update, HP printers had to be re-installed
I don't see anything obvious in the actual config files that changed that could make the printer working again ... FWIW, the printers.conf.O and the ppd.O files, did you create them manually? Apart from that, another user on the forums was affected. He had 2 HP printers, only one stopped working (laserjet). After he adjusted the permissions on the PPD file by adding read permissions for others the printer started to work again. See https://forums.mageia.org/en/viewtopic.php?p=60061#p60061 permissions before: -rw-r--r-- 1 root sys 23321 Sep 27 11:38 HP-Deskjet-3510-series.ppd -rw-r----- 1 root sys 11063 Sep 27 12:32 HP_LaserJet_Professional_P_1102w.ppd permissions after chmod o+r -rw-r--r-- 1 root sys 23321 Sep 27 11:38 HP-Deskjet-3510-series.ppd -rw-r--r-- 1 root sys 11063 Sep 27 12:32 HP_LaserJet_Professional_P_1102w.ppd He did not do anything more other then fixing the permissions, no need to remove and reconfigure the printer. I don't think it would hurt to simply add this to the cups %post scripts ? We already have a fix for group ownership in there, I'd simply add chmod -R o+r /etc/cups/ppd after that. Objections?
(In reply to Florian Hubold from comment #20) > I don't think it would hurt to simply add this to the cups %post scripts ? > We already have a fix for group ownership in there, I'd simply add > > chmod -R o+r /etc/cups/ppd > > after that. Objections? Added via http://svnweb.mageia.org/packages?view=revision&revision=893075 and submitted cups-2.0.4-1.2.mga5 but seems the buildsystem is currently borked somehow. see mail on dev and sysadmin-discuss mls.
I'd certainly like for this issue to be fixed, and maybe we just have to go with the %post thing, but rather than adding a hack to fix breakage elsewhere, it would be nice to know what's messing up the permissions in the first place. Also, it may be that this fix will only work temporarily and something will still mess up the permissions again. We should find the source of the issue. Also, the .O files are created by CUPS. It sometimes rewrites some of the files, and it backs up the old ones to .O.
Well, sadly I don't have a printer to test. But one could use inotifywatch or the audit subsystem to watch /etc/cups/ppd directory on what's happening there. But seems this is an upstream issue, see https://www.cups.org/str.php?L4703 or https://lists.debian.org/debian-printing/2015/09/msg00009.html or also https://answers.launchpad.net/hplip/+question/259568 Additionally we might also need the fix from https://www.cups.org/str.php?L4725 for ipp:// printers which seems to fix an issue with printing from chromium/chrome. But the proper upstream patch is still missing there. I've submitted a new candidate with the upstream fix http://svnweb.mageia.org/packages?view=revision&revision=893090 as cups-2.0.4-1.3.mga5 and now the buildsystem is also working again.
URL: (none) => https://www.cups.org/str.php?L4703
(In reply to Florian Hubold from comment #20) > I don't see anything obvious in the actual config files that changed that > could make the printer working again ... FWIW, the printers.conf.O and the > ppd.O files, did you create them manually? > I did not. They were just "there." > > Apart from that, another user on the forums was affected. He had 2 HP > printers, only one stopped working (laserjet). After he adjusted the > permissions on the PPD file by adding read permissions for others the > printer started to work again. Confirmed. I used Dolphin to look at the permissions of the various ppd files. The file created when I re-installed the 5650 reported that Others "Can Read" it, while the file for the 6110, which had not been re-installed, reported that it was "Forbidden" to Others. The 6110 worked again after changing the permissions.
This morning I took my Dell Dimension E310 computer that had not been updated in a while, and de-activated the update repositories. I then installed cups-pdf and my HP Officejet 6110, using cups 2.0.2. Two ppd files were created, one for each printer, each with read permissions for others. I then re-activated the update repositories, and got the updates, including not only cups 2.0.4, but also the systemd and hplip updates, and others. I examined /etc/cups/ppd before the suggested reboot. A new ppd file for the HP computer had been written, forbidden to others, and the old one had been saved with a ".O" suffix. The one for the cups-pdf printer was unchanged.
(In reply to Thomas Andrews from comment #25) > This morning I took my Dell Dimension E310 computer that had not been > updated in a while, and de-activated the update repositories. I then > installed cups-pdf and my HP Officejet 6110, using cups 2.0.2. > > Two ppd files were created, one for each printer, each with read permissions > for others. I then re-activated the update repositories, and got the > updates, including not only cups 2.0.4, but also the systemd and hplip > updates, and others. > > I examined /etc/cups/ppd before the suggested reboot. A new ppd file for the > HP computer had been written, forbidden to others, and the old one had been > saved with a ".O" suffix. The one for the cups-pdf printer was unchanged. Does the cups in updates_testing fix it?
(In reply to David Walser from comment #26) > > Does the cups in updates_testing fix it? Yes. A test print of a small text file worked perfectly.
Florian, is this ready to go to QA then, or do you have another fix pending?
In VirtualBox, M5, KDE, 32-bit Package(s) under test: cups cups-common libcups2 cups-filesystem Install CUPS, reboot system. default install of cups cups-common libcups2 cups-filesystem [root@localhost wilcal]# urpmi cups Package cups-2.0.4-1.1.mga5.i586 is already installed [root@localhost wilcal]# urpmi cups-common Package cups-common-2.0.4-1.1.mga5.i586 is already installed [root@localhost wilcal]# urpmi libcups2 Package libcups2-2.0.4-1.1.mga5.i586 is already installed [root@localhost wilcal]# urpmi cups-filesystem Package cups-filesystem-2.0.4-1.1.mga5.noarch is already installed Cups works locally and over the LAN. install cups cups-common libcups2 cups-filesystem from updates_testing [root@localhost wilcal]# urpmi cups Package cups-2.0.4-1.3.mga5.i586 is already installed [root@localhost wilcal]# urpmi cups-common Package cups-common-2.0.4-1.3.mga5.i586 is already installed [root@localhost wilcal]# urpmi libcups2 Package libcups2-2.0.4-1.3.mga5.i586 is already installed [root@localhost wilcal]# urpmi cups-filesystem Package cups-filesystem-2.0.4-1.3.mga5.noarch is already installed Cups works locally and over the LAN No need to re-instal the printer.
In VirtualBox, M5, KDE, 64-bit Package(s) under test: cups cups-common lib64cups2 cups-filesystem Install CUPS, reboot system. default install of cups cups-common lib64cups2 cups-filesystem [root@localhost wilcal]# urpmi cups Package cups-2.0.4-1.1.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi cups-common Package cups-common-2.0.4-1.1.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi lib64cups2 Package lib64cups2-2.0.4-1.1.mga5.x86_64 is already installed [root@localhost wilcal]# urpmi cups-filesystem Package cups-filesystem-2.0.4-1.1.mga5.noarch is already installed Cups works locally and over the LAN. install cups cups-common lib64cups2 cups-filesystem from updates_testing [root@localhost wilcal]# urpmi cups Package cups-2.0.4-1.3.mga5.i586 is already installed [root@localhost wilcal]# urpmi cups-common Package cups-common-2.0.4-1.3.mga5.i586 is already installed [root@localhost wilcal]# urpmi lib64cups2 Package libcups2-2.0.4-1.3.mga5.i586 is already installed [root@localhost wilcal]# urpmi cups-filesystem Package cups-filesystem-2.0.4-1.3.mga5.noarch is already installed Cups works locally and over the LAN No need to re-instal the printer.
Note that after the install of the CUPS system it is necessary to reboot the system otherwise the HP Device Manager does not see the printer.
(In reply to David Walser from comment #28) > Florian, is this ready to go to QA then, or do you have another fix pending? Well yes, at least the fix for the permissions for the PPDs is in. I'm not sure if the chmod fix should stay in, but I think cups itself will probably not fix the permissions of the PPDs if the read permissions for others is missing. Also we should still add the proper upstream fix for https://www.cups.org/str.php?L4725 - that's why I've asked you about webgit for cups, as the fix seems to have been applied, but I didn't get around to search for it in a git checkout. I've whipped together some advisory for the current state, hopefully that will suffice. If there are still issues, please reassign to me, and I'll try to have a look. Suggested advisory: ======================== With the security update to cups 2.0.4, cups changed the internal handling of PPD files, so that the same permissions for configuration files are applied to PPD files. This caused issues with some HP printers, and required users to delete and reinstall their printers. This update fixes that issue. References: https://bugs.mageia.org/show_bug.cgi?id=16971 https://www.cups.org/str.php?L4703 ======================== Updated packages in core/updates_testing: ======================== i586 cups-common-2.0.4-1.3.mga5.i586 cups-2.0.4-1.3.mga5.i586 libcups2-devel-2.0.4-1.3.mga5.i586 libcups2-2.0.4-1.3.mga5.i586 x86_64 lib64cups2-devel-2.0.4-1.3.mga5.x86_64 cups-2.0.4-1.3.mga5.x86_64 lib64cups2-2.0.4-1.3.mga5.x86_64 cups-common-2.0.4-1.3.mga5.x86_64 Source RPMs: cups-2.0.4-1.3.mga5.src.rpm
Status: NEW => ASSIGNEDAssignee: bugsquad => qa-bugs
Thanks Florian! Just a small advisory fix, 2.0.4 was just a bugfix update, not security. Suggested advisory: ======================== With the update to cups 2.0.4, cups changed the internal handling of PPD files, such that the same permissions for configuration files are applied to PPD files. This caused issues with some HP printers, which required users to delete and reinstall their printers. This update fixes that issue. References: https://bugs.mageia.org/show_bug.cgi?id=16971 https://www.cups.org/str.php?L4703
FWIW, my observations are that it isn't so much that the permissions were changed, as it was that the newly-written ppd files had the wrong ones. Sorry, but I failed to mention that the ppd.O backup files retained the correct permissions. Also, it doesn't look like the update rewrote the ppd file for the cups-pdf "printer," as there was no ppd.O file. That observation makes me wonder if any ppd file that happened to be rewritten by the update would show the bug, not just those for HP printers. Is there any evidence that ppd files for any other printers are being rewritten? Unfortunately, I don't have any physical printers that aren't HP. so I have no way to test that hypothesis.
(In reply to David Walser from comment #33) > Thanks Florian! > > Just a small advisory fix, 2.0.4 was just a bugfix update, not security. > > Suggested advisory: > ======================== > > With the update to cups 2.0.4, cups changed the internal handling of PPD > files, > such that the same permissions for configuration files are applied to PPD > files. This caused issues with some HP printers, which required users to > delete > and reinstall their printers. This update fixes that issue. > > References: > https://bugs.mageia.org/show_bug.cgi?id=16971 > https://www.cups.org/str.php?L4703 Looks like it works to me.
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED
installed i586 packages usb connected canon printer still operates -ok
CC: (none) => westel
(In reply to ben mcmonagle from comment #36) > installed i586 packages > > usb connected canon printer still operates -ok I am curious, Ben. Did the cups update create a new ppd file for your printer? (Evidenced by the presence of a ppd.O file for that printer.) Working on a vague theory expressed in Comment #34.
@Thomas: Why did you resolve the bug, the update wasn't pushed yet?
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
reassigning to QA
Status: REOPENED => ASSIGNED
(In reply to Florian Hubold from comment #38) > @Thomas: Why did you resolve the bug, the update wasn't pushed yet? Misunderstood David Walser's request via the QA mailing list, I guess.
Adding the OK's as two people have already confirmed the update is good. Please remember to add the OK's when you test things.
Whiteboard: (none) => MGA5-64-OK MGA5-32-OK
Validating this update
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
advisory uploaded
CC: (none) => tmbWhiteboard: MGA5-64-OK MGA5-32-OK => MGA5-64-OK MGA5-32-OK advisory
An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2015-0162.html