Printer doesn't work after reboot

Using openSUSE 11.1 at one client site, the printers are not available after a reboot. We have to go into Yast -> Hardware -> Printers and then select “edit” on any printer and then “save” and all is good (no need to change anything). They are using two parallel port printers (expansion card) lp2/lp3, each connected to an Okidata 320 printer. There is an lp0 detected at boot, but no physical port on the back of the computer.

We are currently limited to 11.1 since the program the clients use only works under Qt3. I have been hired to port it to Java (so we can move beyond Qt3), and to help with customer support. I use TeamViewer to connect to customers’ computers and generally have limited time to work this way. Therefore, I’d like to get as many ideas for which I can look prior to connecting to them.

At first, I though it might be the “lp not loaded at boot anymore” but that didn’t start until 11.4, from what I researched, and they are being detected (lp0, lp2, lp4). We have a few other clients on 11.1 (they are being upgraded from 10.x, slowly) with no printer problem at boot. The hard drive was wiped clean at install, so there is no prior installation problems. No other programs are used on the computer other than our vertical market program, so clean installs are always used to upgrade.

So, other than the lp module loading, where else should I look? I’m thinking maybe some kind of permissions problem, but where to I find the info I need to check this? I am coming up blank on web searches. Any help (sites or info) would be greatly appreciated!

On 2013-09-13 22:06, knathan54 wrote:
>
> Using openSUSE 11.1 at one client site, the printers are not available
> after a reboot. We have to go into Yast -> Hardware -> Printers and then
> select “edit” on any printer and then “save” and all is good (no need to
> change anything).

You might use “lpstat -a” to display the status of all available
printers. And you can do things with “lpadmin” and “lpoptions”. For
example, with another printer I used this to setup the resolution:


lpoptions -p tp0 -o Resolution=360x360dpi

There are some to enable/disable printers, lets see if I can find what
they are. …] Ah, found it. cupsdisable or cupsenable (there are more
commands starting with “cups”). Maybe you can reactivate those stalled
printers with “cupsenable”.

If not, browsing to “localhost:631” displays an interface where you can
restart or disable printers at your wish.

> So, other than the lp module loading, where else should I look?

Logs. /var/log/cups/
With luck you will find something.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Working with legacy distro versions and/or hardware can certainly be challenging. You could check that the parport, parport_pc, ppdev, and lp modules are loaded with

lsmod | grep par

but I suspect (as you already hinted) that this will not be the problem.

I wonder if the CUPS parallel backend is active after a reboot. You could check (following a reboot) with

/usr/sbin/lpinfo -v

Is the parallel backend listed?

deano ferrari wrote:

> Working with legacy distro versions and/or hardware can certainly be
> challenging. You could check that the parport, parport_pc, ppdev, and lp
> modules are loaded with
>

It can also reveal problems. The wife brought home an HP printer that had
wireless. I installed it for her laptop (running 11.4 that I hadn’t gotten
around to updating) and it worked like a charm. I then installed it for my
laptop and the desktop box (both running 12.3) and neither would work,
although both saw the wirelessly connected printer. On a hunch, I followed
the suggestion from the HP device manager to upgrade the hpjis version I had
in 12.3. Went to the hpjis website and installed a later version from there
and both machines worked just fine. Apparently, there was some sort of
regression/error in the hpjis version that 12.3 used and the older one that
11.4 was still using. Try finding THAT error without some help (and luck)!


Will Honea

Yes, unfortunately driver regressions are fairly common. Hence, important to involve one self with beta testing new distro versions where possible.

On 2013-09-14 08:16, deano ferrari wrote:
> Yes, unfortunately driver regressions are fairly common. Hence,
> important to involve one self with beta testing new distro versions
> where possible.

It is a lot of time and effort :frowning:


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

Yes, it is…but I guess it’s the price we pay for free software. :slight_smile:

On 2013-09-14 11:46, deano ferrari wrote:
>
> robin_listas;2584781 Wrote:
>> On 2013-09-14 08:16, deano ferrari wrote:
>>> Yes, unfortunately driver regressions are fairly common. Hence,
>>> important to involve one self with beta testing new distro versions
>>> where possible.
>>
>> It is a lot of time and effort :frowning:

> Yes, it is…but I guess it’s the price we pay for free software. :slight_smile:

I know, I know… I have done a lot of factory testing and reporting,
but not this round.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

deano ferrari wrote:

> Yes, unfortunately driver regressions are fairly common. Hence,
> important to involve one self with beta testing new distro versions
> where possible.
>

Installing a new device in the middle of the release cycle is a different
matter. There, you have no history to fall back on so you are in a cold
trouble shooting mode with no clue about prior performance. FYI, 13.1m4 has
no problem with this printer so only the 12.3 installations got hit.

Ever notice that problems with things like a new printer tend to show up at
the worst possible times - like the night before a presentation where you
REALLY need a printout???


Will Honea

Murphy’s law I guess :slight_smile: I have discovered problems (occasionally) that I had been unaware of until trying to assist a fellow user. That’s always worrying… then the heat is on to resolve the issue for both me and the person I was helping! :confused:

On 2013-09-14 19:34, Will Honea wrote:

> Ever notice that problems with things like a new printer tend to show up at
> the worst possible times - like the night before a presentation where you
> REALLY need a printout???

Absolutely - because we print at the last minute :wink:


