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=678df8a461c7573bf423a39be383bc7b70d943df However, we should also apply http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=1ebd2a5620c93ef4698485d392c19ded675412d2 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. ** Changed in: udev (Ubuntu) Status: Incomplete => Fix Committed ** Also affects: udev (Ubuntu Maverick) Importance: Undecided Assignee: Martin Pitt (pitti) Status: Fix Committed -- mounting hardware encrypted usb stick failes https://bugs.launchpad.net/bugs/653568 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
