Bug 16139

Summary:	Printing does not work after upgrade
Product:	[Retired] Red Hat Linux	Reporter:	Willem Riede <wriede>
Component:	LPRng	Assignee:	Crutcher Dunnavant <crutcher>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	7.0	CC:	nalin, twaugh
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-08-20 14:30:51 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.