Bugzilla – Bug 157055
no resmgr permissions for scanners after update
Last modified: 2006-03-20 15:54:54 UTC
After update from 10.0 to 10.1 there are no resmgr permisions for scanners. Reason: The resmgr config has changed for this kind of permissions. See https://bugzilla.novell.com/show_bug.cgi?id=100695#c3 how it was for 10.0 and see bug #142859 and bug #153705 how it is for 10.1 Easy workaround: Run YaST scanner config which does the 10.1 stuff. Therefore only a MINOR problem. Soultion: Add an appropriate preinstall scipt to the sane RPM which does the following: test if /etc/resmgr.conf.d/50-scanner.conf exists and test if /etc/hal/fdi/policy/10osvendor/80-scanner.fdi does not exist in this case extract the USB ids from /etc/resmgr.conf.d/50-scanner.conf and create new /etc/hal/fdi/policy/10osvendor/80-scanner.fdi and do matching "/sbin/resmgr add ..." calls.
Added postinstall script (because it must run sane-find-scanner to get USB bus and device numbers for the resmgr calls). Submitted package sane to STABLE.
Created attachment 72575 [details] the content of the RPM post-install script regarding this bug Only for information and perhaps for further discussion the content of the post-install script regarding this bug.
For your information: I tested a 10.0 -> 10.1 beta8 update. /etc/hal/fdi/policy/10osvendor/80-scanner.fdi is perfectly created. Nevertheless there are still no resmgr permissions for scanners after update without additional reboot because at package update time the "resmgr add ..." calls fail and in /var/log/YaST2/y2logRPM is: ---------------------------------------------------------------------- 2006-03-20 16:18:03 sane-1.0.17-8.x86_64.rpm installed ok Additional rpm output: warning: /etc/sane.d/dll.conf created as /etc/sane.d/dll.conf.rpmnew Unable to connect to resource manager: Connection refused Unable to connect to resource manager: Connection refused ---------------------------------------------------------------------- There is nothing I can do here (still FIXED as good as possible). The udev -> HAL -> resmgr dependencies are too complicated so that normal users who don't know which services to restart will end up in Windows-like reboots.