lspci cannot load libkmod resources
Nobody has claimed this yet.
- Dominant language
- Makefile
- Stars
- 4.6k
- Forks
- 4k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 134
Description
Describe the bug
Running lspci -v >/dev/null gives partially correct output due to an inability to use libkmod.
# lspci -v >/dev/null
lspci: Unable to load libkmod resources: error -2
OpenWrt version
r23228-cd17d8df2a
OpenWrt target/subtarget
bcm27xx/bcm2711
Device
Raspberry Pi 4 Model B Rev 1.4
Image kind
Official downloaded image
Steps to reproduce
Run this command:
lspci -v > /dev/null
Actual behaviour
Running the above will print the following error and leave various generics in the actual output of the command whereas running the same command on another distro populates various generic statements about the hardware into vendor-specific data
lspci: Unable to load libkmod resources: error -2
Example of missing data:
On OpenWrt:
# lspci -v
...
03:00.0 Ethernet controller: Intel Corporation Device 125c (rev 04)
Subsystem: Intel Corporation Device 0000
...
On Arch:
# lspci -v
...
03:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
Subsystem: Intel Corporation Ethernet Controller I226-V
...
Expected behaviour
Expectation is for libkmod to work properly with lspci and to detect hardware.
Additional info
I have confirmed this bug on two different machines (x86/64 machine) and the rpi4 listed above running the official image for 23.05.0-rc2 and a very recent snapshot.
Diffconfig
No response
Terms
- I am reporting an issue for OpenWrt, not an unsupported fork.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing lspci -v > /dev/null on the reported OpenWrt targets and investigating how the lspci package accesses libkmod resources. Compare the output with the Arch example; the issue is done when the error is gone and hardware vendor-specific data is populated.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100