You are not logged in.
I have blacklisted, actually install /bin/false, the usblp kernel module. Without it, hplip had difficulties to communicate with my printer.
The log has:
Oct 07 22:04:02 systemd[1]: Reached target Printer.
Oct 07 22:04:02 systemd-udevd[1364]: Error running install command for usblpI wonder if the Printer target tries to load usblp. The reason for asking is that usblp interferes with libusb: see Conflict with usblp. I think there were attempts to eliminate the interferences, at list at the application level, so that blacklisting usblp will not be necessary. Again, see Conflict with usblp. I wonder if systemd Printer target take those attempts into consideration.
Last edited by regid (2018-10-08 09:25:56)
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline
No see `systemd cat printer.target` targets are in general just synchronization points see `man 5 systemd.target`.
Oct 07 22:04:02 systemd-udevd[1364]: Error running install command for usblpThis seems to indicate systemd-udevd triggered the attempt to load usblp.
Offline
In short, no.
/usr/lib/udev/rules.d/99-systemd.rules:SUBSYSTEM=="printer", TAG+="systemd", ENV{SYSTEMD_WANTS}+="printer.target"it just happens at the same time that udev wants the printer.target and the usblp module.
Offline
If I hadn't explicitly prevented usblp from loading, it gets loaded. After which, hplip can not further communicate with the printer. Which prevents cups, lpinfo -v, from identifying the printer. As you know, archlinux had to downgrade hplip because there were lots of problems with a newer, > 1:3.18.6-1, version. I suspect this usblp issue is another place where newer hplip versions and archlinux don't cooperate.
Last edited by regid (2018-10-08 16:40:25)
powerofforreboot.efi (AUR): Utilities to be used from within a UEFI boot manager or shell.
Offline