Created attachment 1087059 [details] patch to cdrom_id.c Description of problem: I have a USB stick that appears as two devices - a CDROM and a one-partition disk. This is similar to a U3 device, except that the CDROM has desired data and not the U3 executables. The CDROM is not set up correctly in udev, preventing it from being automounted. Version-Release number of selected component (if applicable): systemd 219.24 How reproducible: Always Steps to Reproduce: 1. Plug in the USB stick Actual results: No symbolic link is created in /dev/disk/by-uuid for the fake CDROM. Only the disk partition is automounted. Expected results: A symbolic link should be created in /dev/disk/by-uuid. Both the disk partition and the fake CDROM will then be automounted. Additional info: The problem appears to be in cdrom_id, which has two bugs preventing it from returning the correct number of data tracks on the fake CDROM. 1/ If a cdrom drive has no current profile, then don't just assume that it has no media. Instead use result of CDROM_DRIVE_STATUS (already done) to determine whether there is media in the drive. 2/ When iterating over the tracks on the media, allow the use of the last 8 bytes of the TOC structure. With these two changes the fake CDROM is correctly set up. I have attached a patch. I'll submit this upstream, if I'm told where to submit it.
Thanks for your patch! Please create an issue or pull request on github for upstream inclusion. https://github.com/systemd/systemd
Thanks for the response. I'm not sure that the patch is 100% correct, as I do not have access to information on how CD tocs are set up, so I'll create an issue with the information above.
The issue is https://github.com/systemd/systemd/issues/1779
The systemd people don't want to touch this. It appears that cdrom_id.c is an orphan, but still used to set up stuff. Anyway, I guess that the best that can be done now is to close this as WONTFIX, which I have done.