The Monthly Troubleshooter: Installing a Printer
Editor's Note
Recently, I was struck by an interesting idea related to the Linux Gazette. One of the major resources for LG is a mailing list we call The Answer Gang, which is populated by a bunch of sharp folks with a good pool of experience, and who have volunteered to answer Linux-related questions for our readers; what I saw, when I considered the standard TAG activity during an average month, was this powerful collection of knowledge and ability mostly sitting around and idling - something I've never considered a good idea ("ships and men rot in port", as they used to say.) So, in order to remedy the problem, I decided to toss a few pebbles in the pool, disturb the quiet (that's me - always willing to disturb the status quo!), and perhaps add some fun for the Gang and some education and entertainment for our readers; I picked a question on a basic Linux topic and pitched it onto the TAG mailing list with an explanation of what I was trying to do. The result - the first collective TAG article - is presented here for your education and reading pleasure; with luck, there will be more of these in the future. I also hope that you, our readers, will suggest some interesting general topics that we can explore in order to "Make Linux Just a Little More Fun!"
As is often the case with Linux, new hardware installation can be a nearly-automatic task; in fact, your distro of choice may come with the necessary supporting programs already in place, hardware detection may discover your new widget automatically during the boot cycle, and all that may be needed is for you to fire up the appropriate "Wizard" (or some equivalent name in your window manager's menu) and click on a 'Yes, use the Ghilliewillikin 2000' box. However - as with many things in life - everything depends on perspective.
As an example, when seen through a technician's or a sysadmin's eyes, the above scenario never happens (except, perhaps, on their own computers) - since the case I've described above isn't one that users ever call about. No, indeed. The User Freakout Syndrome only sets in when things don't go that way.
However frustrating that perspective may be - at least for those of us who haven't developed the Zen-like calmness necessary to deal with problems while someone is throwing a fit, and perhaps foaming at the mouth and thrashing on the floor in an extremis of self-pity - it contains many lessons worth learning. In this column, The Answer Gang is going to bring their collective experience to the table in order to show you, our readers, the less savory parts of installation and configuration; the dark alleys of hardware and software, if you will. With luck, it will be of use - and perhaps, due to the absence of rug-chewing antics, a source of fun and convenience in smoothing the little bumps on your road to full Linux competence.
Just to warn you, and to apply a bit of braking action to those who would
use this column to "prove" that "Linux is only for experts": everything in
here is, by intention, a description of the worst-case scenarios. The
difference between Linux and outdated legacy OSes is that we have access to
1) information about what goes wrong (i.e., detailed, legible logs) and 2)
the means to change the appropriate configuration, whether it requires
modifying a file in the '/etc' directory, loading the appropriate module,
or even (in extreme cases) patching the kernel. In short, with Linux, you
have the power of choice. Here, we hope to provide a little help -
and make Linux a little more fun - in the process of making that
choice. Enjoy.
-- Ben Okopnik
Printer Selection
If you have not yet bought a printer, and are still considering which one to choose, be sure to take a look at http://linuxprinting.org/suggested.html and to search their database (http://linuxprinting.org/printer_list.cgi?make=Anyone) for a specific printer's rating, before making your final decision. In general, all but the lowest-cost HP and Epson printers are good bets; Lexmark and Canon are not. Also, please do consider supporting this excellent, helpful site by buying your printer and supplies through their affiliate link (http://linuxprinting.org/affiliate.html).
Basic installation: parallel printer
(NOTE: This is applicable no matter what kind of printer you have, since almost all of the troubleshooting steps listed here are common to all the other printer types.)
If you have a simple old-style parallel-port printer, there aren't too many things that can go wrong - at least from the Linux end. Plug it in, connect the parallel cable (while your PC is turned off, please!), and test it by dumping a page or so of text directly to the parallel port device:
ben@Fenrir:~# head -60 /usr/share/dict/words > /dev/lp0
If there's no result from the above - i.e., the printer neither printed anything nor started blinking any indicator lights - check the following:
- 1) Permissions
-
ben@Fenrir:~$ ls -l /dev/lp0 crw-rw---- 1 root lp 6, 0 2004-04-28 23:43 /dev/lp0
The output of the 'ls' command says that 'lp0' is a character device that has 'root' and 'lp' as its owner and group respectively - both of which are allowed to read and write to the device. If issuing the 'head' command, above, resulted in an error like 'bash: lp0: Permission denied', you need to check if you're one of the privileged few allowed to talk to the device - and the 'id' command will show you your group membership. If you're not a member of 'lp', you need to add yourself to it - which will require root privileges - then log out and log back in to make that membership active.
- 2) Module/driver
-
Has your parallel port been made available by your system and your kernel? You may need to check both your BIOS settings and your kernel configuration, to ensure that the port is enabled.
Individual system BIOSes differ so much that a precise description of how to find this setting is impossible. Fortunately, BIOS configuration menus tend to be very simple, with a small number of entries; look through them if nothing else works. As to the kernel, try looking at the loaded modules by executing the 'lsmod' command: if you see the 'lp' module listed, then it's loaded. If not, check to see if it exists on your system:
ben@Fenrir:~# modinfo lp
If the result is 'modinfo: could not find module lp', don't despair: parallel port support may well be built right into your kernel. If that's the case, then you need to make sure that it loaded without any errors:
ben@Fenrir:~$ dmesg|egrep -1 'parport|lp' ACPI: Sleep Button (CM) [SLPB] parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP] lp0: using parport0 (polling). mtrr: 0xa8000000,0x8000000 overlaps existing 0xa8000000,0x4000000
There will be some extraneous messages before and after, but the main thing is that there are no errors. If there are no messages, however, you'll need to recompile your kernel - which is outside the scope of this column, but has been described here in LG a number of times in the past.
At this point, the basic printer test (i.e., dumping text to the device) should be working fine. Install your choice of queue manager (e.g., CUPS, 'lpr', 'lprng', etc.) and the appropriate filters/drivers/definition files for your printer (Gnome-Print, 'hp-ppd', 'linuxprinting.org-ppds', etc.). You're ready to go!
Follow-up TAG Discussion
[Martin Hooper] Just a little note - I have a Deskjet 840C, which is ancient, and a Samsung ML1510 Laser. Both have CUPS printer drivers ready to go in both Gnome and KDE Printer setup.
I would recommend either one!
[Ben Okopnik] Both of these are listed in the "Perfectly [suited for
Linux]" category at the 'printer_list.cgi' link. 
[Kapil Hari Paranjape] Waiting for the second installment. Perhaps entitled "There's many a SLIP between the CUPS and the lp" - sorry, couldn't resist.
Specifically, I think it is for the lack of the second part that clumps of hair can be found on the floor...
Scene: Printer is sitting surrounded by an Amazon Forest's worth of paper while L. User is calmly watching this and System Administrator (who is also a member of "Friends of the Earth" and has contributed to the aforementioned clumps of hair) is dancing around in apoplectic rage.
System Administrator: Why didn't you cancel this print job? The printer has printed one line of garbage on each of a 100 pages!
L. User: Courtesy.
System Administrator: What?
L. User: Well! You know! I saw at once that it wasn't my print job, but I didn't want to stop it in case someone else wanted to print this stuff.
System Administrator: Do you seriously believe that anyone would want this stuff?
L. User: Actually, I would have liked to stop it, but your instructions (points to the wall where instructions to cancel jobs are printed) are just too complicated.
System Administrator: All it needs is for you to press
"Offline-1-2-3-4-Enter"! Anyway, how did you decide that it is not your print job?L. User: Hunh! I gave it an article to print, not this junk!
System Administrator: (visibly controlling his temper) Could you please show me how you did that?
(The two remove off to L. User's office and look at the monitor on L. User's desktop where a terminal window is displaying the command:
lpr article.pdfThere is a moment of silent comtemplation before System Administrator repairs to his office to read part two of this article, while L. User silently complains about how nothing works from the command-line/Linux.)
[Ben Okopnik] After which, he will drag-and-drop the "My Documents" directory on his Wind0ws box onto the printer icon, and fume because it won't print his (currently open in MSWord) documents...
As the Russians say, Gorbatovo mogila ispravit (literally, "Only the grave will cure a hunchback"; the actual meaning/usage is more like "the only permanent cure for a moron is death").
[ [chuckle] Kapil does have a point. The last part of the above article deserves a bit of emphasis, since printing anything other than plain text does require some sort of delegation mechanism. On the other hand, installing a filter kit such as Gnome-Print requires only one 'apt-get'/'rpm'/etc. package installer command; it's just a matter of remembering to do so. -- Ben ]
[Martin Hooper, following up to Kapil]
> (The two remove off to L. User's office and look at the monitor on > L. User's desktop, where a terminal window is displaying the command: > lpr article.pdf
Which, if my understanding of Linux Printing is correct, should just convert to something the printer should understand - right????
[Ben Okopnik] Yep. That would be the point of the filters and the delegations.
ben@Fenrir:~$ apt-cache show magicfilter|perl -wne'print if /^ /' Magicfilter is a customizable, extensible automatic printer filter. It uses its own magic database (a la file(1)) to decide how to print out a given print job.
I used 'lpr' with 'magicfilter' for a long time before CUPS came on the scene - actually, my degree of comfort with the combo was so high that it took me a long time to switch. (I was finally forced to by the fact that CUPS supported a much wider range of printers.) The nice thing about it was that, if some new and strange file format that you wanted to print appeared on the scene, you could write your own processing scripts for it and delegate to them via the filter your printer was using. It was a sensible, essentially self-documenting plaintext format that was very easy to tweak.
[Francis Daly] My recent printer experience:
Laptop, Debian stable, never been near a printer before. Visiting a network with a Mac and printer attached. "snort -dv" shows something that looks suspiciously like an IPP broadcast.
I've heard of "CUPS", so I'll give it a try:
$ apt-cache search cups
Quite a lot of output, but one thing looks likely:
$ sudo apt-get install cupsys-client
Then, I issued:
$ lpstat -h <server_ip> $ echo ServerName <server_ip> >> $HOME/.cupsrc $ lpstat $ lp file_name
-- and it all seems to Just Work. No weeping. No gnashing of teeth.
I'm away from that network now, and so can't test for filters for funky filetypes, but I don't recall doing much more than what is outlined above.
Only wanted to print a plain text file, though. If I ever have a problem trying to get a printer to work, I'll be sure to share the details.
[Martin Hooper] My recent printer experience is much the same as Francis's - most distros will use my printers fine.
Only problem is that if I turn my laser printer (Samsung ML1510) off, then boot Linux, I can't print to it without re-booting.
What would I need to do to get the printer working?
[Thomas Adam] USB? Restarting hotplug ought to fix that in the rare case:
sudo /etc/init.d/hotplug restart... and checking /var/log/messages for any errors/warnings/output, thereafter.
[Karl-Heinz Herrmann] I'm running mostly Postscript-capable printers lately (got cheaper than they used to be), and have rarely had problems getting them to work -- remaining problems are hardware or printers crashing on some nasty PDF-via-acroread files.
On the other hand, getting WinXP to print from inside a NATing VMware was not that intuitive. There is a Samba around, but getting it to recognise the printers didn't work right away. Then I found the following solution:
(in XP)
-> new printer
-> network printer
-> connect to printer on internet and enter:
http://CUPSHOST:631/printers/PRINTERNAME
...which did the trick quite nicely. The VMware-host IP is allowed to print on that particular CUPS, so the NATed VMware-XP can too.
[Neil Youngman, following up to Ben]
> At this point, the basic printer test (i.e., dumping text to the device) > should be working fine. Install your choice of queue manager (e.g., > 'CUPS', 'lpr', 'lprng', etc.) and the appropriate > filters/drivers/definition files for your printer (Gnome-Print, > 'hp-ppd', 'linuxprinting.org-ppds', etc.) You're ready to go!This is where it all went wrong for me. Installing a driver for the Xerox WorkCentre XK35C (not recommended, but...).
First I had to identify the correct driver. I happen to know it should use the Lexmark 5700 driver, but linuxprinting.org is, as stated, the place to look it up.
Next question is, what package is the driver in? I'm on MEPIS, which is Debian-based, so a search on packages.debian.org identifies foomatic-filters-ppds as the correct package.
After 'sudo aptitude install foomatic-filters-ppds', there was still no option for an XK35C or and LM5700, in the CUPS configuration.
What next? I seem to have installed the correct packages, but it isn't working. A few emails to TAG later, I'm back at linuxprinting.org and I find that the PPD file hadn't been installed where CUPS could see it. I located the PPD file with
find / -xdev -iname \*xk35\*
and then I copied it to /usr/share/cups/model/:
root@2[~]# gunzip /usr/share/ppd/linuxprinting.org-gs-builtin/Xerox/Xerox-WorkCentre_XK35c-lex5700.ppd.gz root@2[~]# cp /usr/share/ppd/linuxprinting.org-gs-builtin/Xerox/Xerox-WorkCentre_XK35c-lex5700.ppd /usr/share/cups/model/ root@2[~]# /etc/init.d/cupsys restart Restarting Common Unix Printing System: cupsd.
After that, I was able to configure it from the Web interface.
[Pedro Fraile] Quite a coincidence, but, just as Ben was preparing the article about "Installing a printer", I was in the process of getting the (nearly) latest Gutenprint installed on my box (quite painless, I have to say), and I came across this little piece of information (taken from http://cvs.sourceforge.net/viewcvs.py/gimp-print/print/NEWS?rev=1.279):
<Begin quote>
Welcome to Gutenprint 5.0.0-rc3! Please read these release notes
carefully.
[...]
3) Many Epson printers (specifically, the Epson Stylus Color 740 and
all newer printers) will not respond to ASCII text without a
special "activation" sequence (specifically, this command takes
the printers out of "packet mode"). A brand new printer, or one
that has been connected to a Wind0ws system, may or may not work
in packet mode. Therefore, the common suggestion to test a
printer port by sending plain text to it may not work for these
printers; failure to print in this fashion is not a positive
indication that the printer or the connection is malfunctioning.
These printers are, however, able to print plain text *after* the
activation sequence is sent.
A suggestion would be to first verify that the printer is capable
of returning ink levels. This may be done via
escputil -i -r /dev/lp0
(or whatever device your printer is connected to in place of
/dev/lp0). If this returns status, it demonstrates that the link
between your computer and printer is working.
<End quote>
This was new to me, and thought it could be worth mentioning.
[Ben Okopnik] New to me as well; interesting. The GutenPrint project lists the Epsons that need this hack.
Being the ever-curious bear that I am, I compared the results of "escputil -n -r /tmp/foo" and "escputil -n -u -r /tmp/foo1", and the diff looks like this (non-printable characters encoded by their ASCII abbreviations):
[NUL][NUL][NUL][ESC][SOH]@EJL[SP][SP][SP][SP][SP][NL][ESC]@
I suppose those listed printers could be tested by sending them the above 'activation sequence' preceding the plain text, but it does indeed scotch my "standard test". In other words, folks with Epsons, you have to do a bit of extra work not required of others. I suggest complaining to the guilty parties (Epson).
Talkback: Discuss this article with The Answer Gang
The Answer Gang consists of a group of volunteers at the Linux Gazette. It is the source of the Gazette's tech support columns (The Mailbag, 2-Cent Tips, Talkback, Followups, etc.) as well as the major contributor to our KnowledgeBase. To gather relevant questions to respond to, we run an open mailing list where anyone is welcome to ask their Linux-related questions; we also have a standing invitation for people knowledgeable in Linux to join us.
