Bug#375395: [Pkg-cups-devel] Bug#375395: cupsys: Printer stopped working after upgrade

[Roger Leigh]

Henrique de Moraes Holschuh <hmh at debian.org> writes:

> On Wed, 28 Jun 2006, Roger Leigh wrote:
>> I just installed discover on my i386 test system, and it didn't load
>> lp.  I rebooted it to see what happened at startup, and it didn't load
>> lp then, either.
>
> Please file a bug against discover, it has to auto-detect the need for lp
> and other very common protocol drivers.

OK, I will do.

>> In a way, the fact that we have "lost" the facility to autoload
>> modules when the device node is opened, despite the existence of the
>> hotplug/udev/discover tools, is a usability problem.  A lot of
>
> We never lost it, we just are not doing our job right yet, I think.
>
> 1. We now have proper hardware auto-detection and discovery, but it is not
> quite there yet (discover).  This is fixable, so let's fix it :)
>
> 2. We now have to create the device nodes at runtime or boot-time if we need
> them for kernel module auto-load, but we have not awaken to that fact yet.
>
> I'd like to see a proper fix for both issues. Doing it right in (1) makes
> (2) mostly not needed, and (1) is probably the long-term solution.
>
> I'd fix (2) doing this:
>   1. Write a small <autodetectable driver> -> <protocol driver> table,
>      in a dir.d-style place so that packages can extend it.
>
>   2. Have that table create device inodes or load the protocol driver
>      module when the autodetectable driver is loaded.
>
>   (or do the above using udev scripts, it doesn't really matter).
>
> The udev package itself would be a good place to do (2), I supose.  This is
> different from abusing udev from one or two packages, because we would be
> deploying it as a general solution for an async userspace problem, which IS
> in udev's charter to be an enabler of.
>
> And it does NOT, in any way, shape or form, mean that (1) should not be
> fixed.  Discover is to load "lp", and that's it.
>
> What do you guys think?

I think you are right that discover is where the fix should be.

I'm just pasting below a transcript of a discussion about this on
debian-boot.  Here, Colin Watson proposed that we also add a base
printing package (something like a "printing-base") which installs a
script into /etc/modprobe.d to ensure the lp device is loaded.  It
might do as an interim measure, before discover is fixed, and might be
useful for other device types as well.  This might be a solution to
your part (2) above.


Regards,
Roger


<rleigh> Hi folks.  If it wasn't brought up earlier, is there anything that can be done to prevent bugs like #375395.  The current hotplug/coldplug/discover/udev situation means basic stuff like the "lp" device isn't functional unless the user takes manual steps to set it up; this will be a support nightmare.
<Kamion> rleigh: we could put that in /etc/modules unconditionally
<Kamion> what harm would it do?
<rleigh> It should really only be loaded if the parport layer loaded successfully.
<Kamion> rleigh: IMO you're kind of missing the point about autoloading devices when the device node is opened - the point is that asking for the device node only tells the system that you want the parallel port driver, not necessarily that you want it for lp
<rleigh> Kamion: Don't other parport users get different device nodes and names?  I'll check.
<Kamion> rleigh: not to my knowledge ...
<Kamion> rleigh: note that udev is creating the device node you're accessing based on the existence of a parallel port
<Kamion> if other parport users want different device nodes, they probably don't work
<fjp> rleigh: Can you clone that bug to debian-installer as wishlist with comments from conversation here?
<Kamion> (for comparison, Ubuntu autoloads lp from hw-detect)
<Kamion> (unconditionally)
<rleigh> fjp: Sure.  It's also an upgrade issue in addition to an installer issue, BTW.
<fjp> rleigh: Please CC d-boot when you clone.
<fjp> For upgrade issue, file BR against release-notes so it can be documented.
<Kamion> I also disagree with Henrik; if it's possible for discover to autodetect a printer (which would surprise me, but maybe it is), then it's surely also possible to teach the kernel to do so, and then the kernel could tell udev about it
<Kamion> hardware detection belongs in the kernel
<Kamion> er, not Henrik, Henrique, sorry
<Kamion> anyway, assuming that doesn't get fixed for etch, loading lp unconditionally is better than printers not working
<rleigh> Kamion: I see your point about the device loading.  Since lp is the driver most users will be using, it would make sense to default to that.  You can in fact detect printers using the IEEE-1284 readback, but support is not universal and may be vendor-specific.
<rleigh> It also depends upon the parallel port chipset and a suitable cable being used.
<rleigh> (but could be attempted and used if present.)
<Kamion> BTW, you can get the "only if parport is loaded" effect by putting 'install parport /sbin/modprobe lp; /sbin/modprobe --ignore-install parport' in a file in /etc/modprobe.d/
<Kamion> one possible solution could be for cupsys to do that
<Kamion> although since there are other printing subsystems, that may not be appropriate
<Kamion> er, sorry, 'install parport /sbin/modprobe --ignore-install parport; /sbin/modprobe lp' I guess since lp depends on parport
<Kamion> 'install parport /sbin/modprobe --ignore-install parport $CMDLINE_OPTS && { /sbin/modprobe lp; :; }' <- better still
<rleigh> Kamion: kmuto has currently implemented a workaround where we do attempt to load lp, but this is something we ideally shouldn't be involved with.
<Kamion> compare /etc/modprobe.d/alsa-base which does some of this kind of thing
<Kamion> well, perhaps a printing-base package would make sense for that sort of thing?
<rleigh> Kamion: Perhaps.  I'll bring it up with the other printer daemon maintainer on debian-printing.
<rleigh> That would be quite useful, so systems not printing wouldn't get a useless lp driver.
<Kamion> right
<Kamion> definitely better than the /etc/modules approach, and putting it outside the installer would magically fix upgrades too
<rleigh> Agreed.  Thanks for the suggestion!
<Kamion> np. linux-sound-base is an existing example of a similar package, btw.

-- 
Roger Leigh
                Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-cups-devel/attachments/20060628/bd9a6752/attachment-0001.pgp