Summary: | =sys-fs/udev-171-r9: Backport the persistent generator removal from git (was: Does not create 70-persistent-cd.rules or /dev/cdrom) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthew Schultz <mattsch> |
Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander, billie, Ikonta, rdalek1967, tomaszg, tomwij |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 437418 |
Description
Matthew Schultz
2012-11-24 19:02:01 UTC
Purposely made change *** This bug has been marked as a duplicate of bug 433746 *** Reopen if the *persistent* files still end up in /etc/udev/rules.d/ somehow and we can take care of removing them They are not compatible with latest kernels, like stable gentoo-sources At least the 70-persistent-cd.rules are still generated after rebooting. I have a wlan stick and two dvd drives which did look like this when generated # DVD-RW_DVR-212 (pci-0000:00:1f.2-scsi-0:0:1:0) SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:1:0", SYMLINK+="cdrom", ENV{GENERATED}="1" # TSSTcorpCD_DVDW_SH-S183L (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" # WLAN_selfinstall (pci-0000:00:1d.7-usb-0:2:1.0-scsi-0:0:0:0) SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_SERIAL}=="FRITZ__WLAN_selfinstall_BC0543069EA3-0:0", SYMLINK+="cdrom2", ENV{GENERATED}="1" After missing the dvd symlinks I removed the 70-persistent-cd.rules to see if they are generated after a reboot. The file is generated but only with the entry for the wlan stick. (In reply to comment #1) > Purposely made change > > *** This bug has been marked as a duplicate of bug 433746 *** So since the rule generator went away, what does the rule_generator use flag do then? Also, how is /dev/cdrom created now? Do I have to manually write a rule for it? (In reply to comment #4) > (In reply to comment #1) > > Purposely made change > > > > *** This bug has been marked as a duplicate of bug 433746 *** > > So since the rule generator went away, what does the rule_generator use flag > do then? Also, how is /dev/cdrom created now? Do I have to manually write > a rule for it? Also if I'm supposed to write rules manually for this now, where do I place the rules so that they are read because -r9 won't even read the persistent cd rules that are already there to create /dev/cdrom. (In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #1) > > > Purposely made change > > > > > > *** This bug has been marked as a duplicate of bug 433746 *** > > > > So since the rule generator went away, what does the rule_generator use flag > > do then? Also, how is /dev/cdrom created now? Do I have to manually write > > a rule for it? > > Also if I'm supposed to write rules manually for this now, where do I place > the rules so that they are read because -r9 won't even read the persistent > cd rules that are already there to create /dev/cdrom. In addition, is the new manual process documented somewhere on gentoo docs? After another reboot both cd and the net rules are re-generated. I also have the same questions like Matthew. Additionally regarding the cdrom symlinks. How should they be generated. I think this is different to the network interfaces as there is no conflict in naming with kernel namespace. Also it are symlinks instead of renames. On the other hand are the cdrom symlinks still needed. Are there any programs out which require them? (In reply to comment #7) > On the other hand are the cdrom symlinks still needed. Isn't that the point of udev which is to create a standardized way to access devices? >Are there any programs out which require them? Not so much required as far as I know but will make your life miserable by having to do extra configuration to override defaults: Some programs which default to /dev/cdrom: mplayer mythtv kmplayer In addition gentoo handbook mentions /dev/cdrom as the location of that device. Udev-195 will create /dev/cdrom. It does not create /dev/dvd, /dev/cdrw, etc. If the old udev rules are not compatible with modern kernels, this might be a reason to upgrade your udev. (In reply to comment #9) > Udev-195 will create /dev/cdrom. It does not create /dev/dvd, /dev/cdrw, etc. > If the old udev rules are not compatible with modern kernels, this might be > a reason to upgrade your udev. I'm using gentoo-sources 3.6 and it works fine with 171-r8 but not with 171-r9. Installing 171 also does not warn of an incompatibility with 3.6. How is /dev/cdrom created in 195 if the rule generator went away? (In reply to comment #10) > (In reply to comment #9) > > Udev-195 will create /dev/cdrom. It does not create /dev/dvd, /dev/cdrw, etc. > > If the old udev rules are not compatible with modern kernels, this might be > > a reason to upgrade your udev. > > I'm using gentoo-sources 3.6 and it works fine with 171-r8 but not with > 171-r9. Installing 171 also does not warn of an incompatibility with 3.6. > How is /dev/cdrom created in 195 if the rule generator went away? Looking at the rules, it looks like cdrom is always a symlink to sr0. I don't know what udev would do on a box where sr0 did not exist. (In reply to comment #11) > Looking at the rules, it looks like cdrom is always a symlink to sr0. I > don't know what udev would do on a box where sr0 did not exist. The same issue on amd64 system. sys-fs/udev-171-r9 $ uname -svr Linux 3.5.7-gentoo-2 #3 SMP Wed Nov 7 10:17:42 MSK 2012 CD-ROM device exists: $ file /dev/sr0 /dev/sr0: block special No symbolic link created $ file /dev/cdrom /dev/cdrom: ERROR: cannot open `/dev/cdrom' (No such file or directory) Rules generator don't work (i.e. removed /etc/udev/rules.d/70-persistent-cd.rules isn't recreated after reboot and was ignored when present). I see /lib/udev/rules.d/75-cd-aliases-generator.rules file: # 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" But don't find in my system mentioned utulity write_cd_rules (so, this file seems to be incorrect). P.S. /etc/udev/rules.d/70-persistent-net.rules also seems to become ignored. (In reply to comment #9) > Udev-195 will create /dev/cdrom. It does not create /dev/dvd, /dev/cdrw, etc. > If the old udev rules are not compatible with modern kernels, this might be > a reason to upgrade your udev. Yeah, sorry about this, didn't expect this change to break this feature from udev at all. Therefore -r9 solves one problem, while introducing another. Now that council has somewhat agreed that we can stabilize newer udev, like 196-r1, I would suggest anyone having this issue to upgrade immediately. We are still working on minor problems, like kmod not reading /usr/lib/modprobe.d, but otherwise it's solid. Fixed by 197-r{2,3}. Arch's are CCd to the stabilization bug. No need to keep this open. Time to upgrade. |