Bug 16139 - Printing does not work after upgrade
Summary: Printing does not work after upgrade
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: LPRng
Version: 7.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact:
URL:
Whiteboard:
: 16323 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-08-14 01:10 UTC by Willem Riede
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-08-20 14:30:51 UTC
Embargoed:


Attachments (Terms of Use)

Description Willem Riede 2000-08-14 01:10:55 UTC
Printing did not work for me after upgrade for two reasons:

1. the lpd service is not started from the init scripts (appropriate Sxxlpd
link missing) even though it was configured to start before the upgrade

2. once the lp deamon was running, print jobs were accepted, but never came
out of the printer (lpstat said they were removed at whatever the time of
submitting the job was). Once I tried a test page from printtool, it
started working, even though printtool did not change /etc/printcap.
Whatever it did change should have been done by the upgrade.

Comment 1 Preston Brown 2000-08-14 16:24:24 UTC
this absolutely must work for 7.0.

Comment 2 Crutcher Dunnavant 2000-08-14 20:15:30 UTC
I cannot reproduce this,
can you give me a reproducable test case?

(and can you tell me if the upgrade replaced printcap? did it leave a
printcap.original, printcap.rpmsave, or printcap.rpmnew file laying arround?)

We are going from a lpd based lpd to an LPRng based lpd, and home tweaked print
entries are probably gonna fall on the floor.

Comment 3 Willem Riede 2000-08-15 00:17:29 UTC
I'm not sure If this provides a reproducable test case, but here is my
pre-upgrade printcap:
----- cut here -----
#
# This printcap is being created with printtool v.3.27
# Any changes made here manually will be lost if printtool
# is run later on.
# The presence of this header means that no printcap
# existed when printtool was run.
#
##PRINTTOOL3## LOCAL ljet4 300x300 letter {} LaserJet4 Default 1
lp:\
	:sd=/var/spool/lpd/lp:\
	:mx#0:\
	:sh:\
	:lp=/dev/lp0:\
	:if=/var/spool/lpd/lp/filter:
##PRINTTOOL3## LOCAL 
hp4l:\
	:sd=/var/spool/lpd/lp0:\
	:mx#0:\
	:sh:\
	:lp=/dev/lp0:
---- cut here ------
It was not changed by the upgrade, nor was a rpmnew or rpmsave generated.

As stated, printtool didn't change it either when it succeeded to get my printer
going, but it must have changed something somewhere...

Comment 4 Tim Waugh 2000-08-18 09:42:48 UTC
I expect the problem was with rhs-printfilters, which doesn't include the
rewindstdin binary that is used by the filter script created in older
distribution versions.  The filters of existing queues aren't upgraded not to
need rewindstdin: perhaps that's a bug in itself?

Comment 5 Crutcher Dunnavant 2000-08-20 14:30:49 UTC
*** Bug 16323 has been marked as a duplicate of this bug. ***

Comment 6 Crutcher Dunnavant 2000-08-20 14:37:40 UTC
Okay, here is the problem, and the fix.

LPRng does not use a stdin connection to the printfilter, it passes it a file
name, so the old filters cannot be made to work. So what do we do? Well, there
is some new magic in the rhs-printfilters package which replaces printfilters in
the spool directorys with symlinks to the rhs-printfilters master-filter IF THEY
ARE IDENTICAL, before the upgrade. printtool should have been making symlinks in
the first place, which it now does. So, if you configured a printer with the
same version of master-filter as the one that is currently on your box AND you
didn't edit either file, then upgrades outmagically work. THis still leaves some
people in the cold, but handles most cases (and is a s smart as we can safely
make it).

Everyone else can reconfigure. There is a nice LONG note about this going in the
Release Notes.



Note You need to log in before you can comment on or make changes to this bug.