Cheers / Saludos,

Carlos E. R.
(from oS 12.3 “Dartmouth” GM (rescate 1))

Typically true. I’ve had similar last-minute experiences with scanning issues too, (often when I simply don’t have the time to be diagnosing the problem - I just want it to work like everyone else)

“lpstat” shows all printers enabled. All the logs look ok, no unusual msgs. localhost:631 shows all printers enabled and accepting jobs.
We’re still working on it, but they’ve been having internet problems which makes it hard for me to login and work on it.

Yes, they were all there, as expected. I was really hoping this would show something! :slight_smile:

I wonder if the CUPS parallel backend is active after a reboot. You could check (following a reboot) with

/usr/sbin/lpinfo -v

Is the parallel backend listed?

I have yet to perform this one right after a reboot. I have been having a lot of problems logging in with TeamViewer lately and believe it’s internet problems on their end…

Yes, they are all loaded.

The output both pre- and post-reboot is identical:

network socketdirect hpfax
direct hp
network http
network ipp
network lpd
direct parallel:/dev/lp0
direct parallel:/dev/lp1
direct parallel:/dev/lp2
direct scsi 

Any other ideas? And thanks, very much, for your (and everyone else’s) help so far!

My next guess is some permission problem on some file that gets fixed when YaST runs, but I have no idea where to even try looking for that…

And lpstat reports all printers ready to accept jobs (after reboot)?

lpstat -a

The printer status should also be recorded in /etc/cups/printers.conf

I don’t think you have a permissions problem (assuming the users are already members of the ‘lp’ group).

The parallel device node

ls -l /dev/lp*

should report something like

crw-rw---- 1 root lp 6, 0 Sep 20 15:13 /dev/lp0
crw-rw---- 1 root lp 6, 1 Sep 20 15:13 /dev/lp1
crw-rw---- 1 root lp 6, 2 Sep 20 15:13 /dev/lp2
crw-rw---- 1 root lp 6, 3 Sep 20 15:13 /dev/lp3

I didn’t check /etc/cups/printers.conf but will check it also.

lpstat -a
DoNotUse not accepting requests since Wed 04 Sep 2013 03:29:31 PM MDT - Rejecting Jobs
lpbuyer1 accepting requests since Fri 30 Aug 2013 08:41:57 AM MDT
lpbuyer2 accepting requests since Tue 20 Aug 2013 11:55:15 AM MDT
lpcheck accepting requests since Fri 30 Aug 2013 08:52:26 AM MDT
lpclerk accepting requests since Wed 25 Sep 2013 11:04:15 AM MDT
lpseller accepting requests since Wed 25 Sep 2013 07:53:14 AM MDT

This is the same output both after boot and after running YaST. The DoNotUse printer is attached to lp0 which has no plug on the back of the computer. Three printers are USB (and they work after reboot), two printers (lpcheck, lpseller) are parallel and on an expansion card. I added the DoNotUse printer as a first step thinking the lp0 with no printer attached was causing a problem.

There’s the problem! After boot:

crw-rw---- 1 root lp 6, 0 2008-12-02 22:56 /dev/lp0

after running YaST and clicking “edit”:

crw-rw---- 1 root lp 6, 0 2008-12-02 22:56 /dev/lp0
crw-rw---- 1 root lp 6, 1 2013-09-25 11:34 /dev/lp1
crw-rw---- 1 root lp 6, 2 2013-09-25 11:34 /dev/lp2 

So, I am guessing that a driver for the expansion card was probably lost during update (since they do a clean install). If that’s the case, I can have them check for make/model and search for it. Or, it might be in the CMOS – it’s been over ten years since I’ve messed with parallel printers! :slight_smile:

If you have any other suggestions, let me know. Thanks, once again, for your invaluable help!

There’s the problem! After boot:

crw-rw---- 1 root lp 6, 0 2008-12-02 22:56 /dev/lp0

after running YaST and clicking “edit”:

crw-rw---- 1 root lp 6, 0 2008-12-02 22:56 /dev/lp0
crw-rw---- 1 root lp 6, 1 2013-09-25 11:34 /dev/lp1
crw-rw---- 1 root lp 6, 2 2013-09-25 11:34 /dev/lp2 

So, I am guessing that a driver for the expansion card was probably lost during update (since they do a clean install). If that’s the case, I can have them check for make/model and search for it. Or, it might be in the CMOS – it’s been over ten years since I’ve messed with parallel printers! :slight_smile:

If you have any other suggestions, let me know. Thanks, once again, for your invaluable help!

That suggests (but I’m not certain) that the parallel backend is not running, or needs to be run (manually perhaps) before the printers are detected. After a reboot, you could try invoking

/usr/lib/cups/backend/parallel

Note what is reported and whether the expected /dev/lp* nodes are now present. If that works, I’d consider adding that command to a startup script.

FWIW, this may (or may not) be relevant to you
Linux Mint Forums • View topic - LX-300+ parallel port

Try to install the package “parallel-printer-support”, if not installed already.
This should automatically create /dev/lp(0-3) nodes on boot.

That package is for openSUSE 11.4 onwards as the static nodes were no longer created by udev. The OP is dealing with machines running 11.1 and indicated in that the lp lp,ppdev,parport_pc modules are being loaded, although they didn’t explicitly convince me of that yet :slight_smile:

lsmod|grep lp