CUPS problem on upgrade from Squeeze to Wheezy
I have a workstation with a Brother_MFC-7362N printer running with CUPS. It was working fine running Debian/Squeeze on i386 but now that I've replaced it with Debian/Wheezy on amd64 it's not working. It says that everything works and claims that jobs are printed but nothing comes out of the printer. Any suggestions on how to debug it? -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
Russell Coker <russell@coker.com.au> wrote:
I have a workstation with a Brother_MFC-7362N printer running with CUPS. It was working fine running Debian/Squeeze on i386 but now that I've replaced it with Debian/Wheezy on amd64 it's not working.
It says that everything works and claims that jobs are printed but nothing comes out of the printer.
Is it a USB interface? The USB handling in Cups was rewritten, apparently, to use internal modules rather than kernel drivers, and the new version did not work with my printer. The bug I reported was just closed late last week, so if what you're experiencing is a similar problem, you could try the version of Cups from Sid. I am not experiencing this issue anymore as I bought an Ethernet switch and connected the printer to it via its Ethernet interface. The result is much faster data transfer to the printer, and I had other motivations for buying the switch anyway.
Jason White wrote:
Russell Coker<russell@coker.com.au> wrote:
I have a workstation with a Brother_MFC-7362N printer running with CUPS. It was working fine running Debian/Squeeze on i386 but now that I've replaced it with Debian/Wheezy on amd64 it's not working.
It says that everything works and claims that jobs are printed but nothing comes out of the printer. Is the printer still where the OS thinks it is ? I am wondering whether this is essentially an OS issue at all; to put it politely' the stability of USB networks, seems highly contingent on circumstance' ....... they are very fragile !. I had the same experience that Jason reported below. A cheap Epson Artisan 725 which frequently had Russell's problem (above) on USB; but which problem seems to have 'largely' gone away, after connecting via a spare Ethernet port on my router. I say 'largely'; because occasionally its IP address seems to change as a result of me adding and subtracting Ethernet cables.So I have just stuck an identical printer on five near by IP addresses,so that on the rare occasion when it doesn't work I consult the printer to see where it thinks it is and use a printer at that address instead. ...............snip
I am not experiencing this issue anymore as I bought an Ethernet switch and connected the printer to it via its Ethernet interface. The result is much faster data transfer to the printer, and I had other motivations for buying the switch anyway.
regards Rohan McLeod
On 9/10/2012 12:20 PM, Rohan McLeod wrote:
I say 'largely'; because occasionally its IP address seems to change as a result of me adding and subtracting Ethernet cables.So I have just stuck an identical printer on five near by IP addresses,so that on the rare occasion when it doesn't work I consult the printer to see where it thinks it is and use a printer at that address instead.
...............snip
Why not have a static IP lease with DHCP ? Using DHCP keeps things easier, just add a fixed lease to whatever is otherwise providing DHCP for your network. Otherwise, if you can set the printer itself up directly with static IP, then that would be better. Are you using an Ethernet print server? If so, that's what you'll need to set a static IP for. Ping it and then do "arp -a" without the quotes so that you can get the MAC address for the DHCP setup. Cheer A.
Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
Why not have a static IP lease with DHCP ?
That's what I do. In /etc/dhcp/dhcpd.conf: host printer { hardware ethernet 00:11:0a:ca:df:68; fixed-address 192.168.0.5; option routers 192.168.0.2; } Replace the addresses to suit your network.
It should also be noted that, if I remember rightly, the URL used by Cups to identify the printer on the USB bus had to be changed in the Cups configuration after the upgrade. Thus in addition to any printer compatibility issues that may arise, it's possible that an old USB configuration is no longer valid and you may in that case have to scan for devices in Cups to obtain the new URL. This is all from memory and it was quite a while ago.
On Tue, 9 Oct 2012, Jason White <jason@jasonjgw.net> wrote:
It should also be noted that, if I remember rightly, the URL used by Cups to identify the printer on the USB bus had to be changed in the Cups configuration after the upgrade. Thus in addition to any printer compatibility issues that may arise, it's possible that an old USB configuration is no longer valid and you may in that case have to scan for devices in Cups to obtain the new URL.
Due to other problems I had deleted the printer and added it again. It was detected automatically so presumably it doesn't have problems in that regard. Anyway if it had the wrong address then the jobs would stay in the queue instead of being reported as complete. I'll try your other suggestion of upgrading to the Unstable version and see how that goes. I don't recall if the printer has an Ethernet port, if so I'll try that next. Thanks for the suggestions. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
On Tue, 9 Oct 2012, Russell Coker <russell@coker.com.au> wrote:
I'll try your other suggestion of upgrading to the Unstable version and see how that goes. I don't recall if the printer has an Ethernet port, if so I'll try that next.
I upgraded cups to the unstable version, but it didn't help. I connected it via Ethernet and used IPP but that didn't help either. D [10/Oct/2012:13:48:33 +1100] [Job 37] /usr/local/Brother/Printer/MFC7362N/lpd/filterMFC7362N: 137: /usr/local/Brother/Printer/MFC7362N/lpd/filterMFC7362N: /usr/local/Brother/Printer/MFC7362N/lpd/rawtobr3: not found D [10/Oct/2012:13:48:33 +1100] PID 5651 (/usr/lib/cups/filter/brlpdwrapperMFC7362N) exited with no errors. I put cups in debug mode. It logged the above errors. Apart from the stupidity of having "not found" (obviously an error) followed by "no errors" there's a problem of the file being supposedly "not found". The file did exist, it's an i386 executable. I installed libc6-i386 and then things started working via Ethernet and IPP. Now I've configured it to use USB again to free up an Ethernet port and that's working well. I'll probably never know if the Wheezy version of cups would have worked correctly. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
participants (4)
-
Andrew McGlashan -
Jason White -
Rohan McLeod -
Russell Coker