New iPod nano recognized as via raid member

I think this patch might do the trick. I tried hacking /usr/lib/hal/hald-probe-volume and hald-probe-storage and setting VIA_SIGNATURE to 0x55ab instead of 0x55aa. gnome-volume-manager now mounts the iPod Nano as expected.

I have tested this patch, and it works for me. The iPod Nano 2G partition is detected correctly, and is now handled correctly in KDE.

Can anyone tell me how to install the proposed fix?

I am fully unaware of how to install a *.debdiff file and quite desperate that no one knows either.

Are u sure that this bug doesn't must be assigned to udev?
Take a look here, seems that was fixed upstram:

http://lists.freedesktop.org/archives/hal/2006-October/006412.html

On Sat, Nov 18, 2006 at 01:29:29AM -0000, Stefano Fabri wrote:
> Are u sure that this bug doesn't must be assigned to udev?
> Take a look here, seems that was fixed upstram:
> http://lists.freedesktop.org/archives/hal/2006-October/006412.html

The observant reader will notice that it was actually I and Kay who
discussed it on the hal mailing list. :-)

Whether it belongs in udev or hal depends on whether we want to fix it
in Dapper/Edgy or Feisty. Feisty uses hal 0.5.8.1 which uses
libvolume_id, while Edgy and Dapper use < 0.5.8 which includes its own
copy of libvolume_id.

Nonetheless, well spotted and thanks for your input.

Cheers.

Will this also fix the same sort of problem with the new 8G nano? dmesg output:

[17274130.632000] usb 4-3: configuration #1 chosen from 2 choices
[17274130.632000] scsi2 : SCSI emulation for USB Mass Storage devices
[17274130.632000] usb-storage: device found at 22
[17274130.632000] usb-storage: waiting for device to settle before scanning
[17274135.632000] usb-storage: device scan complete
[17274135.636000] Vendor: Apple Model: iPod Rev: 1.62
[17274135.636000] Type: Direct-Access ANSI SCSI revision: 00
[17274135.644000] SCSI device sdc: 3964928 2048-byte hdwr sectors (8120 MB)
[17274135.648000] sdc: Write Protect is off
[17274135.648000] sdc: Mode Sense: 68 00 00 08
[17274135.648000] sdc: assuming drive cache: write through
[17274135.652000] SCSI device sdc: 3964928 2048-byte hdwr sectors (8120 MB)
[17274135.656000] sdc: Write Protect is off
[17274135.656000] sdc: Mode Sense: 68 00 00 08
[17274135.656000] sdc: assuming drive cache: write through
[17274135.656000] sdc: sdc1 sdc2
[17274135.656000] sd 2:0:0:0: Attached scsi removable disk sdc
[17274135.656000] sd 2:0:0:0: Attached scsi generic sg2 type 0
[17274139.888000] ISO 9660 Extensions: Microsoft Joliet Level 3
[17274139.908000] ISO 9660 Extensions: RRIP_1991A
[17274146.656000] UDF-fs: No partition found (1)
[17274146.792000] Unable to identify CD-ROM format.
[17274152.200000] UDF-fs: No VRS found
[17274152.340000] Unable to identify CD-ROM format.
[17274152.364000] FAT: invalid media value (0x2f)
[17274152.364000] VFS: Can't find a valid FAT filesystem on dev sdc1.
[17274152.372000] printk: 1 messages suppressed.
[17274152.372000] NTFS-fs warning (device sdc1): is_boot_sector_ntfs(): Invalid boot sector checksum.
[17274152.372000] NTFS-fs error (device sdc1): read_ntfs_boot_sector(): Primary boot sector is invalid.
[17274152.372000] NTFS-fs error (device sdc1): read_ntfs_boot_sector(): Mount option errors=recover not used. Aborting without trying to recover.
[17274152.372000] NTFS-fs error (device sdc1): ntfs_fill_super(): Not an NTFS volume.
[17274152.384000] hfs: unable to find HFS+ superblock
[17274152.396000] hfs: can't find a HFS filesystem on dev sdc1.
[17274152.420000] VFS: Can't find ext3 filesystem on dev sdc1.
[17274152.424000] VFS: Can't find an ext2 filesystem on dev sdc1.
[17274152.436000] ReiserFS: sdc1: warning: sh-2021: reiserfs_fill_super: can not find reiserfs on sdc1

