Bug #444670 has turned out to be overrun by SELinux (which does not seem to be the problem), so cloning the original problem here. +++ This bug was initially created as a clone of Bug #444670 +++ Description of problem: When inserting ipod the following is in dmesg: usb 1-5: new high speed USB device using ehci_hcd and address 5 usb 1-5: configuration #1 chosen from 2 choices scsi6 : SCSI emulation for USB Mass Storage devices usb 1-5: New USB device found, idVendor=05ac, idProduct=1209 usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-5: Product: iPod usb 1-5: Manufacturer: Apple usb 1-5: SerialNumber: 000A27001615FDB7 usb-storage: device found at 5 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 6:0:0:0: Direct-Access Apple iPod 1.62 PQ: 0 ANSI: 0 sd 6:0:0:0: [sdc] 39075372 2048-byte hardware sectors (80026 MB) sd 6:0:0:0: [sdc] Write Protect is off sd 6:0:0:0: [sdc] Mode Sense: 68 00 00 08 sd 6:0:0:0: [sdc] Assuming drive cache: write through sd 6:0:0:0: [sdc] 39075372 2048-byte hardware sectors (80026 MB) sd 6:0:0:0: [sdc] Write Protect is off sd 6:0:0:0: [sdc] Mode Sense: 68 00 00 08 sd 6:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 sdc2 sd 6:0:0:0: [sdc] Attached SCSI removable disk sd 6:0:0:0: Attached scsi generic sg3 type 0 SELinux: initialized (dev sdc2, type vfat), uses genfs_contexts Clearly the ipod is detected, but podsleuth outputs: david@localhost:~$ podsleuth --rescan No iPods were found in the HAL device tree Version-Release number of selected component (if applicable): ipod-sharp-0.8.0-4.fc9.x86_64 libipoddevice-0.5.3-4.fc9.x86_64 libipoddevice-0.5.3-4.fc9.i386 podsleuth-0.6.0-5.fc8.x86_64 How reproducible: 100% Steps to Reproduce: 1. install podsleuth 2. reboot (or restart hal) 3. insert ipod 4. run podsleuth command Actual results: No ipod, denied! Expected results: iPod joy Additional info: -- Additional comment from katzj on 2008-04-29 22:20 EST -- Can you grab the output of lshal? -- Additional comment from dev on 2008-04-30 00:30 EST -- I have been able to reproduce this I've actually been meaning to get some more info on this. Out of interest, does your iPod appear on: http://banshee-project.org/files/podsleuth/ipod-model-table ? -- Additional comment from gnomeuser on 2008-04-30 04:00 EST -- Created an attachment (id=304202) lshal output The requested lshal output. My iPod does appear on that list and strangely this used to work earlier in the F9 cycle. -- Additional comment from dev on 2008-04-30 07:44 EST -- (In reply to comment #3) > Created an attachment (id=304202) [edit] > lshal output > > The requested lshal output. Very helpful > > My iPod does appear on that list and strangely this used to work earlier in the > F9 cycle. Compared to my F8 machine, this output is very bland! There *should* be a good 15 odd entries starting with org.podsleuth.ipod with the serial number, colour, model name, capabilities etc. I'm going to test on rawhide in a few minutes. -- Additional comment from gnomeuser on 2008-05-06 06:30 EST -- I am tempted to think this is a dbus/ndesk-dbus issue. Now I don't even get the report back that there are no ipods in the hal tree. I did manage to trick it into telling me that Unhandled Exception: System.Exception: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus) at IManagerProxy.FindDeviceStringMatch (System.String value, System.String ) [0x00000] at Hal.Manager.FindDeviceByStringMatch (System.String key, System.String value) [0x00000] at Hal.Manager.FindDeviceByStringMatchAsDevice (System.String key, System.String value) [0x00000] at PodSleuth.HalFrontend.HalClient.Run (System.String[] args) [0x00000] at PodSleuth.HalFrontend.HalEntry.Main (System.String[] args) [0x00000] I tried backing ndesk-dbus down to 0.6.0 using epoch and explicitly telling podsleuth at compile time to expect the updates in /usr/lib64/podsleuth but had no luck. It does not appear that ndesk-dbus is interfacing with dbus at all.
Update: I took the chance to see if the bug still exists in podsleuth 0.6.1. Sadly it doesn't fix it, but I'll update podsleuth w/ banshee when we have a fix.
the main diff between 0.6.1 and 0.6.0 is upstream enforcing a hardcoded libdir as I recall, that was why I originally just published 0.6.0.
Created attachment 304948 [details] Proposed Patch As per comment on Gnome BZ (http://bugzilla.gnome.org/show_bug.cgi?id=531927): """" I think this is two different problems, but the good news is, I have a fix for the Fedora/Ubuntu problem (it seems). The problem appears to stem from a change in hal-info, in particular the change between releases 20080310 20080313. I noticed this change (http://gitweb.freedesktop.org/?p=hal-info.git;a=commitdiff;h=24ed7559180d02e7e389a09a1e56b7536086181f) and after a bit of experimenting I have come up with a stupid little patch that actually works. """ I'm going to push this fix (with another which I have had planned) sometime within the next 24 hours (although it doesn't really matter with F-9 and Rawhide trees in deep freezes), but it gets a big WFM from me.
I compiled an rpm with your patch, and I can confirm that it fixes the issue (I still have SELinux disabled on this machine). Rescanning device [/org/freedesktop/Hal/devices/volume_uuid_AEF3_A4D0] iPod Found [/org/freedesktop/Hal/devices/volume_uuid_AEF3_A4D0] * Generic Device Properties - Block Device: /dev/sdc2 - Mount Point: /media/DAVIDS IPOD - Read Only: False - Volume Size: 80 GiB * General iPod Properties - Serial Number: 9C6456AYV9P - Firewire ID: 000A27001615FDB7 - Firmware Version: 1.3 - iPod_Control: /iPod_Control - Extra Capabilities: podcast - Production Info: 8170 in november, 2006 from factory 9C * iPod Model Properties - Device Class: video - Generation: 5,5 - Shell Color: white * Image Types Supported - Photos: True - Album Art: True - Chapter Images: True I owe you beer, why didn't I think of the fact that HAL changes constantly breaking for no man.
podsleuth-0.6.0-5.fc9 has been submitted as an update for Fedora 9
(In reply to comment #5) > podsleuth-0.6.0-5.fc9 has been submitted as an update for Fedora 9 Sorry guys, but I'm going to do a -6 with the next 24-ish hours so I can fiddle with where mono puts it's .wapi directory so SELinux doesn't go too nutso at us once selinux-policy -51 is out :) (In reply to comment #4) > I owe you beer, why didn't I think of the fact that HAL changes constantly > breaking for no man. It was actually running a yum update that I spotted it and thought it might be interesting so don't worry.
podsleuth-0.6.0-5.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update podsleuth'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-3681
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
podsleuth-0.6.0-6.fc9 has been submitted as an update for Fedora 9
podsleuth-0.6.0-6.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.