Description of problem: With the following hardware present in my laptop: ...... [ 1.019029] scsi 1:0:0:0: CD-ROM Slimtype DVD A DS8A4S JA22 PQ: 0 ANSI: 5 [ 1.024069] sr0: scsi3-mmc drive: 24x/8x writer dvd-ram cd/rw xa/form2 cdda tray [ 1.024075] cdrom: Uniform CD-ROM driver Revision: 3.20 [ 1.024354] sr 1:0:0:0: Attached scsi CD-ROM sr0 [ 1.024454] sr 1:0:0:0: Attached scsi generic sg1 type 5 ...... /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/scsi_generic/sg0 /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/scsi_generic/sg1 /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0 and with the following rules present in /etc/udev/rules.d/70-persistent-cd.rules (written automatically when things still used to work): # DVD_A_DS8A4S (pci-0000:00:1f.2-scsi-1:0:0:0) SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1" # Slimtype_DVD_A_DS8A4S (pci-0000:00:1f.2-scsi-0:0:0:0) SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrom1", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrw1", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="dvd1", ENV{GENERATED}="1" SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="dvdrw1", ENV{GENERATED}="1" systemd creates only a single symlink /dev/cdrom (to /dev/sg0) and does not bother with the rest. The net effect is, for example, that a "new-and-improved" totem, which is so "user-friendly" that it cannot be told which device to play, is unable to find a freshly inserted DVD and is completely lost (the only saving grace is that "improvements" did not affect yet everything and VLC will play a DVD once told to look at /dev/cdrom). I did not try that yet but quite likely attempts to write something on an appropriate CD or DVD media will also fail for the same reasons and when using correspondingly "user-friendly(not)" burners. Version-Release number of selected component (if applicable): systemd-201-2.fc18.7 Additional info: This is a clear regression from a working system. I see the following in /dev crw-rw----. 1 root disk 21, 0 Jun 8 15:35 /dev/sg0 crw-rw----+ 1 root cdrom 21, 1 Jun 8 15:35 /dev/sg1 brw-rw----+ 1 root cdrom 11, 0 Jun 10 17:05 /dev/sr0 and '/dev/cdrom -> sr0'. No cdrw, no dvd or dvdrw.
(In reply to Michal Jaegermann from comment #0) > and '/dev/cdrom -> sr0'. No cdrw, no dvd or dvdrw. There are no persistent links created for optical drives. The entire idea of creating system config at device discovery time created more problems than it has solved. If you need any custom links, you need to write your own udev rules, the system will not do that on its own. The above rules will not work, because the kernel changed the way ATA devices are registered, and the ID_PATH strings are no longer available. It could be fixed by using recently added ATA bus numbers, but so far the code to read them does not exist and has not catched up. /dev/cdrom -> sr0 is the only thing that can be expected to be around, everything else needs to be provided by custom rules, or by using the symlinks in /dev/disk/by-*/*.
(In reply to Kay Sievers from comment #1) > There are no persistent links created for optical drives. Did you bother to inform whomever takes care of, say, 'totem'? Because between NOTABUG here and a NOTABUG in 'totem', which accepts _only_ a device name which is not going to be supplied, the whole thing becomes unusable.
totem could just look into /proc/sys/dev/cdrom/info, but I guess that's to easy :)
also /dev/disk/by-* symlinks provide a more stable device name than /dev/cdrom2
(In reply to Harald Hoyer from comment #4) > also /dev/disk/by-* symlinks provide a more stable device name than > /dev/cdrom2 Possibly but so what? AFAICS I have no way to tell totem, and other similar applications waging war on users, which device to use and the net effect is that what was working just fine is now plain broken.
(In reply to Michal Jaegermann from comment #5) > (In reply to Harald Hoyer from comment #4) > > also /dev/disk/by-* symlinks provide a more stable device name than > > /dev/cdrom2 > > Possibly but so what? AFAICS I have no way to tell totem, and other similar > applications waging war on users, which device to use and the net effect is > that what was working just fine is now plain broken. What? you can always use /dev/sr[0-9] This gives you the same as /dev/cdrom[0-9] or /dev/dvd[0-9]
(In reply to Harald Hoyer from comment #6) > > What? you can always use /dev/sr[0-9] Oh, sure, I can; only the current version of totem cannot. There is no way to specify a device to use and whatever I am trying to do attempting to force a play of DVD I only see in a response: A error occured The server you are trying to connect to is not known So far there is still a possibility to replace that player with something not broken.