Inspect Installed Buses through /proc/bus

/proc/bus lists the bus interfaces the running kernel has actually found, not what a spec sheet claims. This guide covers listing what is exposed, reading the PCI device file, and knowing when to reach for lspci or setpci instead of parsing procfs by hand. Everything here is read-only. Budget ten minutes, and expect the exact directories and device list to differ between machines.

This uses the installed proc_bus(5) page from Linux man-pages 6.7-2, on a Linux 6.8.0-139-generic kernel. The interface it describes comes straight from the kernel, so its contents are host-specific by design. You need a shell; none of the normal examples need elevated privileges.

1. List the bus interfaces that exist

Start at the directory the manual page names:

$ find /proc/bus -maxdepth 2 -print 2>/dev/null | sort
/proc/bus
/proc/bus/input
/proc/bus/input/devices
/proc/bus/input/handlers
/proc/bus/pci
/proc/bus/pci/00
/proc/bus/pci/devices

Your list can be shorter or longer. What matters is that /proc/bus/ holds subdirectories for buses this kernel has installed and chosen to expose. A missing directory is not proof the physical bus does not exist: kernel configuration, hardware, virtualisation and procfs visibility all shape what shows up here.

$ test -d /proc/bus && echo '/proc/bus is present'
/proc/bus is present

2. Inspect the PCI device file

The manual names /proc/bus/pci/devices as the PCI device information file. Read a handful of lines rather than dumping a file of unknown size straight into your terminal:

$ head -n 5 /proc/bus/pci/devices
0000	8086591f	0	               0	               0	               0	               0
0010	80865912	b	        ee000004	               0	        d000000c	               0
00a0	8086a12f	7c	        ef020004	               0	               0	               0

Each line is a kernel-generated record, not a stable report format you should write your own parser against. The first fields identify a PCI location and device ID; the rest carry resource information. Spacing and field count are kernel-version details that can move under you. If you need a stable, human-facing inventory, skip ahead to the next step.

A procfs file can report zero bytes to stat even though a read returns real records, because procfs generates the content at read time:

$ stat -c '%F %s bytes %n' /proc/bus/pci/devices
regular empty file 0 bytes /proc/bus/pci/devices

That is not an ordinary empty file. Do not copy it, truncate it or try to edit it: it is a live interface onto kernel state, not a file on disk.

3. Use lspci for a readable inventory

The proc_bus(5) page notes that the PCI device file may be accessed through lspci(8). Here lspci is version 3.10.0:

$ command -v lspci
/usr/bin/lspci
$ lspci
00:00.0 Host bridge: ...
00:02.0 VGA compatible controller: ...

Those device names and addresses only show the shape of the output, not a promise about your hardware. If the plain output is more than you need, add one display option at a time rather than reaching for a flag you have not read about. For a script or report that needs machine-readable records, check lspci's own documentation for a supported format before you go anywhere near the private spacing of /proc/bus/pci/devices.

To tie a device to its kernel driver, add the driver display option:

$ lspci -k
00:00.0 Host bridge: ...
	Kernel driver in use: ...

The ellipses stand in for your host's real device and driver names. A missing driver line is something to go investigate, not a reason to start writing to procfs.

4. Treat setpci as a hardware-change boundary

The same manual page names setpci(8) as another way into PCI device information, and it is a different order of risk from an inventory command, because PCI configuration-space writes can affect hardware behaviour directly. Confirm the utility and read its help before you touch it:

$ command -v setpci
/usr/bin/setpci
$ setpci --help 2>&1 | head -n 12
Usage: setpci [options] <config operations>

Where options are:
...

5. Check for PCMCIA without assuming it is there

The manual describes /proc/bus/pccard/ as the PCMCIA directory, present only when the kernel was built with CONFIG_PCMCIA. Test for it explicitly instead of assuming either way:

$ if test -d /proc/bus/pccard; then
    printf '%s\n' 'PCMCIA procfs interface is present'
    find /proc/bus/pccard -maxdepth 2 -print
else
    printf '%s\n' 'No /proc/bus/pccard directory is exposed'
fi
No /proc/bus/pccard directory is exposed

On a modern machine, a missing directory usually just means PCMCIA support is not built in or exposed. Do not create the directory yourself: procfs entries come from the kernel, and a hand-made directory here would carry no actual bus information.

Common wrong assumptions

• /proc/bus missing entirely? Check whether procfs is mounted at all before you suspect PCI specifically.
• No row from findmnt /proc? The problem is bigger than PCI. Ask your platform administrator how procfs is mounted rather than creating directories under /proc yourself; mounting filesystems is an administrative job that can affect services, and it is deliberately outside this read-only guide.
• /proc/bus/pci exists but the device list differs from another machine? Compare kernel, virtual machine configuration and hardware. This file describes the running host, not a shared inventory database.
• A command cannot read a procfs entry? Record the exact error and check permissions and security policy before reaching for root. Running as root can paper over an access problem while hiding the reason ordinary monitoring failed.

$ findmnt /proc
TARGET SOURCE FSTYPE OPTIONS
/proc  proc   proc   rw,nosuid,nodev,noexec,relatime