Bug 916926 - udisks1 spurious error in journal: failed to execute '/usr/lib/udev/pci-db: no such file or directory
Summary: udisks1 spurious error in journal: failed to execute '/usr/lib/udev/pci-db: n...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: udisks
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Dan Mashal
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-01 09:30 UTC by Alan Jenkins
Modified: 2014-02-05 19:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-05 19:34:13 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Alan Jenkins 2013-03-01 09:30:08 UTC
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?)

Comment 1 Alan Jenkins 2013-03-01 09:38:36 UTC
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).

Comment 2 Heldwin 2013-03-23 20:11:42 UTC
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.

Comment 3 Oren Oichman 2013-04-07 17:57:16 UTC
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

Comment 4 Oren Oichman 2013-04-15 06:13:08 UTC
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

Comment 5 Fedora End Of Life 2013-12-21 11:47:25 UTC
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.

Comment 6 Fedora End Of Life 2014-02-05 19:34:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.