Bug 678804 - cups doesn't look for /dev/parport0
Summary: cups doesn't look for /dev/parport0
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: cups
Version: 15
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-19 20:24 UTC by Bruno Wolff III
Modified: 2012-01-03 16:56 UTC (History)
9 users (show)

Fixed In Version: cups-1.4.6-17.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-03 09:46:04 UTC
Type: ---
Embargoed:
twaugh: fedora_requires_release_note?


Attachments (Terms of Use)

Description Bruno Wolff III 2011-02-19 20:24:39 UTC
Description of problem:
It seems that udev names parallel ports /dev/parport? now, but cups expects /dev/lp? . I was able to work around this by making a hard link, but either cups or udev should change so that they expect the same names.

Version-Release number of selected component (if applicable):
udev-166-1.fc15.i686
cups-1.4.6-9.fc15.i686


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Tim Waugh 2011-02-21 12:17:12 UTC
/dev/parport* is not the correct device node.  It is for low-level manipulation of the pins.

The correct device node name is /dev/lp*.  Hard-linking to /dev/parport* is not correct.

Comment 2 Harald Hoyer 2011-02-21 12:33:34 UTC
if you really need /dev/lp*, then:

# MAKEDEV /dev/lp
# cp -avr /dev/lp[0-9] /lib/udev/devices/

Comment 3 Harald Hoyer 2011-02-21 12:36:38 UTC
Or use USB :-)

Comment 4 Bruno Wolff III 2011-02-21 12:42:34 UTC
My printer only has a parallel port connection; using USB won't work. There is still a bug here somewhere. Shouldn't udev be making a device for this automatically? If not, do we really expect normal users to be making their own device nodes?

Comment 5 Bruno Wolff III 2011-02-21 14:33:06 UTC
I will note that after doing the above, the device creation is persistent across reboots.

Comment 6 Kay Sievers 2011-02-21 15:12:29 UTC
The issue is unrelated to /dev/parport*.

Udev does not provide any "dead" device nodes anymore by default, also not for /dev/lp*. In the past, these nodes have been used to trigger autoloading of the lp module on device node access.

There are two options, either force-load lp on every bootup by adding a config file to:
  /etc/modules-load.d/
or do create a static device node in /lib/udev/devices/.

The lp module does not support auto-loading/probing out-of-the-box, and udev dropped support/workarounds for _all_ the non-hotplug-aware subsystems. If such hardware is used on recent systems, it requires manual configuration step as described above.

Comment 7 Tim Waugh 2011-02-21 15:20:20 UTC
That explains it, thanks Kay.  I think this just needs mentioning in the release notes.

Comment 8 Bruno Wolff III 2011-02-21 16:00:48 UTC
The release notes should be good enough. It would be nicer to catch this on upgrades or installs, but there are probably few people using parallel ports these days.

Comment 9 Jiri Popelka 2011-04-26 11:26:24 UTC
*** Bug 699052 has been marked as a duplicate of this bug. ***

Comment 10 Tim Waugh 2011-05-18 14:15:01 UTC
Harald, if we want to package device nodes for /dev/lp as part of cups, what's the best way to do that?

Comment 11 Tim Waugh 2011-05-18 15:05:34 UTC
I've added some lp device nodes to cups-1.4.6-17.fc16, FWIW.

Comment 12 Göran Uddeborg 2011-10-02 13:33:52 UTC
> I've added some lp device nodes to cups

That seems to solve the problem, doesn't it?  At least it works for me now with an updated cups. Can't this be closed?  (Maybe changing the component to "cups" first?)

Comment 13 KitchM 2011-12-27 04:31:45 UTC
This problem is experienced in the latest Fedora 16.

Interestingly enough, the install worked perfectly, but the system lost connection to the printer with a printer applet warning popup that says "Printer 'printer name' may not be connected".  It shows this every minute or so.

How can it see the printer during install, but not after?  Sounds like a clear continuing bug in the programming to me.

Should one still have to do the manual config bit?

Comment 14 Tim Waugh 2012-01-03 11:36:18 UTC
KitchM: the problem you are seeing seems to be different: whereas you were able to configure the printer but later saw a communication problem, the original bug reported here was that the communication channel just didn't even exist in the first place.

Could you please report a separate bug so that we can diagnose what's going on?  Thanks.

Comment 15 KitchM 2012-01-03 16:56:19 UTC
Tim Waugh:  Good idea.  Thanks.  I did that.


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