Bug 570490
|
Description
Steve Tyler
2010-03-04 14:26:07 UTC
This seems to be a work-around for the spontaneous reloading problem: $ eject /dev/sr0; sleep 1; eject /dev/sr0 (In reply to comment #1) > This seems to be a work-around for the spontaneous reloading problem: > $ eject /dev/sr0; sleep 1; eject /dev/sr0 https://bugzilla.redhat.com/show_bug.cgi?id=453095#c127 sysctl -w dev.cdrom.autoclose=0 (In reply to comment #0) > Description of problem: > I replaced my optical drive and, after rebooting, /dev/cdrom was not created. > /dev/cdrom2 was created instead. The system has one optical drive (before and > after the replacement). > > This could be reproduced on F11, F12, F13, and Ubuntu 9.10 (all booting on the > same hardware and fully updated). cdrom2 is by purpose... edit: /etc/udev/rules.d/70-persistent-cd.rules Thanks for your tip re autoclose. And thanks for your suggestion that I edit a config file after replacing an optical drive. I edit config files all the time, but this is not one I should even have to know about. I should not have to edit anything after replacing one optical drive with another optical drive. There is only one drive in the system before and there is only one after. That implies that it should be /dev/cdrom. NB: This bug breaks the "eject" command. In Ubuntu 9.10 the "eject" command works despite this bug. ah, well, I will not fix this "bug", because it's intentionally designed that way, so if you connect e.g. USB cdroms, they will get the same name, regardless of the ordering you plug them in.. (In reply to comment #5) > ah, well, I will not fix this "bug", because it's intentionally designed that > way, so if you connect e.g. USB cdroms, they will get the same name, regardless > of the ordering you plug them in.. Yeah, I understand that. But my optical drives are not "removable" -- it takes a screwdriver and lot of hard cable plugging and unplugging. :-) (In reply to comment #4) > NB: This bug breaks the "eject" command. In Ubuntu 9.10 the "eject" command > works despite this bug. I forgot to mention that this bug also breaks "xine" which uses /dev/dvd by default. Maybe a better way would be to file bugs against "eject" and "xine" -- but I don't know the buzz-words -- gvfs? hal? -- that would be needed to say: "eject" and "xine" do not use such-and-such a feature, but instead rely on udev-generated links that may change or disappear. There may be one more case though: I have a back-up script that uses wodim. The script passes /dev/cdrom to wodim. Recently, I tried running wodim without an explicit device name and wodim found /dev/sr0. That is good enough for me. (In reply to comment #6) > Recently, I tried running wodim without an explicit device name and wodim found > /dev/sr0. That is good enough for me. Also, totem, rhythmbox and brasero work without those /dev links. What is their trick? (In reply to comment #7) > (In reply to comment #6) > > Recently, I tried running wodim without an explicit device name and wodim found > > /dev/sr0. That is good enough for me. > > Also, totem, rhythmbox and brasero work without those /dev links. > What is their trick? maybe they look after /dev/sr* or /dev/cdrom* or even /proc/sys/dev/cdrom/info :-) (In reply to comment #5) > ah, well, I will not fix this "bug", because it's intentionally designed that > way, so if you connect e.g. USB cdroms, they will get the same name, regardless > of the ordering you plug them in.. I am new to udev. Is that intention anywhere documented? In particular, I need some info about how the assignment of /dev/cdrom* and the corresponding mount points is designed. Thanks in advance! Created attachment 398047 [details]
70-persistent-cd.rules with three optical drive records; from F12 system
/etc/udev/rules.d/70-persistent-cd.rules from my F12 system.
There are three optical drive records in this file. The first two records are for exactly the same drive. I am guessing that is because I replaced my motherboard but did not reinstall F12. With the first MB, the drive was the only device on its IDE bus. With the second MB, the drive is a slave on the IDE bus shared with a hard drive master. The third record is for a SATA optical drive with the new MB. I also had a different IDE optical drive in the system with the second MB while investigating CD I/O errors, but it is not recorded at all.
In all cases, there was only one optical drive in the system at any time.
# DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-1:0:1:0)
# DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-2:0:1:0)
# iHAS424_Y (pci-0000:00:11.0-scsi-3:0:0:0)
Created attachment 398053 [details]
70-persistent-cd.rules with five optical drive records; from F12
/etc/udev/rules.d/70-persistent-cd.rules from my F12 system.
As an experiment, I shut down my system, moved the SATA plug to the optical drive over to the next SATA connector on the motherboard, restarted. Did that again.
Now I have five optical drives in 70-persistent-cd.rules:
# DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-1:0:1:0)
# DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-2:0:1:0)
# iHAS424_Y (pci-0000:00:11.0-scsi-3:0:0:0)
# iHAS424_Y (pci-0000:00:11.0-scsi-2:0:0:0)
# iHAS424_Y (pci-0000:00:11.0-scsi-1:0:0:0)
[stephent@walnut ~]$ ls -ld /dev/* | grep 'sr[0-9]'
lrwxrwxrwx 1 root root 3 2010-03-05 05:18 /dev/cdrom4 -> sr0
lrwxrwxrwx 1 root root 3 2010-03-05 05:18 /dev/cdrw4 -> sr0
lrwxrwxrwx 1 root root 3 2010-03-05 05:18 /dev/dvd4 -> sr0
lrwxrwxrwx 1 root root 3 2010-03-05 05:18 /dev/dvdrw4 -> sr0
lrwxrwxrwx 1 root root 3 2010-03-05 05:17 /dev/scd0 -> sr0
brw-rw----+ 1 root cdrom 11, 0 2010-03-05 05:17 /dev/sr0
[stephent@walnut ~]$
I forgot to move the SATA plug back to where it was before the experiment in Comment 12. After I booted into my fresh F13 install, /dev/cdrom did not exist. Here is a simple work-around for this problem -- tested with F13: $ su -c 'rm /etc/udev/rules.d/70-persistent-cd.rules' $ reboot udev regenerates 70-persistent-cd.rules with a single drive entry: # iHAS424_Y (pci-0000:00:11.0-scsi-1:0:0:0) /dev/cdrom exists and "eject" works as expected. [stephent@spruce ~]$ rpm -q udev udev-151-3.fc13.x86_64 (In reply to comment #13) > Here is a simple work-around for this problem -- tested with F13: > $ su -c 'rm /etc/udev/rules.d/70-persistent-cd.rules' > $ reboot Works with F12 too ... [stephent@walnut ~]$ rpm -q udev udev-145-15.fc12.x86_64 Created attachment 398086 [details]
screenshot of xine when /dev/dvd is missing; the dvd is mounted though
xine is also affected by this problem. If /dev/dvd does not exist, xine displays the two errors shown in this screenshot.
This is with F12.
(In reply to comment #15) > Created an attachment (id=398086) [details] > screenshot of xine when /dev/dvd is missing; the dvd is mounted though > > xine is also affected by this problem. If /dev/dvd does not exist, xine > displays the two errors shown in this screenshot. > > This is with F12. Surprise surprise - any software using a device that does not work will fail. I don't understand why you added me to the cc list. PS. You can change the dvd device from xine configuration options. (In reply to comment #16) > (In reply to comment #15) > > Created an attachment (id=398086) [details] [details] > > screenshot of xine when /dev/dvd is missing; the dvd is mounted though > > > > xine is also affected by this problem. If /dev/dvd does not exist, xine > > displays the two errors shown in this screenshot. > > > > This is with F12. > > Surprise surprise - any software using a device that does not work will fail. I > don't understand why you added me to the cc list. Because xine should "just work" with the default settings. > PS. You can change the dvd device from xine configuration options. Yes, I know ... If you prefer, I can open a bug against xine like the one against "eject". :-) Bug 570561 - "eject" fails after optical drive replaced And you don't need to get sarcastic. (In reply to comment #12) > Created an attachment (id=398053) [details] > 70-persistent-cd.rules with five optical drive records; from F12 > > /etc/udev/rules.d/70-persistent-cd.rules from my F12 system. > > As an experiment, I shut down my system, moved the SATA plug to the optical > drive over to the next SATA connector on the motherboard, restarted. Did that > again. > > Now I have five optical drives in 70-persistent-cd.rules: > > # DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-1:0:1:0) > # DVDRW_SHW-160P6S (pci-0000:00:14.1-scsi-2:0:1:0) > # iHAS424_Y (pci-0000:00:11.0-scsi-3:0:0:0) > # iHAS424_Y (pci-0000:00:11.0-scsi-2:0:0:0) > # iHAS424_Y (pci-0000:00:11.0-scsi-1:0:0:0) > > [stephent@walnut ~]$ ls -ld /dev/* | grep 'sr[0-9]' > lrwxrwxrwx 1 root root 3 2010-03-05 05:18 /dev/cdrom4 -> sr0 > lrwxrwxrwx 1 root root 3 2010-03-05 05:18 /dev/cdrw4 -> sr0 > lrwxrwxrwx 1 root root 3 2010-03-05 05:18 /dev/dvd4 -> sr0 > lrwxrwxrwx 1 root root 3 2010-03-05 05:18 /dev/dvdrw4 -> sr0 > lrwxrwxrwx 1 root root 3 2010-03-05 05:17 /dev/scd0 -> sr0 > brw-rw----+ 1 root cdrom 11, 0 2010-03-05 05:17 /dev/sr0 > [stephent@walnut ~]$ works as intended (In reply to comment #18) ,,, > works as intended Well, it breaks xine and eject. They could be called legacy apps., but as you can read in comment 16, that is not going to change. Modern apps. search for the device or offer a GUI asking what device to use (e.g. brasero). My current workaround is to remove 70-persistent-cd.rules, disable its regeneration in /lib/udev/rules.d/75-cd-aliases-generator.rules, explicitly pass "eject" the device name, and not use xine (totem works fine without any of those device links -- I am still studying how it finds the device without them). Indeed, I wonder why those udev-generated links are needed at all? From 75-cd-aliases-generator.rules, it looks like the "usb|ieee1394" case is handled separately. BTW, /dev/scd0 is still being generated -- maybe "eject" could search for that. [stephent@walnut rules.d]$ cat /lib/udev/rules.d/75-cd-aliases-generator.rules # these rules generate rules for the /dev/{cdrom,dvd,...} symlinks # the "path" of usb/ieee1394 devices changes frequently, use "id" ACTION=="add", SUBSYSTEM=="block", SUBSYSTEMS=="usb|ieee1394", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", \ PROGRAM="write_cd_rules by-id", SYMLINK+="%c", GOTO="persistent_cd_end" #ACTION=="add", SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", PROGRAM="write_cd_rules", SYMLINK+="%c" LABEL="persistent_cd_end" Created attachment 400437 [details] 70-persistent-cd.rules generated with "write_cd_rules by-id" I have a simple fix for the case in comment 12. Use "write_cd_rules by-id" instead of "write_cd_rules" in /lib/udev/rules.d/75-cd-aliases-generator.rules. With this change, I can move my single optical drive from one SATA port on the motherboard to another and still get /dev/cdrom. How can this be further fixed so that if there is only one optical drive in the system, it always gets /dev/cdrom? That would fix this bug. [stephent@walnut rules.d]$ cat /lib/udev/rules.d/75-cd-aliases-generator.rules # these rules generate rules for the /dev/{cdrom,dvd,...} symlinks # the "path" of usb/ieee1394 devices changes frequently, use "id" ACTION=="add", SUBSYSTEM=="block", SUBSYSTEMS=="usb|ieee1394", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", \ PROGRAM="write_cd_rules by-id", SYMLINK+="%c", GOTO="persistent_cd_end" #ACTION=="add", SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", PROGRAM="write_cd_rules", SYMLINK+="%c" ACTION=="add", SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{GENERATED}!="?*", PROGRAM="write_cd_rules by-id", SYMLINK+="%c" LABEL="persistent_cd_end" Here's an even better solution, IIUC:
# 70-persistent-cd.rules
SUBSYSTEM=="block", ENV{ID_CDROM}=="1", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="1", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="1", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="1", SYMLINK+="dvdrw", ENV{GENERATED}="1"
This was hand edited -- something I swore I was not going to do. :-)
If write_cd_rules could generate these rules when there is only one optical drive in the system, I believe that would fix this bug and the case in
comment 12. (I'm assuming ID_CDROM is always "1" when there is only one optical drive in the system -- is that valid?)
The solution in comment 20 doesn't entirely work, because two identical optical drives would match this part:
ENV{ID_MODEL}=="iHAS424_Y", ENV{ID_REVISION}=="ZL1U"
The fundamental problem is that optical drives may not have serial numbers or UUIDs. Compare:
$ udevadm info --query=all --name=sr0
$ udevadm info --query=all --name=sda1
I'm still trying to figure out what to do when there is more than one optical drive -- which one should "eject" work on?
Bug 190037 - "eject" command opens different drive in FC5
"ID_CDROM" seems to be a boolean ...
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM}=="1", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw", ENV{GENERATED}="1"
Writing udev rules
CD/DVD drives
http://www.reactivated.net/writing_udev_rules.html#example-cdrom
This does almost everything right with two optical devices. What it lacks is a way to remap in one line which device gets /dev/cdrom. ATM, "sr0" would have to be changed in five places. An arbitrary mapping would be more general, but overkill for the problem at hand (and I don't know how to implement one anyway :-) ). If /dev/cdrom0 is acceptable in addition to /dev/cdrom, the GOTO could be eliminated. NB: For testing, I have disabled write_cd_rules as in comment 19 and have put these in 70-persistent-cd.rules. This is probably not the right file ... SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM}=="1", SYMLINK+="cdrom", ENV{GENERATED}="1" SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1", SYMLINK+="cdrw", ENV{GENERATED}="1" SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1", SYMLINK+="dvd", ENV{GENERATED}="1" SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw", ENV{GENERATED}="1" SUBSYSTEM=="block", KERNEL=="sr0", ENV{GENERATED}="1", GOTO="cd_rules_end" SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM}=="1", SYMLINK+="cdrom%n", ENV{GENERATED}="1" SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_CD_RW}=="1", SYMLINK+="cdrw%n", ENV{GENERATED}="1" SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_DVD}=="1", SYMLINK+="dvd%n", ENV{GENERATED}="1" SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw%n", ENV{GENERATED}="1" LABEL="cd_rules_end" [stephent@walnut dev]$ ls -l /dev | grep 'sr[0-9]' lrwxrwxrwx 1 root root 3 2010-03-16 13:20 cdrom -> sr0 lrwxrwxrwx 1 root root 3 2010-03-16 13:20 cdrom1 -> sr1 lrwxrwxrwx 1 root root 3 2010-03-16 13:20 cdrw -> sr0 lrwxrwxrwx 1 root root 3 2010-03-16 13:20 dvd -> sr0 lrwxrwxrwx 1 root root 3 2010-03-16 13:20 dvd1 -> sr1 lrwxrwxrwx 1 root root 3 2010-03-16 13:20 dvdrw -> sr0 lrwxrwxrwx 1 root root 3 2010-03-16 13:20 scd0 -> sr0 lrwxrwxrwx 1 root root 3 2010-03-16 13:20 scd1 -> sr1 brw-rw----+ 1 root cdrom 11, 0 2010-03-16 13:20 sr0 brw-rw----+ 1 root cdrom 11, 1 2010-03-16 13:20 sr1 [stephent@walnut dev]$ (In reply to comment #23) > If /dev/cdrom0 is acceptable in addition to /dev/cdrom, the GOTO could > be eliminated. If there were three optical devices, and the "middle" one (sr1) were the default, the rules in comment 23 would produce: cdrom0 -> sr0 cdrom -> sr1 cdrom2 -> sr2 IOW, there would be a "hole" in the sequence. NB: I am a udev rules noob ... This bug also affects abcde (Bug 527123, Comment 3), which searches for a cdrom in these places (abcde is a shell script): # If the CDROM has not been set yet, find a suitable one. # If this is a devfs system, default to /dev/cdroms/cdrom0 # instead of /dev/cdrom if [ "$CDROM" = "" ] ; then if [ -e /dev/cdroms/cdrom0 ]; then CDROM=/dev/cdroms/cdrom0 elif [ -e /dev/cdrom ]; then CDROM=/dev/cdrom elif [ -e /dev/cd0c ]; then CDROM=/dev/cd0c elif [ -e /dev/acd0c ]; then CDROM=/dev/acd0c elif [ -e /dev/disk1 ]; then CDROM=/dev/disk1 fi fi The -d option allows a device to be specified: [stephent@walnut ~]$ abcde -h This is abcde v2.3.99.8. ... -d <device> Specify CDROM device to grab (flac uses a single-track flac file) abcde uses the eject command: EJECT=eject This version adds a fallback handler in case the chosen default device does not exist (e.g. it was removed). Added comments to guide the user in changing the default device.
Tested with one and two devices and with sr0, sr1, and sr9 as the default device. Verify generated links with:
$ ls -l /dev | grep 'sr[0-9]'
# change the default device by changing sr0 to srN in this section
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM}=="1", SYMLINK+="cdrom", ENV{GENERATED}="1", link_priority=1
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1", SYMLINK+="cdrw", ENV{GENERATED}="1", link_priority=1
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1", SYMLINK+="dvd", ENV{GENERATED}="1", link_priority=1
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw", ENV{GENERATED}="1", link_priority=1
SUBSYSTEM=="block", KERNEL=="sr0", ENV{GENERATED}="1", GOTO="cd_rules_end"
# end of default device rules
# if the default device does not exist, fall back to sr0
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM}=="1", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_CD_RW}=="1", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD}=="1", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr0", ENV{GENERATED}="1", GOTO="cd_rules_end"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM}=="1", SYMLINK+="cdrom%n", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_CD_RW}=="1", SYMLINK+="cdrw%n", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_DVD}=="1", SYMLINK+="dvd%n", ENV{GENERATED}="1"
SUBSYSTEM=="block", KERNEL=="sr[0-9]*", ENV{ID_CDROM_DVD_RW}=="1", SYMLINK+="dvdrw%n", ENV{GENERATED}="1"
LABEL="cd_rules_end"
Created attachment 400876 [details]
udev rules to generate default device links for optical devices
/etc/udev/rules.d/70-dynamic-cd.rules
I have been calling this file 70-dynamic-cd.rules because it is a supplement to, not a replacement for, /etc/udev/rules.d/70-persistent-cd.rules
?? why don't you simply change 70-persistent-cd.rules instead of introducing a new file, which has to be changed? maybe changing the rule generator with link_priority=1 and adding the fallback would be a solution (In reply to comment #28) > ?? why don't you simply change 70-persistent-cd.rules instead of introducing a > new file, which has to be changed? Thanks for your comments. The short answer is that, for testing, I didn't want write_cd_rules possibly mangling my rules file. The long answer is that I don't know how to integrate the two (write_cd_rules and 70-dynamic-cd.rules) -- they are both creating cdrom[0-9]* links ... It isn't clear how to get the rules in 70-dynamic-cd.rules into 70-persistent-cd.rules initially. One way would be to not, but instead to add them to /lib/udev/rules.d/75-cd-aliases-generator.rules. Also, 70-dynamic-cd.rules doesn't exactly create "persistent" device links. (In reply to comment #29) > maybe changing the rule generator with link_priority=1 and adding the fallback > would be a solution OK. How would it work to put the first two blocks into 75-cd-aliases-generator.rules, drop the last block, and drop the second write_cd_rules rule in 75-cd-aliases-generator.rules (the one that causes all the trouble :-))? I am fuzzy on some of the requirements: Is it a requirement that a persistent rule be able to generate "cdrom"? When there is more than one optical device, is it a requirement that "cdromN" links be created for them? Is it OK for "cdrom" to link to one device and "dvd" to link to another device? (AKA, mix-and-match :-)) Created attachment 401232 [details]
70-default-cd.rules -- udev rules to generate default device links for optical devices
/etc/udev/rules.d/70-default-cd.rules
Rules to generate optical device links "cdrom", "cdrw", "dvd", "dvdrw".
These links are used by some applications as default devices (e.g. eject, xine, abcde).
This file is intended to be user-configurable.
The following patch ensures that write_cd_rules does not generate rules that create links with the same names.
/lib/udev/write_cd_rules
[stephent@walnut udev]$ rcsdiff -u write_cd_rules
===================================================================
RCS file: RCS/write_cd_rules,v
retrieving revision 1.1
diff -u -r1.1 write_cd_rules
--- write_cd_rules 2010/03/19 11:15:51 1.1
+++ write_cd_rules 2010/03/19 12:07:11
@@ -97,6 +97,11 @@
link_num=$(find_next_available 'cdrom[0-9]*')
+# Ensure that "cdrom0" is generated instead of "cdrom".
+# find_next_available may return an empty string instead of "0".
+# This hack restores the "0".
+link_num=${link_num:-"0"}
+
match="SUBSYSTEM==\"block\", ENV{ID_CDROM}==\"?*\", $RULE"
comment="$ID_MODEL ($ID_PATH)"
In the single-device case, the rules and patch in comment 32 produce redundant links. Is that a problem? [stephent@walnut dev]$ ls -l /dev | grep 'sr[0-9]*' lrwxrwxrwx 1 root root 3 2010-03-19 05:08 cdrom -> sr0 lrwxrwxrwx 1 root root 3 2010-03-19 05:08 cdrom0 -> sr0 lrwxrwxrwx 1 root root 3 2010-03-19 05:08 cdrw -> sr0 lrwxrwxrwx 1 root root 3 2010-03-19 05:08 cdrw0 -> sr0 lrwxrwxrwx 1 root root 3 2010-03-19 05:08 dvd -> sr0 lrwxrwxrwx 1 root root 3 2010-03-19 05:08 dvd0 -> sr0 lrwxrwxrwx 1 root root 3 2010-03-19 05:08 dvdrw -> sr0 lrwxrwxrwx 1 root root 3 2010-03-19 05:08 dvdrw0 -> sr0 srw-rw-rw- 1 root root 0 2010-03-19 05:08 log lrwxrwxrwx 1 root root 3 2010-03-19 05:07 scd0 -> sr0 brw-rw----+ 1 root cdrom 11, 0 2010-03-19 05:07 sr0 (In reply to comment #28) > ?? why don't you simply change 70-persistent-cd.rules instead of introducing a > new file, which has to be changed? A user should be able to remove 70-persistent-cd.rules and restart to regenerate a fresh 70-persistent-cd.rules. If a user has customized the file, this simple procedure could result in data loss. Machine-generated files and user-configurable files should be kept separate -- hence 70-default-cd.rules. This opinion is based on having had my customized /etc/fstab trashed many times in the past by updates. I never did figure out who was doing the trashing ... fstab never gets trashed on my system... 70-persistent-cd.rules is designed for user modifications (In reply to comment #35) > fstab never gets trashed on my system... Last time, I couldn't figure out happened to my swap space ... Another time, my nfs mount disappeared ... > 70-persistent-cd.rules is designed for user modifications Yes. And it achieves that by requiring the user to put ENV{GENERATED}="1" on every line. udev is already hard enough to understand without this additional complexity. Also, "GENERATED" is a misleading and confusing name. If the rules generated by write_cd_rules were the only ones with it, that would makes sense. A user editing 70-persistent-cd.rules is not generating rules, yet has to lie by saying the additional rules were also "generated". I much prefer this advice from /etc/sysconfig/iptables : # Manual customization of this file is not recommended. BTW, I sometimes ignore that advice. :-) This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. Reopening against F14. udev-161-8.fc14.x86_64 Reproduce by moving SATA cable to a different port. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |