Canon Printer Troubleshooting (MF644c)

English Hardware
#1

Hi all.

I’m wondering if anybody has a Canon MF642, MF643 or MF644 class printer working with OpenSUSE?

I am stuck with a MF644c, and while its a decent printer, I cannot for the life of me get it working driver-less or with the ‘official-unofficial’ Canon drivers.

I have tried with Tumbleweed and Leap 15.4.

Starting with the Canon driver RPM (Redhat), installing the file goes as expected. Yast/zypper complains about the package being unsigned and that the ‘libgcrypt’ package is missing. (I believe the later to be a simple packaging naming issue as the correct libgcrypt files are installed and in their expected paths (I’ve also tried installing the specifically named package it complains about and it does not change anything)).

Those two issue aside, package installs, a Canon utility pops up (GUI) and allows registering a USB/Network printer as well as assigning a PPD.

I can then go into Yast Printers and see the installed printer. At this point I know communication has been established because the correct toner levels are displayed.

Printing a test page however, results in a ‘beep’ (completion chime) at the printer, but no physical printout. There are no errors logged in cups, just a completed job. On the printer, I see a successful job logged, however I notice in the job stats it says: 0 (received), 0 (printed).

I booted into the most current Ubuntu Live image, loaded the driver,… and it just works. Printer functions flawless. Annoying. So then I loaded up the latest Fedora Live image… and it also just works. Even more annoying.

I reeeeeeeeaaaaally do not want to be forced to jump ship :frowning: If anybody has a suggestion on where to look, I would greatly appreciate it.

~M

lpstat -t

scheduler is running
no system default destination
device for Canon-MF642C-643C-644C-UFR-II: socket://<ip-removed>
Canon-MF642C-643C-644C-UFR-II accepting requests since Thu 04 May 2023 07:21:31 PM EDT
printer Canon-MF642C-643C-644C-UFR-II is idle.  enabled since Thu 04 May 2023 07:21:31 PM EDT