On Tue, Nov 28, 2006 at 03:00:41PM -0000, anthony baxter wrote:
> Will this also fix the same sort of problem with the new 8G nano? dmesg
> output:

Your dmesg output does not in itself suggest anything wrong. The iPod
has two partitions. sdc1 holds the iPod's operating system or firmware
while sdc2 is the partition that holds your music. The errors in your
dmesg output simply tells that something has tried to mount sdc1 which
often means that all the different file system drivers will be tried in
sequence. None of the will succeed, hence the errors.

However, this does not necessarily mean that you're not experiencing the
problem that I was seeing. I just can't tell from the dmesg output. Try
running lshal, locate the output block that relates to sdc2. If it says
via_raid_member somewhere in that block, you're seeing the same bug.

Cheers.

Hm. Looking a bit closer, this may be a different issue. The behaviour I'm seeing is that the ipod is getting mounted, but just as (for instance) /media/sdc2, while my old 15G pre-clickwheel ipod is mounted as /media/ipod (or /media/ipod-1) and then the appropriate signals are sent to banshee and amarok to enable it automatically. I'm looking at the output of lshal, and I can't see how the two differ (I have both plugged in right now).

On Tue, Nov 28, 2006 at 10:05:57PM -0000, anthony baxter wrote:
> Hm. Looking a bit closer, this may be a different issue. The behaviour
> I'm seeing is that the ipod is getting mounted, but just as (for
> instance) /media/sdc2, while my old 15G pre-clickwheel ipod is mounted
> as /media/ipod (or /media/ipod-1) and then the appropriate signals are
> sent to banshee and amarok to enable it automatically. I'm looking at
> the output of lshal, and I can't see how the two differ (I have both
> plugged in right now).

You should file a new bug about this. It sounds like a HAL issue.

https://launchpad.net/distros/ubuntu/+source/hal/+filebug

Cheers.

Thanks, Soren!

how the heck does one use this patch?????
I'm a relative linux noob.

This evening, I ran into the same issue with a friends' ipod. I can confirm that the debdiff fixes the issue.

Martin, can we have this patch in edgy-updates?

waytoogeeky, theoretically:
1) mkdir hal-ipod-fix && cd hal-ipod-fix
2) sudo apt-get build-dep hal
3) apt-get source hal
4) sudo apt-get install fakeroot
5) wget http://librarian.launchpad.net/4838850/via-raid-fix.debdiff
6) patch -p0 < via-raid-fix.debdiff
7) cd hal-*
8) dpkg-buildpackage -rfakeroot
9) sudo dpkg -i *.deb

Thank you so much for posting that, I appreciate it a lot.

everything goes fine until this, then it's just a whole bunch of junk:
root@ubuntu:/home/waytoogeeky/hal-ipod-fix# patch -p0 < via-raid-fix.debdiff
patching file hal-0.5.7.1/debian/changelog
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file hal-0.5.7.1/debian/changelog.rej
patching file hal-0.5.7.1/debian/patches/23-fix-via-raid-detection.patch

anything I should try?

Just go ahead to the next step..

after that, every step except the directory change results in errors.

Okay, actually, Malone is not for giving support but hey - it's christmas :-)

So, as a christmas present, I prepared precompiled .debs which can be found at http://gamesplace.info/opensource/ubuntu/hal/ipod-nano-fix/. In the README, there's information provided how to install them.

Martin: thanks for your Christmas present, my brother gave his girlfriend a Nano and thanks to your packages we were able to make it work. Really appreciated.

Look forward to seeing this in edgy-updates...

Btw, a friend told me that after applying this patch his other mp3 player (Trekstor i.beat rock) was detected as an iPod also (but he was able to access it).

I'll try to reproduce this, I have the same mp3 player..

Can this fix not be made available as an update? Thanks for the debs btw!!!

