Marking as regression-update, since this reportedly worked in lucid.
==== SRU information ====
= Rationale =
This is a regression from 10.04, where the IronKey reportedly worked. I don't really know why yet, but it's clear why maverick udev's cdrom_id fails.
I debugged this with another user on IRC, who also has an ironkey, and without the second patch you get a lot of extra bogus audio tracks, which confuse nautilus. This patch has been tested by that user, the reporter of this bug (bankey), and by me with about 5 different types of CD media.
= Regression potential =
The first patch (678df8a4) merely adds yet another fallback for CD media detection if both the current MMC-2 ioctl as well as the old-style ioctl fail; we did not yet encounter a real CD drive where this happens, and on those the behaviour is unchanged. The regression potential on those pathological drives which support neither is that they also have a broken CDROM_DRIVE_STATUS ioctl which claims to have a medium although they don't. But this isn't relevant for the IronKeys (since you can't actually remove the medium), and on real drives you would get a false medium displayed without any tracks (but if none of the ioctls work, then there's nothing that you can do with the drive in the first place..)
The second patch could potentially lead to not counting tracks which were previously recognized IF the drive lies about the number of tracks. However, since we compared the behaviour under Windows, we have reason to believe that the Windows driver read this field as well; otherwise you would also get bogus audio tracks there; the extra TOC fields do have reasonably valid entries, but are outside the number of tracks area. In the end this could lead to nautilus/rhythmbox not detecting all audio tracks. This patch got successfully tested on several drives and media, though, and all specs that I looked at agree on these fields being the track number limits, so I think the regression potential here is low.
Marking as regression-update, since this reportedly worked in lucid.
==== SRU information ====
= Rationale =
This is a regression from 10.04, where the IronKey reportedly worked. I don't really know why yet, but it's clear why maverick udev's cdrom_id fails.
= Patch =
The most important fix for this is
http:// git.kernel. org/?p= linux/hotplug/ udev.git; a=commitdiff; h=678df8a461c75 73bf423a39be383 bc7b70d943df
However, we should also apply
http:// git.kernel. org/?p= linux/hotplug/ udev.git; a=commitdiff; h=1ebd2a5620c93 ef4698485d392c1 9ded675412d2
I debugged this with another user on IRC, who also has an ironkey, and without the second patch you get a lot of extra bogus audio tracks, which confuse nautilus. This patch has been tested by that user, the reporter of this bug (bankey), and by me with about 5 different types of CD media.
= Regression potential =
The first patch (678df8a4) merely adds yet another fallback for CD media detection if both the current MMC-2 ioctl as well as the old-style ioctl fail; we did not yet encounter a real CD drive where this happens, and on those the behaviour is unchanged. The regression potential on those pathological drives which support neither is that they also have a broken CDROM_DRIVE_STATUS ioctl which claims to have a medium although they don't. But this isn't relevant for the IronKeys (since you can't actually remove the medium), and on real drives you would get a false medium displayed without any tracks (but if none of the ioctls work, then there's nothing that you can do with the drive in the first place..)
The second patch could potentially lead to not counting tracks which were previously recognized IF the drive lies about the number of tracks. However, since we compared the behaviour under Windows, we have reason to believe that the Windows driver read this field as well; otherwise you would also get bogus audio tracks there; the extra TOC fields do have reasonably valid entries, but are outside the number of tracks area. In the end this could lead to nautilus/rhythmbox not detecting all audio tracks. This patch got successfully tested on several drives and media, though, and all specs that I looked at agree on these fields being the track number limits, so I think the regression potential here is low.