Description of problem: journalctl highlights errors in red. It would be nice if a default install could avoid having any red messages. udisks1 generates spurious errors at boot time: Feb 25 09:26:14 fossil.scree.dyndns.org systemd-udevd[527]: failed to execute '/usr/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:1f.1': No such file or directory ... Feb 25 09:26:14 fossil.scree.dyndns.org systemd-udevd[528]: failed to execute '/usr/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:1f.2': No such file or directory According to https://bugs.archlinux.org/task/32825, "the error is harmless so we just need to remove the offending rules". (Or make them conditional on udev having loaded the needed data already, perhaps?) Version-Release number of selected component (if applicable): Name : udisks Arch : x86_64 Version : 1.0.4 Release : 8.fc18 Size : 685 k Repo : installed How reproducible: On every boot Steps to Reproduce: 1. Boot computer 2. Run journalctl -b 3. Page down, looking for red lines Actual results: spurious error message as above Expected results: This error message should not be displayed Additional info: According to https://bugs.archlinux.org/task/32825, "the error is harmless so we just need to remove the offending rules". (Or make them conditional on udev not having loaded the needed data already, perhaps?)
I think it also happened on Fedora 17. (And the F17 udisks rules look like they try to execute an external pci-db, and there's no /lib/udev/pci-db in F17 either).
Same error here. udisks: udisks-1.0.4-8.fc18.x86_64 It tries to execute pci-db from a rule: grep pci-db /usr/lib/udev/rules.d/* /usr/lib/udev/rules.d/80-udisks.rules:SUBSYSTEM=="pci", ACTION=="add|change", ENV{ID_MODEL_FROM_DATABASE}=="", ATTR{class}=="0x01*", IMPORT{program}="pci-db %p" It seems to import names for PCI storage controllers, as indicated in the file as a comment.
I have encounter the same problem when I tried to create a backup from udev device and script my udev rule looks like this : KERNEL="*", ACTION=="add", SUBSYSTEMS=="usb", ATTRS{serial}=="NA0LN5H5", ATTRS{manufacturer}=="Seagate", SYMLINK+=”backup”, RUN+="/usr/local/sbin/syncit.sh" and the error from /var/log/messages is : Apr 7 20:56:29 bagira systemd-logind[753]: Watching system buttons on /dev/input/event1 (Power Button) Apr 7 20:56:29 bagira systemd-logind[753]: Watching system buttons on /dev/input/event0 (Power Button) Apr 7 20:56:29 bagira systemd-udevd[15305]: failed to execute '/usr/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:06.0': No such file or directory Apr 7 20:56:29 bagira systemd-udevd[15306]: failed to execute '/usr/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:07.0': No such file or directory Apr 7 20:56:29 bagira systemd-udevd[15307]: failed to execute '/usr/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:08.0': No such file or directory Apr 7 20:56:29 bagira systemd-udevd[15313]: failed to execute '/usr/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:09.0/0000:01:08.0': No such file or directory Apr 7 20:56:29 bagira kernel: [198062.073414] AMD64 EDAC driver v3.4.0 Apr 7 20:56:29 bagira kernel: [198062.073460] EDAC amd64: DRAM ECC disabled. Apr 7 20:56:29 bagira kernel: [198062.073465] EDAC amd64: ECC disabled in the BIOS or no ECC capability, module will not load. Apr 7 20:56:29 bagira kernel: [198062.073465] Either enable ECC checking or force module loading by setting 'ecc_enable_override'. Apr 7 20:56:29 bagira kernel: [198062.073465] (Note that use of the override may cause unknown side effects.) Apr 7 20:56:29 bagira kernel: [198062.103263] microcode: AMD CPU family 0xf not supported thanks in advanced
Hello Again, I notice where my problem was : SUBSYSTEM=="block", SUBSYSTEMS=="usb", ATTRS{idVendor}=="0bc2", ATTRS{idProduct}=="xxxx", RUN+="/usr/local/sbin/run_backup.sh %N" I didn't wrote SUBSYSTEM insted of SUBSYSTEMS after I fix that everything worked but the logs massages are still showing I have notice a nice example of how to write a new code: http://superuser.com/questions/294671/how-do-i-get-udev-to-mount-certain-usb-disks-when-they-are-plugged-in-or-after maybe this will help. best regards
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. 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.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 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. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.