Printing problem
 

I'm not at all sure where this question should go. So I hope this is an acceptable place.

I recently installed SolydX on a desktop machine in a small business network. The network consists of an SME 8 server (gateway, router and web server), an SMS server (file server) and one desktop machine (now running SolydX, was running SalineOS). Since its a computer business, there can be lots of other machines connected, mainly Windows machines.

The network has 4 printers - an HP colour laser (stand alone network connection), an old Epson 24-pin dot matrix (connected to the SME server), a Dymo label printer and a Lexmark Interpret S505 multi-fucntion device. The latter two are connected to the SolydX desktop.

Just about everything seems to work. Well, almost everything. For some reason, any attempt to print from Firefox, Seamonkey, Thunderbird or Chromium fails. Whichever one attempts to start a print job fails instantly. I've tried starting all of them from a terminal in the hopes of seeing some error message, but the only thing I've seen is a "segmentation fault" from Chromium when it fails. Seamonkey, Firefox and Thunderbird just fail silently.

I even installed Konqueror. It will print from the browser menu, but fails to resolve things like javascript controls.

Printing from other applications (such as Evince or LibreOffice) works fine. So I'm at a loss. I don't know if its a network problem, or a problem specific to some library. I've tried to change the default printer from the HP to the Epson, without any change in behaviour.

I've also done some testing with my own laptop, which has several different Linux distributions installed. I've got SolydX installed, which fails in the same way. But, my main distribution is Arch, and from Arch I have no problems printing from Seamonkey, Firefox, Thunderbird or Chromium.

Oh, and the SalineOS install that was on the desktop machine had no problems printing from Firefox or Seamonkey (same versions as installed in SolydX). The difference being the SalineOS is based on what was Debian stable (now badly out of date) and SolydX is based on Debian testing. Both use Xfce.

Anyone else seen problems of this sort? Any suggestions as to how to narrow down the cause of the problem?

Paul.

hi

they have their own forum so post there
http://forums.solydxk.com/

2) go to the cups config page and edit the config for the line that starts "LogLevel" to change from warn to debug

then post your error log to that forum.

3) Of course you could go back and re-configure in case you did not allow yourself to print?
easier to see at the cups page but also visible but harder to see in the file cupsd.conf which is a text file
on debian systems under /etc/cups needs root powers to edit

:) Thanks. I use the SolydXK forum, and had posted the error there also. Only suggestion I had was to check that hplip was installed, which it is.

Thanks. Hadn't thought of that. Unfortunately, it doesn't seem to make any difference. Looks as though the failure is happening before anything gets to cups.

No problem there. Both the desktop and my laptop when I'm there are allowed access to all the network printers. And can print from other applications (such as LibreOffice or evince).

Another odd things is that whatever the problem, it seems to be Debian testing specific. I found another distro that is also based on Debian testing (can't remember the name off-hand), and it has exactly the same problem.

My laptop can print from SolydX in my own home network (I've got a Brother mono laser which is connected to my small home server). I've also discovered that Midori has the same problem when its in the network I described in my first post.

Looking through the Seamonkey crash reports (only recently found out that they produce a web report that makes a lot more sense than the raw reports leaving the machine), the crash always seems to be in libc-2.17. Arch is using libc-2.18, but I doubt I can install a later version of libc in SolydX without breaking lots of things.

What is really annoying is the problem seems to be quite specific to that particular network, and so far I've had no luck isolating the cause.

Paul.