egrep -i "name|model|filter" /etc/cups/ppd/*

/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*PCFileName: "CNM642ZS.PPD"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*cupsModelNumber: 8073
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*cupsFilter: "application/vnd.cups-raster 0 rastertoufr2"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*ModelName: "Canon MF642C/643C/644C UFR II"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*ShortNickName: "MF642C/643C/644C"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*NickName: "Canon MF642C/643C/644C UFR II"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*%CNGPLPLIBNAMER: "uictlufr2r"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*%CNGPLPLIBNAMERVER: "1.0.0"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*CNOEFLibName: "ufr2filterr"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*CNPrinterName: "Canon MF642C/643C/644C UFR II"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*CNGenericDatName: "Canon Generic Plus BDL CL3"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*CNModelMethod: "1213858060"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*CNModelMethod2: "590"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd:*CNUFR2ModelMethod: "100708352"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*PCFileName: "CNM642ZS.PPD"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*cupsModelNumber: 8073
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*cupsFilter: "application/vnd.cups-raster 0 rastertoufr2"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*ModelName: "Canon MF642C/643C/644C UFR II"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*ShortNickName: "MF642C/643C/644C"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*NickName: "Canon MF642C/643C/644C UFR II"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*%CNGPLPLIBNAMER: "uictlufr2r"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*%CNGPLPLIBNAMERVER: "1.0.0"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*CNOEFLibName: "ufr2filterr"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*CNPrinterName: "Canon MF642C/643C/644C UFR II"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*CNGenericDatName: "Canon Generic Plus BDL CL3"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*CNModelMethod: "1213858060"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*CNModelMethod2: "590"
/etc/cups/ppd/Canon-MF642C-643C-644C-UFR-II.ppd.O:*CNUFR2ModelMethod: "100708352"
#2

Try printing a text file, jpg, and simple pdf file via the lp command eg

lp -d Canon-MF642C-643C-644C-UFR-II /path/to/foo.txt

Do any such files print successfully?

You may need to put CUPS into debug logging for more verbose logging output…

sudo cupsctl debug-logging

After that you can trawl through /var/log/cups/error-log for any filter-related errors that may be evident. However, when a printer silently fails to print, it usually means that the print data being sent is invalid for a given printer.

#3

Thank you, deano_ferrari for your help.

I too believed it was possibly a data format issue, however I discovered with another situation that the printer actually logs an ‘invalid format’ error in its logs when confronted with bad data.

More revealing, the printer log in those cases also shows “1, (received), 0, (printed)”. In my situation above, the log records a successfully processed job, but shows “0, (received), 0, (printed)” - which makes me believe CUPS may not actually be sending any payload at all.

Fails in the same way.

With your debugging suggestion, the resulting error log produced by an attempted ‘lp -d’ command is:

[CUPS_DEBUG-MODE_ERROR-LOG](https://pastebin.com/ZfSPnNAP)

There are some errors recorded within, but they do not look to be the issue. However, I am still trying to read up on CUPS as I am not very familiar with the black magic that is printer interfacing. If anything stands out, any additioanl direction would be appreciated.

~M

#4

The error-log reports the following filters involved with the print job…

D [05/May/2023:20:03:05 -0400] [Job 6] 4 filters for job:
D [05/May/2023:20:03:05 -0400] [Job 6] texttopdf (text/plain to application/pdf, cost 32)
D [05/May/2023:20:03:05 -0400] [Job 6] pdftopdf (application/pdf to application/vnd.cups-pdf, cost 66)
D [05/May/2023:20:03:05 -0400] [Job 6] gstoraster (application/vnd.cups-pdf to application/vnd.cups-raster, cost 99)
D [05/May/2023:20:03:05 -0400] [Job 6] rastertoufr2 (application/vnd.cups-raster to printer/Canon-MF642C-643C-644C-UFR-II, cost 0)

They all complete without error at least…

D [05/May/2023:20:03:05 -0400] [Job 6] PID 1989 (/usr/lib/cups/filter/texttopdf) exited with no errors.
D [05/May/2023:20:03:05 -0400] [Job 6] PID 1990 (/usr/lib/cups/filter/pdftopdf) exited with no errors.

D [05/May/2023:20:03:05 -0400] [Job 6] PID 1991 (/usr/lib/cups/filter/gstoraster) exited with no errors.

D [05/May/2023:20:03:05 -0400] [Job 6] PID 1992 (/usr/lib/cups/filter/rastertoufr2) exited with no errors.

You may need to run the filters manually by hand to examine the output at each stage of the print job process…
https://fedoraproject.org/wiki/How_to_debug_printing_problems#Running_filters_by_hand
You can view the output at each stage (apart from the last printer-specific filter). The first two can be viewed with evince or okular (PDF viewers). The gstoraster output can be viewed with rasterview. That can be obtained via the openSUSE printing repo if required.

#5

Thank you for getting back.

So far I’m not seeing anything obvious to my novice eyes. The first 3 filters work fine. I cannot determine the state of the last.

I did come across this (which it seems you were helping on) describing an issue with a slightly different model using the same driver:

I decided to find a large multi-page PDF and attempt to print it. The result: it tried to print it.

Out of the 100+ pages in the PDF, the printer log reports: ‘18 (received)’, which it attempted to physically print. I also noticed that the first page physically printed actually started at page #5 of the PDF file.

I have not looked through it yet, but this is the error_log for the ‘at least it printed something this time’ print job: https://pastebin.com/JxG0K4rp

~M

#6

That at least confirms any issue is between the last filter and the printer itself. I still wonder if rastertoufr2 is producing output suitable for the printer model you have.

#7

Very strange behaviour. A bug report might be the best way forward here. The error log didn’t show the last filter executing successfully. Were you still in CUPS debugging mode? In any case I don’t think there are any errors occurring from a CUPS job processing perspective. It may be that rastertoufr2 doesn’t like what it is receiving from the prior filter processing.

#8

An experiment that may be worth a shot here. There are two filters capable of performing the PDF to CUPS raster conversion:gstoratser (ghostscript) and pdftoraster (poppler). The former is used by default.

If you do

grep 'toraster' /usr/share/cups/mime/*

you’ll see that gstoraster is preferred because it has the lower cost. You could change that by making pdftoraster have the lower value (eg 98) in the ‘cupsfilters-poppler.convs’ file , and then confirm that it is used in the print filter chain when a print job is generated. I have no idea whether it will help here, but it would be interesting to see if it makes a difference.

Other than that a bug report is probably needed.

#9

Again, thank you for the help.

So changing filter the priority had no impact on the output.

https://pastebin.com/ekEzPWfP
This attempt was with the Yast test-print dialog. Completion beep only at the printer with the log registering 0 (received). I did not try a large multi-paged document.

Also, I loaded up the printing repo and tried cycling through the various (print related) package versions available to see if it made a difference. It did not.

I guess next I’ll see if I can identify what package versions Fedora 38 is using since the same Canon driver works flawlessly over there.

I’m not sure if a big-report should be directed at openSUSE or CUPS…

~M

#10

Perhaps compare

ldd /usr/lib/cups/filter/rastertoufr2

between openSUSE and the working Fedora 38 environment.

#11

This Manjaro post described a user experiencing similar printing symptoms (with the cnrdrvcups driver), and got me wondering about missing libraries. There it was reported that ‘libjbig-shared’ and ‘libjpeg6-turbo’ were missing, and installing them fixed the printing issue.

Focussing on ‘libjbig-shared’ I notice that it provides ‘libjbig.so.0’ based on what is described here…
https://aur.archlinux.org/packages/libjbig-shared
Now, assuming that you have ‘libjbig2’ already installed, I wonder if the following might be sufficient here…

cd /usr/lib64/ ln -s libjbig.so.2.1 libjbig.so.0

#12

Great find on the Manjaro post, that does look like it could be related.

This is the output of ldd:

Tumbleweed:

ldd /usr/lib/cups/filter/rastertoufr2 
        linux-vdso.so.1 (0x00007fff9a1d4000)
        libcups.so.2 => /lib64/libcups.so.2 (0x00007fad2ed6f000)
        libcupsimage.so.2 => /lib64/libcupsimage.so.2 (0x00007fad2ed6a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fad2eb6f000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fad2eb1a000)
        libavahi-common.so.3 => /lib64/libavahi-common.so.3 (0x00007fad2eb0b000)
        libavahi-client.so.3 => /lib64/libavahi-client.so.3 (0x00007fad2eaf8000)
        libgnutls.so.30 => /lib64/libgnutls.so.30 (0x00007fad2e800000)
        libz.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libz.so.1.2.13 (0x00007fad2eade000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fad2e719000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fad2ee3d000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fad2e64a000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fad2eac4000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fad2eabe000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fad2eaaf000)
        libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007fad2ea5c000)
        libjitterentropy.so.3 => /lib64/libjitterentropy.so.3 (0x00007fad2ea53000)
        libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007fad2e51e000)
        libidn2.so.0 => /lib64/libidn2.so.0 (0x00007fad2ea2f000)
        libunistring.so.5 => /lib64/libunistring.so.5 (0x00007fad2e36e000)
        libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007fad2ea18000)
        libnettle.so.8 => /lib64/glibc-hwcaps/x86-64-v3/libnettle.so.8.6 (0x00007fad2e31a000)
        libhogweed.so.6 => /lib64/glibc-hwcaps/x86-64-v3/libhogweed.so.6.6 (0x00007fad2e2d0000)
        libgmp.so.10 => /lib64/libgmp.so.10 (0x00007fad2e22c000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fad2ea0f000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fad2e21a000)
        libcrypto.so.3 => /lib64/glibc-hwcaps/x86-64-v3/libcrypto.so.3.0.8 (0x00007fad2de00000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fad2ddd1000)
        libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007fad2dcf8000)
        libffi.so.8 => /lib64/libffi.so.8 (0x00007fad2dced000)
        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fad2dc46000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007fad2dc3a000)
        libgcrypt.so.20 => /lib64/glibc-hwcaps/x86-64-v3/libgcrypt.so.20.4.2 (0x00007fad2daef000)
        liblzma.so.5 => /lib64/glibc-hwcaps/x86-64-v3/liblzma.so.5.4.2 (0x00007fad2dab6000)
        libzstd.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libzstd.so.1.5.5 (0x00007fad2da09000)
        liblz4.so.1 => /lib64/glibc-hwcaps/x86-64-v3/liblz4.so.1.9.4 (0x00007fad2d9e5000)
        libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007fad2d9bf000)

Fedora 38:

ldd /usr/lib/cups/filter/rastertoufr2
        linux-vdso.so.1 (0x00007fff8fde4000)
        libcups.so.2 => /lib64/libcups.so.2 (0x00007f49ade6a000)
        libcupsimage.so.2 => /lib64/libcupsimage.so.2 (0x00007f49ade65000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f49adc86000)
        libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f49adc30000)
        libavahi-common.so.3 => /lib64/libavahi-common.so.3 (0x00007f49adc21000)
        libavahi-client.so.3 => /lib64/libavahi-client.so.3 (0x00007f49adc0d000)
        libgnutls.so.30 => /lib64/libgnutls.so.30 (0x00007f49ad800000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f49adbf1000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f49adb10000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f49adf29000)
        libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f49ada37000)
        libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f49ad7e8000)
        libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f49ada30000)
        libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f49ad7d8000)
        libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f49ada27000)
        libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007f49ad200000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f49ad7c6000)
        libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007f49ad771000)
        libp11-kit.so.0 => /lib64/libp11-kit.so.0 (0x00007f49ad641000)
        libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f49ad1b3000)
        libunistring.so.5 => /lib64/libunistring.so.5 (0x00007f49ad004000)
        libtasn1.so.6 => /lib64/libtasn1.so.6 (0x00007f49ad62b000)
        libnettle.so.8 => /lib64/libnettle.so.8 (0x00007f49acfb1000)
        libhogweed.so.6 => /lib64/libhogweed.so.6 (0x00007f49acf6e000)
        libgmp.so.10 => /lib64/libgmp.so.10 (0x00007f49acec9000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f49ace9c000)
        libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007f49acdb5000)
        libffi.so.8 => /lib64/libffi.so.8 (0x00007f49acda9000)
        libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f49acbfb000)
        libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007f49acb61000)
        libcap.so.2 => /lib64/libcap.so.2 (0x00007f49acb57000)
        liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f49acb24000)
        libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f49aca6c000)
        liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f49aca4a000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f49aca26000)

I guess I do not understand what ldd shows, as I thought it simply listed the linked libraries required of the queried file, however, the list returned is different on the two distros, despite rastertoufr2 being the same file from the same package.

Regarding the jpeg packages, ( ln -s libjbig.so.2.1 libjbig.so.0 - had no effect), the Canon driver package requires:

libjpeg-turbo
jbigkit-libs

On Fedora 38, I see these packages are providing:

(libjpeg-turbo)
/usr/lib64/libjpeg.so.62
/usr/lib64/libjpeg.so.62.3.0

(jbigkit-libs)
/usr/lib64/libjbig.so.2.1
/usr/lib64/libjbig85.so.2.1

Reviewing what is installed in Tumbleweed I see:

(libjpeg-turbo)
/usr/lib64/libjpeg.so.8
/usr/lib64/libjpeg.so.8.2.2

(libjbig2)
/usr/lib64/libjbig.so.2.1
/usr/lib64/libjbig85.so.2.1

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

!!SOLVED!!

After seeing the above distro discrepancy between libjpeg-turbo packages, I did some searching and found that openSUSE provides libjpeg.so.62 in its own package, separate from libjpeg-turbo: libjpeg62-62.3.0-75.1.

I have installed this additional package, and so far, everything that I have attempted to print has processed successfully.

So for anybody finding this in the future and having issues with the Canon driver package, make sure you have libjpeg62 installed in addition to the stated Canon driver package dependencies.

Again, thank you, deano_ferrari. I would have never made it this far or found this without your help.

~M

#13

Well done. I had noticed that package too, but had not examined what it provided yet. Glad to have helped with the diagnostic path in any case. :slight_smile: