Bug 972859 - udev fails to generate required device links
udev fails to generate required device links
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: systemd-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-10 12:29 EDT by Michal Jaegermann
Modified: 2013-09-13 12:30 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-12 16:01:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2013-06-10 12:29:09 EDT
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.
Comment 1 Kay Sievers 2013-09-12 16:01:56 EDT
(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-*/*.
Comment 2 Michal Jaegermann 2013-09-12 16:29:40 EDT
(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.
Comment 3 Harald Hoyer 2013-09-13 07:33:13 EDT
totem could just look into /proc/sys/dev/cdrom/info, but I guess that's to easy :)
Comment 4 Harald Hoyer 2013-09-13 07:36:53 EDT
also /dev/disk/by-* symlinks provide a more stable device name than /dev/cdrom2
Comment 5 Michal Jaegermann 2013-09-13 11:07:07 EDT
(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.
Comment 6 Harald Hoyer 2013-09-13 11:57:33 EDT
(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]
Comment 7 Michal Jaegermann 2013-09-13 12:30:21 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.