Bug#991639: udev: 80-debian-compat.rules can yield non-stable and inconsistent symlinks

[Vincent Lefevre]

On 2021-07-29 17:05:23 +0200, Michael Biebl wrote:
> Am 29.07.21 um 16:33 schrieb Vincent Lefevre:
> > On 2021-07-29 16:20:48 +0200, Michael Biebl wrote:
> > > And the comment from 2017 still holds true:
> > > https://lists.debian.org/debian-user/2017/04/msg00790.html
> > > 
> > > "
> > > See the comment in there:
> > > 
> > > # These rules will create symlinks for CD/DVD drives, to help old
> > > # programs which are unable to automatically discover the devices.
> > > # The first detected device gets the symlink, but this is not stable across
> > > # reboots.
> > > 
> > > So, yes, what you see can happen depending on the order devices are
> > > discovered.
> > > "
> > > 
> > > The kernel hasn't changed. It still probes devices asynchronously.
> > > There is not much we can do about that.
> > 
> > The comment says: "The first detected device gets the symlink".
> > If this were true, all symlinks would be the same (even though
> > this would not be stable), which is not the case.
> > 
> > BTW, aren't the devices numbered 0, 1, etc. in the order they are
> > detected, so that one would expect always sr0 here?
> 
> It appears you do not believe what I said. Feel free to propose a patch.

This is not a question of belief, but of logic. Either sr0 or sr1 is the
first detected device. Thus the 3 symlinks added by 80-debian-compat.rules
are expected to be the same (possibly different from "sr0", which is
hardcoded to "sr0" in 60-cdrom_id.rules).

On the second remark, actually the kernel logs make this quite clear:

cventin:~> journalctl -b | grep 'sr[01]'
Jul 29 14:25:46 cventin kernel: sr 2:0:0:0: [sr0] scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
Jul 29 14:25:46 cventin kernel: sr 3:0:0:0: [sr1] scsi3-mmc drive: 48x/12x writer dvd-ram cd/rw xa/form2 cdda tray
Jul 29 14:25:46 cventin kernel: sr 2:0:0:0: Attached scsi CD-ROM sr0
Jul 29 14:25:46 cventin kernel: sr 3:0:0:0: Attached scsi CD-ROM sr1

and ditto for the previous boots.

So there are no visible issues with the kernel, only with udev.

I'm not sure how this works, but if I understand the udev(7) man page
correctly, I suppose that the sr number should be subtracted from the
link_priority value, so that sr0 will get the precedence over sr1.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)