[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: usb/cups printer problem after etch upgrade



On Sat, May 12, 2007 at 08:18:10 -0700, Nick Jacobs wrote:
> 
> 
> Florian Kulzer-3 wrote:
> > 
> > As far as I understand udev, it should always use the lowest free lpX
> > node for a new printer.
> > 
> That's just the problem, it doesn't always. If it did that consistently,
> nobody would have had a problem when upgrading from devfs/hotplug. It looks
> to me as though we have "upgraded" from something that was stable and worked
> (despite having some theoretical deficiencies) to something that is
> bug-ridden and unsuitable for general use (despite being theoretically
> wonderful).

I think there are two slightly different issues:

1) Removable devices, such as printers or external storage drives, which
   are not always present and which can be plugged in or switched on in
   changing order. I am not sure if devfs can ensure reserving the same
   device node for each specific device in that case. (I have to admit
   that I hardly know devfs; I started with Linux only after udev was
   the "norm".) Udev provides mechanisms to address this problem by
   generating device symlinks from properties such as volume labels and
   it allows you to specify your own rules on top of that. This is
   complemented by changes in other systems, e.g. CUPS now lets you
   specify the DeviceURI of printers by maker, model and serial number,
   which is independent of the actual lpX or usb/lpX device node.
   Partitions on storage devices can be addressed by labels or UUIDs in
   all important places (e.g. /etc/fstab or GRUB).

2) "Permanent" devices changing device nodes, e.g. different network
   cards in the same computer can alternate between eth0 and eth1. As
   far as I understand it, this is inherent in the new kernels which can
   exhibit changes in the order of loading modules. Udev has
   "persistent" rules which should take care of that by using e.g. the
   MAC address to assign a given ethX node always to the same ethernet
   card. If this automatic mechanism fails it is time to submit a bug
   report. Also, there are enough people on this list who can help you
   with fixing the rules yourself in case of trouble. A special problem
   arises if your system partitions change device nodes, for example due
   to a change in the driver (hdX -> sdY). Using volume labels or UUIDs
   for your bootloader and in fstab can save the day in that case, too.

-- 
Regards,            | http://users.icfo.es/Florian.Kulzer
          Florian   |



Reply to: