Description of problem: I am unable to access my iriver using libifp-1.0.0.2-4.fc6 in user mode. I have found a work-around involving manipulation of the udev entry. Can you verify that this is a good solution and please incorporate it into the next release of this tool. Version-Release number of selected component (if applicable): libifp-1.0.0.2-4.fc6 How reproducible: Always Connect iriver mp3 player and powerup. run ifpline ls as user Steps to Reproduce: 1.Connect iriver mp3 player and powerup. 2.run ifpline ls as user <- will return a message to indicate the unit is busy 3.run ifpline ls as root <- ifpline will display contents of mp3 player Actual results: will return a message to indicate the unit is busy Expected results: as user: ifpline will display contents of mp3 player Additional info: Here is the workaround I created: > mv 10-libifp.rules 52-libifp.rules (gets this file after the 50-udev.rules file change the content of 52-libifp.rules to be the following: #ACTION=="add", SUBSYSTEM=="usb", SYSFS{idVendor}=="4102", SYSFS{idProduct}=="100[135789]", RUN+="/sbin/libifp-hotplug" ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idVendor}=="4102", SYSFS{idProduct}=="100[135789]", OWNER="root", GROUP="ifp", MODE="0760", RUN+="/sbin/libifp-hotplug", OPTIONs="last rule" ACTION=="add", SUBSYSTEM=="usb", SYSFS{idVendor}=="4102", SYSFS{idProduct}=="101[01]", RUN+="/sbin/libifp-hotplug" Note I only changed the first line as I have an IFP-700 series. I would expect that both lines would need to be modified. > Add your userid to unix group ifp. Thoughts?
Thanks for this excellent bug report. I've implemented your ideas, in a slightly different way which should not require you to add yourself to a (new) ifp group. Please try these rpms: http://gauret.free.fr/fichiers/rpms/fedora/libifp-1.0.0.2-5.i386.rpm http://gauret.free.fr/fichiers/rpms/fedora/libifp-devel-1.0.0.2-5.i386.rpm http://gauret.free.fr/fichiers/rpms/fedora/libifp-1.0.0.2-5.src.rpm and tell me if it works for you (I don't own an IRiver). If it's ok, I'll publish them.
Hi Aurelien: ....close I looked at your /etc/security/console.perms.d/60-libifp.perms rules. This iriver device seems to get its identity from /etc/udev/rules.d/50-dev.rules:305 ACTION=="add", SUBSYSTEM=="usb_device", \ PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i $${K%%%%.*} $${K#*.}'", \ NAME="%c", MODE="0644" From what I can tell, this code seems to set permissions or attributes on /proc/usb/{bus}/{device} When I made the proposed changes, it was to override this rule and permit this device to be owned by a particular group and apply group readwrite permissions. Comments? Peter
Unfortunately your fix does not work. I am trying to find the attribute file that gets modified with the changed group id and permissions. The only think I keep seeing are changes in /dev/.udev/db point a class@udev_device it creates as well as an entry /dev/usbdev{bus}.{device}_ep[08][10] I can't see where it stores the permissions for a given device.... sorry.
My objective it to avoid requiring the user to add himself to a group, I think we can do it since the libmtp package does it. Unfortunately I don't own an IRiver so I depend on you for testing. What is the name of the device file which is created when you plug in the IRiver ? Can you try after logging out completely and logging back in (to make sure the new console.perms file is taken into account) ? Thanks
Hello Aurelien: I loaded your fix and rebooted the machine. ifpline had to be run as root to access the device. I added in 52-libifp.rules: #ACTION=="add", SUBSYSTEM=="usb", SYSFS{idVendor}=="4102", SYSFS{idProduct}=="100[135789]", RUN+="/sbin/libifp-hotplug" ACTION=="add", SUBSYSTEM=="usb_device", SYSFS{idVendor}=="4102", SYSFS{idProduct}=="100[135789]", OWNER="root", GROUP="ifp", MODE="0760", RUN+="/sbin/libifp-hotplug", OPTIONS=="last rule" ACTION=="add", SUBSYSTEM=="usb", SYSFS{idVendor}=="4102", SYSFS{idProduct}=="101[01]", RUN+="/sbin/libifp-hotplug" unplugged and replugged in the iriver and was able to get user mode (albeit as a member of the 'ifp' group to work. Thoughts? Peter
I understand it could work by requirering the user to add himself to the 'ifp' group, but I'd like to avoid that if possible. What is the name of the device file created when you plug in the IRiver ? Could you attach a sample of /var/log/messages when you plug it in ? Thanks.
Hi Aurelien: I agree that having to add yourself to a group is not the way I would prefer this to work: Here are the logs from /var/log/message On connection: --------------- Mar 4 08:13:22 gandalf kernel: usb 4-5: new high speed USB device using ehci_hcd and address 8 Mar 4 08:13:22 gandalf kernel: usb 4-5: configuration #1 chosen from 1 choice On Disconnect: ------------- Mar 4 08:14:35 gandalf kernel: usb 4-5: USB disconnect, address 8
Anything else ? Do you know which module gets loaded when you plug in the IFP (lsmod) ? Which device is created when you plug it in (ls -lrt /dev | tail) ?
I just noticed that someone added themselves to the CC list of this bug. Is the bug occuring in a current release of Fedora?
(In reply to comment #9) > I just noticed that someone added themselves to the CC list of this bug. Is the > bug occuring in a current release of Fedora? I do not know, yet. I have an iriver, but it currently uses the usb mass storage device. I plan to flash it and test it, when I am in the mood. I just cc'ed me, to make it more likely not to forget it.
Hi. I haven't played with this problem in some time. I have not flashed my iRiver device, and also not tested this on the latest version of Fedora. In my notes above, I got around this problem by adding my user to the group I created with the USB addition. I've also noticed that Ubuntu uses a technique of using groups to define user rights when users are set up on a Ubuntu system. Currently this issue is not a problem on Ubuntu. This may not align with Fedora's strategy of assigning device ownership to the first logged in user. I wish I could comment further on this. Thanks for keeping this issue alive Peter
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers
This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.