Description of problem: When you try to download photos from Canon 350D camera with gphoto2 or with the Gnome "Camera Import" tool, you get an "Operation not permitted" / "Could not claim USB device" error. This worked two weeks ago. Version-Release number of selected component (if applicable): udev-113-12.fc7 pam-0.99.7.1-5.1.fc7 How reproducible: always Steps to Reproduce: 1. connect a Canon 350D camera 2. either wait the Import Photos tool to pop up 3. click on Import Photos Actual results: An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Operation not permitted). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device. Expected results: Photos should be displayed and imported. Additional info: When you run gphoto2, you get the same error. I'm also attaching the gphoto2 debug log and strace output. Looking at strace output, I noticed that gphoto2 tries to open /dev/bus/usb/002/007 in RDWR mode. This file is owned by root, and not writeable by the currently logged in user. Looking at /etc/security/console.perms.d/50-default.perms, it seems that the device must be accessible via /dev/usb/dc2xx* in order for PAM to change ownership to the console user. For the Canon 350D, this can be achieved by putting the following in a file in /etc/udev/rules.d: SYSFS{idVendor}=="04a9", SYSFS{idProduct}=="30ef", SYMLINK+="usb/dc2xx-%k"
Created attachment 245881 [details] gphoto2 debug log
Created attachment 245891 [details] gphoto2 strace output
Better place would be /usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi $ rpm -qf /usr/share/hal/fdi/information/20thirdparty/10-camera-libgphoto2.fdi gphoto2-2.4.0-3.fc8
The Canon 350D is already listed in 10-camera-libgphoto2.fdi, with the correct vendor_id 1193 and product_id 12527.
I am seeing the same problem with a Canon Powershot A80 USB camera that has reliably worked with F7 until a recent update. gphoto detects the camera fine but throws the error opening the USB device as a normal user logged in via X on the console: [psj@localhost ~]$ gphoto2 --debug --auto-detect --summary <snip> 2.333519 gphoto2-port(2): Opening USB port... 2.334004 gphoto2-port(0): Could not query kernel driver of device. 2.334103 gphoto2-port(0): Could not claim interface 0 (Operation not permitted). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device. 2.334232 context(0): An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Operation not permitted). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device. *** Error *** An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Operation not permitted). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device. *** Error (-53: 'Could not claim the USB device') *** Package versions: udev-115-5.20071012git.fc7 kernel-2.6.23.1-10.fc7 gphoto2-2.3.1-5.fc7
Looks like another recent USB camera permissions issue in bug #365281 - related?
Possibly also related to bug #239250 ? Historic report but same error in similar circumstances reported for a number of USB cameras.
Booting to the previous kernel (kernel-2.6.22.9-91.fc7) from kernel-2.6.23.1-10.fc7 allowed normal operation again for me. See also bug #365891.
can you please do: # ls -lR /dev/ > /tmp/kernel-$(uname -r)-dev.txt with both kernels and diff the output? # diff -u /tmp/kernel-*-dev.txt and post the output of diff here?
sry, "ls -lR" will not work. please use: # ls -ZR /dev/ > /tmp/kernel-$(uname -r)-dev.txt # diff -u /tmp/kernel-*-dev.txt
--- /tmp/kernel-2.6.22.9-91.fc7-dev.txt 2007-11-05 12:34:36.000000000 -0500 +++ /tmp/kernel-2.6.23.1-10.fc7-dev.txt 2007-11-05 12:30:06.000000000 -0500 @@ -20,6 +20,14 @@ crw-rw-rw- root root full crw-rw---- root fuse fuse crw------- root root hpet +crw-rw---- root uucp hvc0 +crw-rw---- root uucp hvc1 +crw-rw---- root uucp hvc2 +crw-rw---- root uucp hvc3 +crw-rw---- root uucp hvc4 +crw-rw---- root uucp hvc5 +crw-rw---- root uucp hvc6 +crw-rw---- root uucp hvc7 prw------- root root initctl drwxr-xr-x root root input crw------- root root kmsg @@ -180,6 +188,9 @@ lrwxrwxrwx root root usbdev2.1_ep81 lrwxrwxrwx root root usbdev2.4_ep00 lrwxrwxrwx root root usbdev2.4_ep81 +crw------- root root usbmon0 +crw------- root root usbmon1 +crw------- root root usbmon2 lrwxrwxrwx root root vbi crw-rw----+ craig root vbi0 crw------- vcsa tty vcs
can you diff the output of "gphoto2 --debug --auto-detect --summary" also please?
You may want to test an udev update also: # yum --enablerepo=updates-testing update udev
Created attachment 249351 [details] diff of devices under the two kernels The udev package from testing didn't change anything. Here's the diff of the devices with the camera actually plugged in this time (sorry about that).
Created attachment 249361 [details] gphoto autodetect output under 2.6.22.9-91.fc7
Created attachment 249381 [details] gphoto autodetect output for 2.6.23.1-10.fc7
Something changed in usbdevfs.. snipped from a strace - as a end user: ioctl(9, USBDEVFS_CONNECTINFO, 0xbfc89984) = -1 ENOTTY (Inappropriate ioctl for device) ioctl(9, USBDEVFS_CONNECTINFO, 0xbfc89984) = -1 ENOTTY (Inappropriate ioctl for device) ioctl(8, USBDEVFS_GETDRIVER, 0xbfc8b074) = -1 EPERM (Operation not permitted) ioctl(8, USBDEVFS_CLAIMINTERFACE, 0xbfc8b194) = -1 EPERM (Operation not permitted) ioctl(8, USBDEVFS_RELEASEINTERFACE, 0xbfc8cc04) = -1 EPERM (Operation not permitted whereas root is allowed to do this. kernel is Linux beeble.homelinux.net 2.6.23.1-10.fc7 #1 SMP Fri Oct 19 15:39:08 EDT 2007 i686 i686 i386 GNU/Linux
FWIW this is still happening in kernel-2.6.23.1-21.fc7.
Created attachment 251201 [details] hal-device list for 2.6.23.1-10.fc7
Created attachment 251221 [details] hal-device list for 2.6.22.9-91.fc7
hal shows the USBRAW device is missing in 2.6.23..
re comment #17 .. which files does the ioctl touch?
(In reply to comment #22) > re comment #17 .. which files does the ioctl touch? under 2.6.22.9-91.. crw-rw-r--+ 1 root root 189, 516 2007-11-07 21:00 /dev/bus/usb/005/005 under 2.6.23.1: crw-r--r-- 1 root root 189, 520 2007-11-08 09:06 /dev/bus/usb/005/009
So: crw-rw-r--+ vs. crw-r--r-- The acl isn't being set to allow user access? Worth comparing "getfacl" output?
hald is supposed to be setting the ACL/permissions, and it's not even trying under 2.6.23.1 from what I can see.
I found the problem. Please re-compile the kernel with the option: config USB_DEVICE_CLASS bool "USB device class-devices (DEPRECATED)" depends on USB default y ---help--- Userspace access to USB devices is granted by device-nodes exported directly from the usbdev in sysfs. Old versions of the driver core and udev needed additional class devices to export device nodes. These additional devices are difficult to handle in userspace, if information about USB interfaces must be available. One device contains the device node, the other device contains the interface data. Both devices are at the same level in sysfs (siblings) and one can't access the other. The device node created directly by the usb device is the parent device of the interface and therefore easily accessible from the interface event. This option provides backward compatibility for libusb device nodes (lsusb) when usbfs is not used, and the following udev rule doesn't exist: SUBSYSTEM=="usb", ACTION=="add", ENV{DEVTYPE}=="usb_device", \ NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0644" It appears to have been turned off.. Without this, Fedora 7 doesn't work properly. In 2.6.22, the /sys/bus/usb/devices/5-4.4.1 has: drwxr-xr-x 3 root root 0 2007-11-08 23:40 5-4.4.1:1.0 -r--r--r-- 1 root root 4096 2007-11-08 23:40 bcdDevice -rw-r--r-- 1 root root 4096 2007-11-08 23:40 bConfigurationValue -r--r--r-- 1 root root 4096 2007-11-08 23:40 bDeviceClass -r--r--r-- 1 root root 4096 2007-11-08 23:40 bDeviceProtocol -r--r--r-- 1 root root 4096 2007-11-08 23:40 bDeviceSubClass -r--r--r-- 1 root root 4096 2007-11-08 23:40 bmAttributes -r--r--r-- 1 root root 4096 2007-11-08 23:40 bMaxPacketSize0 -r--r--r-- 1 root root 4096 2007-11-08 23:40 bMaxPower -r--r--r-- 1 root root 4096 2007-11-08 23:40 bNumConfigurations -r--r--r-- 1 root root 4096 2007-11-08 23:40 bNumInterfaces lrwxrwxrwx 1 root root 0 2007-11-08 23:40 bus -> ../../../. ./../../../bus/usb -r--r--r-- 1 root root 4096 2007-11-08 23:40 busnum -r--r--r-- 1 root root 4096 2007-11-08 23:40 configuration -r--r--r-- 1 root root 4096 2007-11-08 23:40 dev -r--r--r-- 1 root root 4096 2007-11-08 23:40 devnum lrwxrwxrwx 1 root root 0 2007-11-08 23:40 driver -> ../../. ./../../../../bus/usb/drivers/usb lrwxrwxrwx 1 root root 0 2007-11-08 23:40 ep_00 -> ../../.. /../../../../class/usb_endpoint/usbdev5.8_ep00 -r--r--r-- 1 root root 4096 2007-11-08 23:40 idProduct -r--r--r-- 1 root root 4096 2007-11-08 23:40 idVendor -r--r--r-- 1 root root 4096 2007-11-08 23:40 manufacturer -r--r--r-- 1 root root 4096 2007-11-08 23:40 maxchild drwxr-xr-x 2 root root 0 2007-11-08 23:40 power -r--r--r-- 1 root root 4096 2007-11-08 23:40 product -r--r--r-- 1 root root 4096 2007-11-08 23:40 quirks -r--r--r-- 1 root root 4096 2007-11-08 23:40 speed lrwxrwxrwx 1 root root 0 2007-11-08 23:40 subsystem -> ../. ./../../../../../bus/usb -rw-r--r-- 1 root root 4096 2007-11-08 23:40 uevent lrwxrwxrwx 1 root root 0 2007-11-08 23:40 usb_device:usbdev5.8 -> ../../../../../../../class/usb_device/usbdev5.8 lrwxrwxrwx 1 root root 0 2007-11-08 23:40 usb_endpoint:usbdev5.8_ep00 -> ../../../../../../../class/usb_endpoint/usbdev5.8_ep00 -r--r--r-- 1 root root 4096 2007-11-08 23:40 version Notice the usb_device:usbdev link. In 2.6.23.1, that link is missing. To get that link, the kernel needs USB_DEVICE_CLASS turned on. Searching in the config in the src rpm gives: [tdavis@beeble SOURCES]$ grep USB_DEVICE_CLASS *config kernel-2.6.23.1-i586.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-i686.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-i686-debug.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-i686-PAE.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-i686-PAE-debug.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-i686-xen.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-ia64.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-ia64-xen.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-ppc64.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-ppc64-kdump.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-ppc.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-ppc-smp.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-s390x.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-x86_64.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-x86_64-debug.config:# CONFIG_USB_DEVICE_CLASS is not set kernel-2.6.23.1-x86_64-xen.config:# CONFIG_USB_DEVICE_CLASS is not set which means the usb_device:usbdev symlink is not created.
Or, check and see if HAL has an update that fixes this problem..
I'm seeing this with a Sony camera under KDE (see also #365891 which appears to be a duplicate of this).
*** Bug 365891 has been marked as a duplicate of this bug. ***
Fix in CVS.
*** Bug 395411 has been marked as a duplicate of this bug. ***
*** Bug 371991 has been marked as a duplicate of this bug. ***
Just installed kernel-2.6.23.9-73.fc8, which has USB_DEVICE_CLASS, but it's still no good. Error is: ------------------------------ An error occurred in the io-library ('Could not claim the USB device'): Could not claim interface 0 (Operation not permitted). Make sure no other program or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device. ------------------------------ Canon PowerShot A75. See also bug #397571.
*** Bug 365281 has been marked as a duplicate of this bug. ***
Today I tried with kernel-2.6.23.8-63.fc8 and gphoto2-2.4.0-4.fc8. Strangely enough, the situation changed for the better the first time I connected the camera (i.e. I was able to see the photos on it in gthumb-import), but then returned to previous situation, where it would complain with the same error message. I also noticed that the gthumb-import now pops up twice when the camera is connected. The first time, it displays the familiar error message. The second time is claims there are no photos in the camera.
Here is the really weird bit. My wife was able to use the camera on her notebook (imported photos with no errors), but after that one fluke, it would not work again, not even after a clean boot. Race conditions?
This problem is still present on 2.6.23.8-34.fc7 with both a Canon EOS 350D and a Sony DSC-T7. Manually chmod 666'ing the relevant device node under /dev/bus/usb/xxx/yyy seems to be a workaround.
The other workaround is booting into an older kernel - for example kernel-2.6.21-1.3194.fc7 from the original F7 install media. Comment #30 (26/11/2007) says fix is in CVS. Any idea when this will hit updates-testing Chuck?
That fix in CVS doesn't work for me.
(In reply to comment #39) > That fix in CVS doesn't work for me. ls -l /dev/bus/usb/xxx/yyy of the device along with ls -lR /sys/bus/usb/devices/ directory would be helpful.
ls -l /dev/bus/usb/004/003 crw-rw-r--+ 1 root root 189, 386 2007-12-19 07:38 /dev/bus/usb/004/003 ls -lR /sys/bus/usb/devices/ /sys/bus/usb/devices/: total 0 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 1-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.7/usb1/1-0:1.0 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 2-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2/2-0:1.0 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 3-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.1/usb3/3-0:1.0 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 4-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-0:1.0 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 4-1 -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-1 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 4-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.2/usb4/4-1/4-1:1.0 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 5-0:1.0 -> ../../../devices/pci0000:00/0000:00:1d.3/usb5/5-0:1.0 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 5-1 -> ../../../devices/pci0000:00/0000:00:1d.3/usb5/5-1 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 5-1:1.0 -> ../../../devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 usb1 -> ../../../devices/pci0000:00/0000:00:1d.7/usb1 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 usb2 -> ../../../devices/pci0000:00/0000:00:1d.0/usb2 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 usb3 -> ../../../devices/pci0000:00/0000:00:1d.1/usb3 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 usb4 -> ../../../devices/pci0000:00/0000:00:1d.2/usb4 lrwxrwxrwx 1 root root 0 2007-12-19 07:39 usb5 -> ../../../devices/pci0000:00/0000:00:1d.3/usb5
Well, I just tried 2-6-23.10-51 from koji, on my laptop at home, and it works for me.. there is a 5 to 10 second delay in getting everyone happy, but it worked for me.. Do a 'getfacl /dev/bus/usb/004/003' and see if it lists you; ie: [root@sony-san ~]# getfacl /dev/bus/usb/002/003 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/002/003 # owner: root # group: root user::rw- user:tdavis:rw- group::r-- mask::rw- other::r-- if it does, and it doesn't work, last try - do 'setenforce 0' and see if works.
# getfacl /dev/bus/usb/004/018 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/004/018 # owner: root # group: root user::rw- user:bojan:rw- group::r-- mask::rw- other::r-- I'm not running SELinux on the machines in questionn, so setenforce 0 does not apply.
Latest stable update kernel for F8, 2.6.23.9-85.fc8.i686, still doesn't work here.
Created attachment 290220 [details] Output of "gphoto2 --debug --auto-detect --summary" under kernel-2.6.23.9-85.fc8.i686
kernel-2.6.23.12-52.fc7 from updates-testing fixes this for F7. Before: [psj@localhost ~]$ uname -r 2.6.23.8-34.fc7 [psj@localhost ~]$ ls -ld /dev/bus/usb/002/002 crw-r--r-- 1 root root 189, 129 2007-12-23 14:15 /dev/bus/usb/002/002 [psj@localhost ~]$ getfacl /dev/bus/usb/002/002 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/002/002 # owner: root # group: root user::rw- group::r-- other::r-- After: [psj@localhost ~]$ uname -r 2.6.23.12-52.fc7 [psj@localhost ~]$ ls -ld /dev/bus/usb/002/002 crw-rw-r--+ 1 root root 189, 129 2007-12-23 14:24 /dev/bus/usb/002/002 [psj@localhost ~]$ getfacl /dev/bus/usb/002/002 getfacl: Removing leading '/' from absolute path names # file: dev/bus/usb/002/002 # owner: root # group: root user::rw- user:psj:rw- group::r-- mask::rw- other::r--
On Fedora 8, with kernel 2.6.23.12-99.fc8.i686 (from Koji), the first time the machine boots, the camera import works, although the import dialog is presented twice. However, after hibernate and resume, the same problem with permissions occurs again.
On Fedora 8, my Canon EOS 350D still works with kernel 2.6.23.8-63.fc8. However, when booted with the 2.6.23.9-85.fc8 update, I am unable to import at all.
(In reply to comment #48) > On Fedora 8, my Canon EOS 350D still works with kernel 2.6.23.8-63.fc8. > However, when booted with the 2.6.23.9-85.fc8 update, I am unable to import at all. Not same make/model of camera but I can confirm this behaviour - 2.6.23.9-85.fc8 does not let the import of pictures since it cannot mount it at all.
[tdavis@beeble ~]$ uname -a Linux beeble.homelinux.net 2.6.23.12-52.fc7 #1 SMP Tue Dec 18 21:18:02 EST 2007 i686 i686 i386 GNU/Linux appeared today, and under Fedora 7, gphoto/digikam now works fine for me..
*** Bug 397571 has been marked as a duplicate of this bug. ***
Short intro: I'm a Fedora contributer doing some kernel bug triaging. Can the other reporters / followers of this bug please check if the latest kernel updates fixes things for them too?
kernel _and_ udev please
FC7 kernel 2.6.23.12-52 fixed it for me.
Unless something undocumented in the changelog has been applied to 2.6.23.13-106.fc8, I would think it would give the same result as -99. See comment #47. Any kernel folks know if this has been addressed?
Still not working for me with kernel-2.6.23.9-85.fc8 and udev-118-1.fc8
Ditto comment #56.
FC7 kernel 2.6.23.12-52 also fixed it for me, both for a Canon 350D and the Sony DSC-T7 I reported on in comment #28.
Can you try the kernel at http://koji.fedoraproject.org/koji/buildinfo?buildID=31566 and post results here?
As previously reported, I tried .12-99. I don't see anything in the changelog of the RPM or .13/.14 kernels related to this. Does any kernel person knows if any fixes have been applied that would affect this?
(In reply to comment #60) > As previously reported, I tried .12-99. I don't see anything in the changelog of > the RPM or .13/.14 kernels related to this. Does any kernel person knows if any > fixes have been applied that would affect this? Should have been fixed by this: * Mon Nov 26 2007 Chuck Ebbert <cebbert> 2.6.23.8-64 - Set CONFIG_USB_DEVICE_CLASS (#397571)
(In reply to comment #59) > Can you try the kernel at > http://koji.fedoraproject.org/koji/buildinfo?buildID=31566 and post results here? This (kernel-2.6.23.14-107.fc8) works for me, although after importing the photos I am again asked if I want to import as in comment #47. Hibernation always crashes my computer hard so I can't test that.
The CONFIG_USB_DEVICE_CLASS didn't actually fix the problem here, as I reported before. Any other fixes that are relevant in the latest build?
Latest F8 kernel, 2.6.23.14-107.fc8, still behaves the same.
Although it worked the other day (comment 62), today it failed repeatedly (same kernel). However, if I cancel the first import and attempt it with the second dialog that pops up, it does not generate the error. Rather, it claims that it cannot find any images. Maybe a race condition somewhere? (At first I was concerned that something had become corrupted, but the images were retrieved fine on a windows system)
From the comments, this appears to be fixed on F7 (from comment #46 onwards) but is broken on F8. This bug is against F7. Maybe it could either be changed to F8 - or a related bug opened for F8 and this bug resolved? From comment #43, the F8 issue may be different anyway because the acls look correct - whereas on F7 the acls were wrong until the fix?
Completely agree with comment #65. I can see this on F8 as well, as reported before.
Looks like the Fedora 8 HAL doesn't want CONFIG_USB_DEVICE CLASS set.
Here is another test that results in failure on F8. Fresh boot, connect camera, import photos. All OK. Disconnect the camera, connect again and the permission problem appears. No hibernate required.
(In reply to comment #69) > Here is another test that results in failure on F8. Fresh boot, connect camera, > import photos. All OK. Disconnect the camera, connect again and the permission > problem appears. No hibernate required. Please try 2.6.23.14-123: http://koji.fedoraproject.org/koji/buildinfo?buildID=32986
Behaves the same as -107.
Any chance of getting this fixed in F8?
Still a problem with latest kernel in Koji: 2.6.24.2-7.fc8.
Some new information: I realized today that I've been using the USB hub on the monitor exclusively because it's easier to reach. Two attempts at downloading images were successful using the USB ports on the computer itself. Note that I still get the double prompt problem.
Latest kernel 2.6.24.3-21.fc8 from koji and hal 0.5.10-1.fc8.2 from updates-testing still give the same behaviour. Pretty sure this is not a straightforward "never works" thing, as on first boot I had the above combo give me pictures from my camera. On second boot, I had the permission issue. Both times I was asked to import twice.
Still the same with 2.6.24.4-64.fc8.i686.
This is still a problem in Fedora 9 Preview Live CD.
Fedora 9 update. Although I was previously able to get things to work after a fashion in F8 as per comment #74, it now fails completely. I don't know if this is the same bug. Note that I have switched from x86 in F8 to x86_64 in F9 on the same computer. A new dialog box pops up titled "Unable to mount Canon, Inc. PowerShot A75" with the text "Error initializing camera: -60: Could not lock the device" The gphoto2 "Import Photos" window contains the messsage "No images found" kernel-2.6.25.3-18.fc9.x86_64 gphoto2-2.4.0-10.fc9.x86_64 hal-0.5.11-1.fc9.x86_64 udev-120-5.20080421git.fc9.x86_64 Please let me know if any additional information would be useful.
(In reply to comment #78) > Fedora 9 update. Although I was previously able to get things to work after a > fashion in F8 as per comment #74, it now fails completely. I don't know if this > is the same bug. Note that I have switched from x86 in F8 to x86_64 in F9 on > the same computer. > > A new dialog box pops up titled "Unable to mount Canon, Inc. PowerShot A75" with > the text "Error initializing camera: -60: Could not lock the device" > > The gphoto2 "Import Photos" window contains the messsage "No images found" On Fedora 9 it seems to mount the camera as a disk. Can you check if that is so ? The following steps work for me: 1] Unmount the volume (icon generally on the desktop) that denotes the camera 2] Use gphoto to recognize the camera (as in earlier releases) 3] Import the photos
The instructions from comment #79 do not work for me. This is F9 and Canon PowerShot A75.
The procedure from comment #79 failed with: *** Error (-114: 'OS error in camera communication') *** However, I was able to browse the camera's directories with nautilus and copy the files manually.
Now running Fedora 9 (x86): kernel-2.6.25.11-97.fc9.i686 hal-0.5.11-2.fc9.i386 udev-124-1.fc9.2.i386 gphoto2-2.4.0-10.fc9.i386 Still using a Canon Digital Rebel XT. I see the same behaviour as described in comment #78. The process described in comment #79 does not work for me. However, I can browse the camera's directories with the filemanager.
With kernel 2.6.25.14-69.fc8, I can get pictures off my Canon Rebel Xti (AKA 400D) with no problems. With my Canon A75, I get the double prompt and I had to turn the camera off and on a couple of times before I could access the pictures. With kernel 2.6.26.3-14.fc8 my Xti is recognized but any attempt to retrieve pictures gives me zero-length files. I did not try the A75 on that kernel.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Initial tests on one of my F-10 based notebooks show success with Canon PowerShot A75. It does take a long time for GThumb to start, but that's probably a good thing - I can see the images on the camera just fine. I'll test more and report back.
Tried on my second notebook under F-10 and it worked. Again, GThumb takes a long time to start, but when it does, it can see all images on camera's flash card.
I'm still getting this error on F-10 with Canon 400D.
Sorry, I was wrong, what I was seeing is a different bug. Camera works fine now.
F-10 works with my Canon Digital Rebel XT as well. As commented in #85, it takes a long time for GThumb to start, but once it does come up, it imports the images fine.
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.