Re-verified that it builds now fine on all arches for Xenial. I took a Xenial VM Guest and also pre-verified that
0. on a correct (manual) trigger I'd see in udevadm monitor the root hub and the device to show up as event => ok, working 1. on install of the old nut-server package there is no trigger => issue confirmed, no trigger 2. on install of the new SRU there is the trigger that would fix up permissions on install as intended => now working correctly re-emitting the events (and only usb events) I'm moving that into the test steps, as it allows one wirthout special HW to *somewhat* test he SRU. ** Description changed: [Impact] - * Installing nut provides rules to set up the devnodes accordingly, but - on an install the trigger to run those is missed to be executed due to - an error in postinst. + * Installing nut provides rules to set up the devnodes accordingly, but + on an install the trigger to run those is missed to be executed due to + an error in postinst. - * Fix is a backport from Debian repo - (https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/id=d31c6dcb) , which works in artful already + * Fix is a backport from Debian repo + (https://anonscm.debian.org/cgit/collab-maint/nut.git/commit/id=d31c6dcb) , which works in artful already [Test Case] - * Plug in a usb controlled UPS of your choice - * Install nut-server - * The device node created should be mode 664 and group "nut", but it is - not. - * Install the proposed package with the fix - * that should trigger the rules to run and it should now be created with - proper permissions. + * Plug in a usb controlled UPS of your choice + * Install nut-server + * The device node created should be mode 664 and group "nut", but it is + not. + * Install the proposed package with the fix + * that should trigger the rules to run and it should now be created with + proper permissions. + + * In the lack of special HW there is a fallback + * Create a VM and give it some USB device + * Start in one console "sudo udevadm monitor" + * On installing the nut-server package the USB events should be re-triggered, but they are not yet today - with the fixed package they are. [Regression Potential] - * The postinst trigger never worked, now it will work. If on a system the - rules fail to execute there might be an issue, but since the are only - triggered (async udev) the install will not fail due to that. I think - in the worst case they are just still not executed. - * Vice versa once they are executed correctly the changed permission - could be an issue for odd setups that relied on the broken permission, - but I explained in the Regression potential section of bug 1099947 that - is released together why I think that is no issue. + * The postinst trigger never worked, now it will work. If on a system the + rules fail to execute there might be an issue, but since the are only + triggered (async udev) the install will not fail due to that. I think + in the worst case they are just still not executed. + * Vice versa once they are executed correctly the changed permission + could be an issue for odd setups that relied on the broken permission, + but I explained in the Regression potential section of bug 1099947 that + is released together why I think that is no issue. [Other Info] - - * n/a + + * n/a ---- 1) $ lsb_release -rd Description: Ubuntu 14.04.3 LTS Release: 14.04 2) nut-server: 2.7.1-1ubuntu1; udev: 204-5ubuntu20.15 3) On a fresh install of Ubuntu 14.04 (amd64), I installed the nut- server package while the UPS was already connected via USB. After installation, the permissions described by /lib/udev/rules.d/52-nut- usbups.rules should have changed the group of the corresponding /dev/bus/usb/*/* node to 'nut'. 4) The owner/group for the /dev/bus/usb node remained root:root. Manually running 'udevadm trigger --subsystem-match=usb --action=change' changed the group to 'nut'. (From past experience tracking down related udev+nut bugs, unplugging and re-plugging the USB cable would yield similar results.) However, that udevadm command is included in the postinst for nut- server, and it is guarded with a pidof check for 'udevd': # ask udev to check for new udev rules [ -x /etc/init.d/udev ] && pidof udevd > /dev/null \ && udevadm trigger --subsystem-match=usb --action=change This most likely needs to be amended to include the current process name, 'systemd-udevd'. I checked the control files, and unless the udevd process name has changed back, I believe this will affect vivid, wily and xenial as well as trusty. (I will let someone else add those later tags if that turns out to be the case.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1540008 Title: USB permissions not set at install time (udevd name changed?) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nut/+bug/1540008/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
