Description of problem: The latest Ipod Nano (2nd generation) is detected by HAL as a "via_raid_member" and then fails to auto-mount. Version-Release number of selected component (if applicable): 0.5.8.1 (both compiles 5 (updates) and 6 (development) How reproducible: very. Steps to Reproduce: 1. Get ipod nano 2nd generation 2. plug in via USB 3. look in hal-device-manager Actual results: as above Expected results: should see as a mountable disk, and pass it to gnome-mount to mount Additional info: This bug has also been observed in Ubuntu, by several different people: Their bug report, with debian-style patch to 'hal' is: https://launchpad.net/distros/ubuntu/+source/hal/+bug/66068 There is also discussion of it in the hal archives at freedesktop.org, http://lists.freedesktop.org/archives/hal/2006-October/006413.html, which offer a fix at the kernel level. Both are dated after the current HAL release (from September)
There's a patch for udev (hal relies on libvolume_id from the udev src.rpm) for this here http://lists.freedesktop.org/archives/hal/2006-October/006412.html Harald, can you apply this for FC6 please? Also adding Bill Peck as Cc as he experienced this problem too and said the patch worked fine. Thanks.
Yes, I can confirm the patch works, QA ack. ;-)
Suffering from the same problem here.... new 8gig iPod Nano for Christmas... doesn't work due to hal thinking "via_raid_member". Looks like BZ # 220773 is the same as this bug. Please fix!
*** Bug 220695 has been marked as a duplicate of this bug. ***
*** Bug 220773 has been marked as a duplicate of this bug. ***
udev-095-17.fc6 will appear in testing
Confirmed that the udev fix works. dmesg now shows this: SCSI subsystem initialized Initializing USB Mass Storage driver... scsi0 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 2 usb-storage: waiting for device to settle before scanning usbcore: registered new driver usb-storage USB Mass Storage support registered. Vendor: Apple Model: iPod Rev: 1.62 Type: Direct-Access ANSI SCSI revision: 00 usb-storage: device scan complete scsi 0:0:0:0: Attached scsi generic sg0 type 0 SCSI device sda: 3964928 2048-byte hdwr sectors (8120 MB) sda: Write Protect is off sda: Mode Sense: 68 00 00 08 sda: assuming drive cache: write through SCSI device sda: 3964928 2048-byte hdwr sectors (8120 MB) sda: Write Protect is off sda: Mode Sense: 68 00 00 08 sda: assuming drive cache: write through sda: sda1 sda2 sd 0:0:0:0: Attached scsi removable disk sda "lshal | grep -i ipod" now shows this: info.udi = '/org/freedesktop/Hal/devices/storage_serial_Apple_iPod_000A2700192 DBC01' (string) info.product = 'iPod' (string) storage.serial = 'Apple_iPod_000A2700192DBC01' (string) storage.model = 'iPod' (string) block.storage_device = '/org/freedesktop/Hal/devices/storage_serial_Apple_iPod _000A2700192DBC01' (string) etc Now I just need Banshee and Rhythmbox to understand that it really can access my 8gig iPod Nano :-(
I have Banshee working with the 8GB nano fine. You may need to update libgpod from freshrpms to support the newer 6th generation ipod. if libgpod is in extras we should get it updated there.
I noticed that libgpod-0.4.2 came out *today*... but can't get it to compile so I can't tell if that would help me or not. Perhaps we can get libgpod updated to this version in Fedora Core 6
libgpod is available in core. An update to 0.4.2 is in updates-testing as of the 17th. An update for rhythmbox is also in -testing. Please check those out and report if they work well with the later iPod Nanos. For banshee, libgpod isn't a factor AFAIK. It used libipoddevice and it's own ipod-sharp lib to access the ipod.
*** Bug 211787 has been marked as a duplicate of this bug. ***