my thanks as well - my issue was an authorization issue (originally synced it with a different computer than my laptop at home... then was locked out in windows and linux). But now it works beautifully under Ubuntu. (edgy). Thanks!

This is already fixed in feisty's libvolume-id.

Thanks Martin - will you be fixing this in edgy-updates?

Closing hal task, since the code is in udev's libvolume-id now.

This is not the type of bug we fix in stable releases, sorry.

> This is not the type of bug we fix in stable releases, sorry.

Ok, thanks Martin (P). Martin (J), are you able to confirm that your
packages will result in clean upgrades to Feisty when the time comes?

Matthew, although I didn't test it in detail, I do not except my packages to break Feisty upgrades.

The reasons are:

- I only added a patch to debian/patches and changed the Ubuntu revision +1.

- My package is version 0.5.7.1-0ubuntu18, the current one in Feisty is 0.5.8.1-4ubuntu1, so the upgrade procedure should detect hal as "needs upgrade".

- On a Feisty install having my hal packages for Edgy installed, a dist-upgrade works fine.

Is there any way to apply this fix in Dapper too? Without breaking package dependencies and confusing the update-manager.

Is this fixed in Feisty?

Yes, as the status says "Fix Released".

I didn't experience this problem until I upgraded to Gutsy. Now, my ipod apparently has the raid bug. This wouldn't be a problem if this fix worked for me -- but it looks like I can't use it with my architecture:

theluddite@S01060019d15f4017MACHINE:~/Downloads/hal-ipod-fix$ sudo dpkg -i *.deb
[sudo] password for theluddite:
dpkg: error processing hal_0.5.7.1-0ubuntu18_i386.deb (--install):
 package architecture (i386) does not match system (amd64)
dpkg - warning: downgrading hal-device-manager from 0.5.9.1-6ubuntu5 to 0.5.7.1-0ubuntu18.
(Reading database ... 107730 files and directories currently installed.)
Preparing to replace hal-device-manager 0.5.9.1-6ubuntu5 (using hal-device-manager_0.5.7.1-0ubuntu18_all.deb) ...
Unpacking replacement hal-device-manager ...
dpkg - warning: downgrading hal-doc from 0.5.9.1-6ubuntu5 to 0.5.7.1-0ubuntu18.
Preparing to replace hal-doc 0.5.9.1-6ubuntu5 (using hal-doc_0.5.7.1-0ubuntu18_all.deb) ...
Unpacking replacement hal-doc ...
dpkg: error processing libhal1_0.5.7.1-0ubuntu18_i386.deb (--install):
 package architecture (i386) does not match system (amd64)
dpkg: error processing libhal-dev_0.5.7.1-0ubuntu18_i386.deb (--install):
 package architecture (i386) does not match system (amd64)
dpkg: error processing libhal-storage1_0.5.7.1-0ubuntu18_i386.deb (--install):
 package architecture (i386) does not match system (amd64)
dpkg: error processing libhal-storage-dev_0.5.7.1-0ubuntu18_i386.deb (--install):
 package architecture (i386) does not match system (amd64)
dpkg: dependency problems prevent configuration of hal-device-manager:
 hal-device-manager depends on python2.4; however:
  Package python2.4 is not installed.
dpkg: error processing hal-device-manager (--install):
 dependency problems - leaving unconfigured
Setting up hal-doc (0.5.7.1-0ubuntu18) ...
Errors were encountered while processing:
 hal_0.5.7.1-0ubuntu18_i386.deb
 libhal1_0.5.7.1-0ubuntu18_i386.deb
 libhal-dev_0.5.7.1-0ubuntu18_i386.deb
 libhal-storage1_0.5.7.1-0ubuntu18_i386.deb
 libhal-storage-dev_0.5.7.1-0ubuntu18_i386.deb
 hal-device-manager

Any chance of a fix for x86_64?

theluddite, this is already supposed to be fixed in Gutsy. Installing a very old hal on it won't help. Can you please open a new bug about this against 'hal' and do the steps on https://wiki.ubuntu.com/DebuggingHal?