Bug#655924: udev: {dvd,cdrom,…} symlinks are not created
Package: udev
Version: 204-6
Followup-For: Bug #655924
There is an easy fix for creating new /dev/dvd[0-9] symlinks, i.e. drop the
'by-path' method and use 'by-id' for all optical drive types in 75-cd-aliases-
generator.rules:
# These rules generate rules for the /dev/{cdrom,dvd,...} symlinks and
# write them to /etc/udev/rules.d/70-persistent-cd.rules.
ACTION==add, SUBSYSTEM==block, ENV{GENERATED}!=?*, ENV{ID_CDROM}==?*, \
PROGRAM=write_cd_rules by-id, SYMLINK+=$result
Until the bug is fixed in the debian package, users can override the factory
rule by putting the above into /etc/udev/rules.d/75-cd-aliases-generator.rules
And the persistent rules are just best nuked on each boot by way of
/etc/rc.local entry rm /etc/udev/rules.d/70-persistent-* IMHO..
-- Package-specific info:
--
udev database:
--
P:
/devices/pci:00/:00:04.0/:01:08.0/ata2/host1/target1:0:0/1:0:0:0/block/sr0
N: sr0
L: -100
S: cdrom
S: cdrw
S: disk/by-id/ata-ATAPI_iHAS224_Y
S: disk/by-label/iX\x202008\x20Sicher\x20im\x20Netz
S: dvd
S: dvdrw
E: DEVLINKS=/dev/cdrom /dev/cdrw /dev/disk/by-id/ata-ATAPI_iHAS224_Y /dev/disk
/by-label/iX\x202008\x20Sicher\x20im\x20Netz /dev/dvd /dev/dvdrw
E: DEVNAME=/dev/sr0
E:
DEVPATH=/devices/pci:00/:00:04.0/:01:08.0/ata2/host1/target1:0:0/1:0:0:0/block/sr0
E: DEVTYPE=disk
E: ID_ATA=1
E: ID_ATA_FEATURE_SET_PM=1
E: ID_ATA_FEATURE_SET_PM_ENABLED=1
E: ID_ATA_SATA=1
E: ID_ATA_SATA_SIGNAL_RATE_GEN1=1
E: ID_BUS=ata
E: ID_CDROM=1
E: ID_CDROM_CD=1
E: ID_CDROM_CD_R=1
E: ID_CDROM_CD_RW=1
E: ID_CDROM_DVD=1
E: ID_CDROM_DVD_PLUS_R=1
E: ID_CDROM_DVD_PLUS_RW=1
E: ID_CDROM_DVD_PLUS_R_DL=1
E: ID_CDROM_DVD_R=1
E: ID_CDROM_DVD_RAM=1
E: ID_CDROM_DVD_RW=1
E: ID_CDROM_MEDIA=1
E: ID_CDROM_MEDIA_DVD=1
E: ID_CDROM_MEDIA_SESSION_COUNT=1
E: ID_CDROM_MEDIA_STATE=complete
E: ID_CDROM_MEDIA_TRACK_COUNT=1
E: ID_CDROM_MEDIA_TRACK_COUNT_DATA=1
E: ID_CDROM_MRW=1
E: ID_CDROM_MRW_W=1
E: ID_FS_LABEL=iX_2008_Sicher_im_Netz
E: ID_FS_LABEL_ENC=iX\x202008\x20Sicher\x20im\x20Netz
E: ID_FS_TYPE=iso9660
E: ID_FS_USAGE=filesystem
E: ID_MODEL=ATAPI_iHAS224_Y
E:
ID_MODEL_ENC=ATAPI\x20\x20\x20iHAS224\x20\x20\x20Y\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
E: ID_REVISION=ZL0W
E: ID_SERIAL=ATAPI_iHAS224_Y
E: ID_TYPE=cd
E: MAJOR=11
E: MINOR=0
E: OSINFO_BOOTABLE=1
E: SUBSYSTEM=block
E: TAGS=:seat:uaccess:
E: UDISKS_PRESENTATION_NOPOLICY=0
E: USEC_INITIALIZED=2309053337
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (100,
'experimental'), (1, 'raring'), (1, 'quantal'), (1, 'precise')
Architecture: i386 (i686)
Foreign Architectures: amd64
Kernel: Linux 3.13-trunk-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages udev depends on:
ii cdebconf [debconf-2.0] 0.187
ii debconf [debconf-2.0] 1.5.52
ii libacl1 2.2.52-1
ii libblkid1 2.20.1-5.6
ii libc6 2.17-97
ii libkmod216-2
ii libselinux1 2.2.2-1
ii libudev1204-6
ii lsb-base4.1+Debian12
ii procps 1:3.3.9-2
ii util-linux 2.20.1-5.6
udev recommends no packages.
udev suggests no packages.
-- debconf information excluded
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Michael Biebl bi...@debian.org writes: Am 10.10.2013 21:40, schrieb Colomban Wendling: Really? I'm not finding each and every application that uses /dev/dvd as the default DVD device and convince their developers to use a new library. This is not realistic, and IMO not a sensible solution: it would mean breaking a lot of applications that just used to work out of the box, just because of a link? Well, too bad then. It's udev's problem. It's breaking other packages that worked recently. It's not too bad then; it's actively turning working programs into not working programs and causing problems for Debian's users. -- Kie ekzistas vivo, ekzistas espero. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Hi, Ron Murray wrote: [...] but I created an entry for it using the ID_SERIAL variable (which was present) and, on reboot, all symlinks are created as expected. I have the very same problem, and could workaround it like this, by editing the persistent CD rules to use the ID_SERIAL instead of ID_PATH and rebooting. We have two options here: 1/ Fix /lib/udev/write_cd_rules and /lib/udev/rules.d/75-cd-aliases-generator.rules to work with udev v204 and if necessary update the existing /etc/udev/rules.d/70-persistent-cd.rules. For that, someone needs to investigate, what changed in udev. That'd be great. Just FTR, all by-path entries seem to be gone, no more /dev/disks/by-path/ 2/ Follow upstream and simply drop that feature. I'm not convinced it is actually that useful nowadays. Modern desktop environments use frameworks like udisks which don't care for those names/symlinks anyway. I don't think it's sensible, because there still are many an application that use /dev/dvd as the default DVD device. First coming to mind is MPlayer. Of course you can tell it to use another device, but it won't detect the device automatically, so it kinda breaks its default configuration. Regards, Colomban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Am 10.10.2013 17:09, schrieb Colomban Wendling: I don't think it's sensible, because there still are many an application that use /dev/dvd as the default DVD device. First coming to mind is MPlayer. Of course you can tell it to use another device, but it won't detect the device automatically, so it kinda breaks its default configuration. Please file a bug against mplayer to use a more robust method to detect DVD drives, like e.g. using libudev. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Am 10.10.2013 17:09, schrieb Colomban Wendling: Just FTR, all by-path entries seem to be gone, no more /dev/disks/by-path/ I talked to udev upstream about this. Apparently the kernel changed the sysfs layout for ATA devices, so support for ATA devices was disabled in path_id [1]. Kay didn't remember the exact kernel version, when this changed, but mentioned something like 2 years ago. This change is probably the cause why /lib/udev/write_cd_rules is currently broken and no longer creates any entries in /etc/udev/rules.d/70-persistent-cd.rules Michael [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-path_id.c#n377 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Am 10.10.2013 17:09, schrieb Colomban Wendling: Hi, Ron Murray wrote: [...] but I created an entry for it using the ID_SERIAL variable (which was present) and, on reboot, all symlinks are created as expected. I have the very same problem, and could workaround it like this, by editing the persistent CD rules to use the ID_SERIAL instead of ID_PATH and rebooting. Since ID_PATH is no longer set for ATA devices, using ID_SERIAL would indeed be most likely the way to fix this. See /lib/udev/rules.d/75-cd-aliases-generator.rules: For ATA type devices, we would have to call write_cd_rules with by-id as parameter. Unfortunately this will not fix any existing /etc/udev/rules.d/70-persistent-cd.rules, and the result would most likely be that the symlinks are then named cdrw2, dvd2 etc. I don't see a good way to fixup existing entries in /etc/udev/rules.d/70-persistent-cd.rules aside from nuking the file and letting it be recreated. But that opens another can of worms. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Am 10.10.2013 19:08, schrieb Michael Biebl:
Unfortunately this will not fix any existing
/etc/udev/rules.d/70-persistent-cd.rules, and the result would most
likely be that the symlinks are then named cdrw2, dvd2 etc.
I don't see a good way to fixup existing entries in
/etc/udev/rules.d/70-persistent-cd.rules aside from nuking the file and
letting it be recreated. But that opens another can of worms.
I updated 70-persistent-cd.rules to call write_cd_rules with by-id as parameter.
This resulted in
$ cat /etc/udev/rules.d/70-persistent-cd.rules
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.
# DVD_RW_AD-7930H (pci-:00:1f.2-scsi-1:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.2-scsi-1:0:0:0, SYMLINK+=cdrom,
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.2-scsi-1:0:0:0, SYMLINK+=cdrw,
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.2-scsi-1:0:0:0, SYMLINK+=dvd,
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.2-scsi-1:0:0:0, SYMLINK+=dvdrw,
ENV{GENERATED}=1
# File-CD_Gadget (pci-:00:1d.0-usb-0:1.2:1.0-scsi-0:0:0:2)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1d.0-usb-0:1.2:1.0-scsi-0:0:0:2, SYMLINK+=cdrom1,
ENV{GENERATED}=1
# File-CD_Gadget (pci-:00:1d.0-usb-0:1.2:1.0-scsi-0:0:0:2)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==Linux_File-CD_Gadget_78F5FD2FAB42-0:2, SYMLINK+=cdrom2,
ENV{GENERATED}=1
# Optiarc_DVD_RW_AD-7930H (pci-:00:1f.2-scsi-0:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.2-scsi-0:0:0:0, SYMLINK+=cdrom3,
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.2-scsi-0:0:0:0, SYMLINK+=cdrw3,
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.2-scsi-0:0:0:0, SYMLINK+=dvd3,
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.2-scsi-0:0:0:0, SYMLINK+=dvdrw3,
ENV{GENERATED}=1
# File-CD_Gadget (pci-:0e:00.0-usb-0:1:1.0-scsi-0:0:0:2)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:0e:00.0-usb-0:1:1.0-scsi-0:0:0:2, SYMLINK+=cdrom4,
ENV{GENERATED}=1
# File-CD_Gadget (pci-:0e:00.0-usb-0:1:1.0-scsi-0:0:0:2)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==Linux_File-CD_Gadget_78F5FD310FB6-0:2, SYMLINK+=cdrom5,
ENV{GENERATED}=1
# Optiarc_DVD_RW_AD-7930H ()
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==Optiarc_DVD_RW_AD-7930H, SYMLINK+=cdrom6, ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==Optiarc_DVD_RW_AD-7930H, SYMLINK+=cdrw6, ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==Optiarc_DVD_RW_AD-7930H, SYMLINK+=dvd6, ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==Optiarc_DVD_RW_AD-7930H, SYMLINK+=dvdrw6, ENV{GENERATED}=1
I now do have /dev/dvd6 symlinks etc., but this is obviously very ugly.
The old entries (cdrom5 and older) were created with the old udev (v175).
This is a huge mess and imho one more reason to just drop this feature.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Le 10/10/2013 18:02, Michael Biebl a écrit : Am 10.10.2013 17:09, schrieb Colomban Wendling: I don't think it's sensible, because there still are many an application that use /dev/dvd as the default DVD device. First coming to mind is MPlayer. Of course you can tell it to use another device, but it won't detect the device automatically, so it kinda breaks its default configuration. Please file a bug against mplayer to use a more robust method to detect DVD drives, like e.g. using libudev. Really? I'm not finding each and every application that uses /dev/dvd as the default DVD device and convince their developers to use a new library. This is not realistic, and IMO not a sensible solution: it would mean breaking a lot of applications that just used to work out of the box, just because of a link? signature.asc Description: OpenPGP digital signature
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Le 10/10/2013 19:08, Michael Biebl a écrit : Am 10.10.2013 17:09, schrieb Colomban Wendling: Hi, Ron Murray wrote: [...] but I created an entry for it using the ID_SERIAL variable (which was present) and, on reboot, all symlinks are created as expected. I have the very same problem, and could workaround it like this, by editing the persistent CD rules to use the ID_SERIAL instead of ID_PATH and rebooting. Since ID_PATH is no longer set for ATA devices, using ID_SERIAL would indeed be most likely the way to fix this. See /lib/udev/rules.d/75-cd-aliases-generator.rules: For ATA type devices, we would have to call write_cd_rules with by-id as parameter. Unfortunately this will not fix any existing /etc/udev/rules.d/70-persistent-cd.rules, and the result would most likely be that the symlinks are then named cdrw2, dvd2 etc. I don't see a good way to fixup existing entries in /etc/udev/rules.d/70-persistent-cd.rules aside from nuking the file and letting it be recreated. But that opens another can of worms. What about only nuking entries that won't work anymore, aka ID_PATH ATA entries? Or maybe even better, find what ID_PATH entry matches the device and replace them (which should be possible since udevadm still reports PCI pathes, only in a different manner). Or, although I'm not sure if it's technically possible, make this file use the config file feature of dpkg, and ask whether to update it? signature.asc Description: OpenPGP digital signature
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Am 10.10.2013 21:47, schrieb Colomban Wendling: What about only nuking entries that won't work anymore, aka ID_PATH ATA How can you differentiate which entries don't work anymore which do? entries? Or maybe even better, find what ID_PATH entry matches the device and replace them (which should be possible since udevadm still reports PCI pathes, only in a different manner). Well, we don't want to e.g. replace any existing entries for SCSI devices. And the information in the rules files doesn't give any hint which entry was previously created for a ATA device. Or, although I'm not sure if it's technically possible, make this file use the config file feature of dpkg, and ask whether to update it? It's not a conffile, so this isn't possible and wouldn't help anyway. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Le 10/10/2013 22:08, Michael Biebl a écrit : Am 10.10.2013 21:47, schrieb Colomban Wendling: What about only nuking entries that won't work anymore, aka ID_PATH ATA How can you differentiate which entries don't work anymore which do? I don't know, any one that uses ID_PATH and for which this can't be resolved? I mean, the script seems to bail out because it can't generate by-path, so for those devices generate the by-serial and try to find existing matching entries, since it seems to me like there still is some kind of path that could be checked against -- or are those bath impossible to check each against the other? [...] Or, although I'm not sure if it's technically possible, make this file use the config file feature of dpkg, and ask whether to update it? It's not a conffile, so this isn't possible and wouldn't help anyway. OK. But why wouldn't it help? The user would see something changed and can replace or update manually or something. But if it's not possible anyway, let's not think about it. Colomban signature.asc Description: OpenPGP digital signature
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Am 10.10.2013 21:40, schrieb Colomban Wendling: Le 10/10/2013 18:02, Michael Biebl a écrit : Am 10.10.2013 17:09, schrieb Colomban Wendling: I don't think it's sensible, because there still are many an application that use /dev/dvd as the default DVD device. First coming to mind is MPlayer. Of course you can tell it to use another device, but it won't detect the device automatically, so it kinda breaks its default configuration. Please file a bug against mplayer to use a more robust method to detect DVD drives, like e.g. using libudev. Really? I'm not finding each and every application that uses /dev/dvd as the default DVD device and convince their developers to use a new library. This is not realistic, and IMO not a sensible solution: it would mean breaking a lot of applications that just used to work out of the box, just because of a link? Well, too bad then. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Am 09.10.2013 03:09, schrieb Ron Murray:
Package: udev
Version: 204-5
Followup-For: Bug #655924
I have the same kind of problem. I have four Debian machines, and on
three of them the only symlink created is /dev/cdrom (linked to sr0).
The fourth machine (the one I'm submitting this on, and on which the
udev database snapshot was taken) fares even worse. It has two DVD
drives at the moment: one (sr0) via SATA, and the other (sr1) via
USB. The 70-persisten-cd.rules file, when generated, contains nothing
on the SATA drive, and the USB drive has two entries (one using
ENV{ID_SERIAL} and the other using ENV{ID_PATH}. Deleting the file and
trying to force generation of a new one with
echo add /sys/block/sr0/uevent
has no effect, although doing the same thing using sr1 creates the
file as expected. I do note that the SATA drive doesn't seem to have
an ID_PATH variable as obtained by
udevadm info --query=all --name=/dev/sr0
but I created an entry for it using the ID_SERIAL variable (which
was present) and, on reboot, all symlinks are created as expected.
We have two options here:
1/ Fix /lib/udev/write_cd_rules and
/lib/udev/rules.d/75-cd-aliases-generator.rules to work with udev v204
and if necessary update the existing
/etc/udev/rules.d/70-persistent-cd.rules.
For that, someone needs to investigate, what changed in udev.
2/ Follow upstream and simply drop that feature. I'm not convinced it
is actually that useful nowadays. Modern desktop environments use
frameworks like udisks which don't care for those names/symlinks anyway.
I'm leaning towards 2/.
Marco, what's your opinion on this?
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#655924: udev: {dvd,cdrom,?} symlinks are not created
Package: udev
Version: 204-5
Followup-For: Bug #655924
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have the same kind of problem. I have four Debian machines, and on
three of them the only symlink created is /dev/cdrom (linked to sr0).
The fourth machine (the one I'm submitting this on, and on which the
udev database snapshot was taken) fares even worse. It has two DVD
drives at the moment: one (sr0) via SATA, and the other (sr1) via
USB. The 70-persisten-cd.rules file, when generated, contains nothing
on the SATA drive, and the USB drive has two entries (one using
ENV{ID_SERIAL} and the other using ENV{ID_PATH}. Deleting the file and
trying to force generation of a new one with
echo add /sys/block/sr0/uevent
has no effect, although doing the same thing using sr1 creates the
file as expected. I do note that the SATA drive doesn't seem to have
an ID_PATH variable as obtained by
udevadm info --query=all --name=/dev/sr0
but I created an entry for it using the ID_SERIAL variable (which
was present) and, on reboot, all symlinks are created as expected.
Note: current kernel is user-compiled, but the same thing happens with
the stock Debian kernel.
- -- Package-specific info:
(udev database zipped and attached)
- -- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11.4-khufu-0 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages udev depends on:
ii debconf [debconf-2.0] 1.5.51
ii libacl12.2.52-1
ii libblkid1 2.20.1-5.5
ii libc6 2.17-93
ii libkmod2 9-3
ii libselinux12.1.13-2
ii libudev1 204-5
ii lsb-base 4.1+Debian12
ii procps 1:3.3.4-2
ii sysv-rc2.88dsf-43
ii util-linux 2.20.1-5.5
udev recommends no packages.
udev suggests no packages.
- -- debconf information:
udev/sysfs_deprecated_incompatibility:
udev/title/upgrade:
udev/new_kernel_needed: false
udev/reboot_needed:
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBAgAGBQJSVKy3AAoJEDHYrtWvbQ1KeoIP/RGMt/FkxydjdgPqBwsCeyAL
cjmiikNd8HCYD8sk8kAOKaybNIYZCT9kf8FUi6qb4Nqp/NAF3Y4ZMM6O8wqH4+oz
LVpvlPMEAclz57QNXUDO8HmRG3Hp/tukqt05vMtPmjWfjLxla9oDGbq5wHWb6cw5
AwrqHjn4c/lMTU84nqo+vrjhflNixScr+kz828ke+lGxCQqDRYCI1mIbp1ZbEh3B
KoCbu7YVQ1q8+m+Ke19YMHq0IL0pbi6hcgGn0zRbFcqa+XsRNzBEeMm4t5RsUEkt
cCwEDsaI7mzItdJHPNJjgUuvImiP6dvK3jP058vwtA0i9CCadirXFife6wbRyGa+
aIUttD6GuDpy6k7hQza10ATXmdWngWP4BSglSGnyRyjIMpgJ3rkQo+phcF+vINsE
JRLG3pl9zLe65dsr/kIM6El60sBqqNP2SMxqYOJbS6HoT1tRZSq1XXnwEJENiMsq
MGSFT8/7sLY8QwyCQ1SCQ/Zo9BYcVMyy8OUHmBCGVqDd/ZwtkwNZBJVsaIvYQGRp
kQL9SKsJZpFoFXhzWuUc9BhRgDrwoVs5NXV3zJwimzvRGOgkONb/nTebiJvxt7Xt
XFdwUgYf3y97wM4U23Ls+JYo1yuCGDnq78VogitPgI+lllNd2FNbNlciUZ0XkZ4l
rPgTkwkskWnnBgKoDXDt
=Qquy
-END PGP SIGNATURE-
udev-database.tar.bz2
Description: BZip2 compressed data
Bug#655924: udev: {dvd,cdrom,…} symlinks are not created
Package: udev
Version: 175-3
Severity: important
Hi,
as of today (but can't tell for how long), my cdrom reader doesn't get its
/dev/{dvd,cdrom,…}# symlinks.
The particularity of my cdrom reader is that its hotpluggable, hence /was/
getting different numbers at each plug (but that was manageable).
Today, as I tried to hotplug it, I noticed I had no {dev,cdrom,…} symlinks in
/dev. So I tried moving /etc/udev/rules.d/70-persistent-cd.rules out of the
way and rebooted. After reboot, still no symlink (still /dev/sr0 exists).
Both old and new 70-persistent-cd.rules are attached.
Cheers,
OdyX
-- System Information:
Debian Release: wheezy/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages udev depends on:
ii debconf [debconf-2.0] 1.5.41
ii libc6 2.13-24
ii libselinux12.1.0-4
ii libudev0 175-3
ii lsb-base 3.2-28
ii util-linux 2.20.1-1.1
Versions of packages udev recommends:
ii pciutils 1:3.1.8-2
ii usbutils 1:005-2
udev suggests no packages.
-- debconf information:
udev/new_kernel_needed: false
udev/title/upgrade:
udev/reboot_needed:
udev/sysfs_deprecated_incompatibility:
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.
# QEMU_DVD-ROM (pci-:00:01.1-scsi-1:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:01.1-scsi-1:0:0:0, SYMLINK+=cdrom,
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:01.1-scsi-1:0:0:0, SYMLINK+=dvd,
ENV{GENERATED}=1
# HSDPA_Modem (pci-:00:1d.0-usb-0:1:1.0-scsi-0:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1d.0-usb-0:1:1.0-scsi-0:0:0:0, SYMLINK+=cdrom1,
ENV{GENERATED}=1
# HSDPA_Modem (pci-:00:1d.0-usb-0:1:1.0-scsi-0:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==GT_HSDPA_Modem_Serial_Number-0:0, SYMLINK+=cdrom2,
ENV{GENERATED}=1
# MB525 (pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0, SYMLINK+=cdrom3,
ENV{GENERATED}=1
# MB525 (pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==Motorola_MB525_015F1C6806008014-0:0, SYMLINK+=cdrom4,
ENV{GENERATED}=1
# Cruzer (pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:1)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:1, SYMLINK+=cdrom5,
ENV{GENERATED}=1
# Cruzer (pci-:00:1d.7-usb-0:1:1.0-scsi-0:0:0:1)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==SanDisk_Cruzer_1101810A2241B22D-0:1, SYMLINK+=cdrom6,
ENV{GENERATED}=1
# Optiarc_DVD+_-RW_AD-5560A (pci-:00:1f.1-scsi-0:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.1-scsi-0:0:0:0, SYMLINK+=cdrom7,
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.1-scsi-0:0:0:0, SYMLINK+=cdrw7,
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.1-scsi-0:0:0:0, SYMLINK+=dvd7,
ENV{GENERATED}=1
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.1-scsi-0:0:0:0, SYMLINK+=dvdrw7,
ENV{GENERATED}=1
# Cruzer_Contour (pci-:00:1d.7-usb-0:4:1.0-scsi-0:0:0:1)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1d.7-usb-0:4:1.0-scsi-0:0:0:1, SYMLINK+=cdrom8,
ENV{GENERATED}=1
# Cruzer_Contour (pci-:00:1d.7-usb-0:4:1.0-scsi-0:0:0:1)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==SanDisk_Cruzer_Contour_31469218BBD0172B-0:1,
SYMLINK+=cdrom9, ENV{GENERATED}=1
# Mass_storage (pci-:00:1d.7-usb-0:1:1.1-scsi-0:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1d.7-usb-0:1:1.1-scsi-0:0:0:0, SYMLINK+=cdrom10,
ENV{GENERATED}=1
# Mass_storage (pci-:00:1d.7-usb-0:1:1.1-scsi-0:0:0:0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==HUAWEI_Mass_storage_1234567890ABCDEF-0:0, SYMLINK+=cdrom11,
ENV{GENERATED}=1
# HUAWEI_Mobile_Connect (pci-:00:1d.7-usb-0:4:1.0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1d.7-usb-0:4:1.0, SYMLINK+=cdrom12,
ENV{GENERATED}=1
# HUAWEI_Mobile_Connect (pci-:00:1d.7-usb-0:4:1.0)
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_SERIAL}==Huawei_Incorporated_HUAWEI_Mobile_Connect_1234567890ABCDEF,
SYMLINK+=cdrom13, ENV{GENERATED}=1
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the
