after upgrade to v103, the following scripts in /etc/udev/rules.d needed manual modification due to the location change of supporting programs such as cdrom_id, from /sbin to /lib/udev: udev.rules 50-udev.rules
/etc/udev/rules.d/udev.rules is not installed by udev (or anything else for that matter, delete the orphaned file). # grep cdrom_id /etc/udev/rules.d/50-udev.rules BUS=="ide", KERNEL=="hd[a-z]", ACTION=="add", IMPORT="cdrom_id --export $tempnode" BUS=="scsi", KERNEL=="sr[0-9]*", ACTION=="add", IMPORT="cdrom_id --export $tempnode" BUS=="scsi", KERNEL=="scd[a-z]", ACTION=="add", IMPORT="cdrom_id --export $tempnode" You didn't run etc-update, seems like...
*** Bug 156507 has been marked as a duplicate of this bug. ***
I have run etc-update, and your knee-jerk reaction to closing this bug should result in your bug-wrangling license revocation.
and if I delete the files in question, what will re-create them???
and, if there are orphan files, that is still a bug
(In reply to comment #3) > I have run etc-update, and your knee-jerk reaction to closing this bug > should result in your bug-wrangling license revocation. I don't like your attitude, folk. Already explained above, wipe the orphaned files, re-emerge udev, run etc-update. You can use 'qfile /etc/udev/rules.d/*' to find the orphaned files and owners of the rest of the files there.
and I don't like your attitude either... your tone is hostile and dismissive And what tool scans the whole system for orphan files, and why are orphan package files not a bug?
emerge portage-utils if you don't have qfile
This is a bug.
Your orphaned files issue belongs to Bug 8423.
NOT a udev bug, closing.
And enough noise here.
Another hostile, dismissive, and this time inflammatory comment. Congrats, a new low for you. You must be proud. The package update resulted in a system that did not run udev correctly. Furthermore, it did not fix the paths in 50-udev.rules until I manually corrected them and rebooted. This is a package update bug that should be addressed in a -r1 of udev. Perhaps you can finally answer the question as to what tool scans the entire system for orphan package files? If its is unused, why wasn't it removed at package update? And why is the failure to remove it not a bug? And your workaround of manual file removal and re-emerge is not a solution.
Stop reopening this bug, there's no /sbin cdrom_id reference, as shown in comment #1. If you screwed up w/ etc-update, it's not a bug.
Closed, and don't reopen this bug unless you want to have your bugzilla account suspended. You've already produced 20 pointless bugspams in my mailboxes, not appreciated.
Charles, perhaps you should say what you changed to fix.
(In reply to comment #16) > Charles, perhaps you should say what you changed to fix. There's no need to change _anything_ if you update your udev rules properly via etc-update or dispatch-conf or whatever other tool $ grep sbin /usr/portage/sys-fs/udev/files/udev.rules-098 #KERNEL=="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK+="%c" SYSFS{modalias}=="?*", ACTION=="add", RUN+="/sbin/modprobe $env{MODALIAS}" SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", RUN+="/bin/sh -c 'while read id; do /sbin/modprobe pnp:d$$id; done < /sys$devpath/id'" The above all _all_ references to /sbin in 50-udev.rules installed w/ udev-103. Now, can we please finally stop the pointless noise here?
if your assertion were true, I would not have had the trouble, since I did, in fact, run etc-update.
Then try to select the correct option in etc-update next time. # rm -f /etc/udev/rules.d/50-udev.rules; emerge -1 udev; grep /sbin /etc/udev/rules.d/50-udev.rules <snip> >>> sys-fs/udev-103 merged. >>> No packages selected for removal by clean. >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. #KERNEL=="dm-[0-9]*", PROGRAM="/sbin/devmap_name %M %m", NAME="%k", SYMLINK+="%c" SYSFS{modalias}=="?*", ACTION=="add", RUN+="/sbin/modprobe $env{MODALIAS}" SUBSYSTEM=="pnp", ENV{MODALIAS}!="?*", RUN+="/bin/sh -c 'while read id; do /sbin/modprobe pnp:d$$id; done < /sys$devpath/id'" </snip> Now, absolutely no need for further comments here. If you need support, move to forums.gentoo.org or #gentoo on freenode. This is not a support forum and there's no such issue in udev-103 as you claim.
This was part of an emerge -bNDu world. I wonder what you would counsel to update thousands of machines? Should every individual update require individual attention? Really? And was there even a warning for this package, to do this special procedure as part of the 23 updates applied in this batch? If you want to have the last word, little man, go ahead, but please stop CC'ing me on this. I have had quite enough of you, and will do everything I can do avoid you in the future. I left the bug closed as you requested, but it is still a bug. And you are way out of line in your treatment of me, and owe me an apology. When you grow up, please email me one. Apparently, I am not alone in my opinion of you.
(In reply to comment #20) > If you want to have the last word, little man, go ahead, but please stop > CC'ing me on this. WTF? Where did I CC you? http://bugs.gentoo.org/show_activity.cgi?id=156505 Here's a suggestion: could you move your rants to /dev/null finally? Or somewhere else, but definitely out of bugzilla and out of my mailbox. TIA.
