Table of Contents
The Linux lsvpd package is a partial reimplementation, for Linux®, of some AIX® hardware inventory and configuration commands. The focus is on providing some of the same serviceability features when running Linux on IBM® pSeries® hardware as is provided by AIX. The main function is to list Vital Product Data (VPD) about hardware components, including systems, adapters and devices, in a variety of ways.
This documentation contains installations notes for the Linux lsvpd package. The focus is on making packagers and administrators aware of dependencies.
Linux lsvpd was originally written for IBM pSeries systems running the Linux 2.4 kernel (or newer). However, recent versions provide almost full functionality on other architectures by using features provided by the Linux 2.6 kernel.
Therefore, lsvpd provides little or no functionality on non-pSeries systems when running Linux <= 2.4.
RPM and DEB packages are built for systems where they can be tested.
The RPM packages are designed to work with the Red Hat and SUSE distributions, but might work with others. The RPM package does not initialise the database at installation time. Database initialisation is done at the next boot, or possibly by a cron(8) job. See rpm(8) for details of how to install RPM packages.
The DEB packages will hopefully run on Debian stable systems, although this is not generally tested. The database is initialised by the post-install script in the DEB packages. It is also rebuilt on reboot. See dpkg(8) or apt-get(8) for details of how to install DEB packages.
In all cases, see the details below to find out what will and won't work, depending on kernel version, architecture and availability of other software.
Binary executables, generated scripts, etc. can be built by running:
make
Most things can then be installed by running:
make install
These things are not installed include:
debian/init.d.
lsvpd.cron.daily is generated
during the make process.
Note that there is no configure script.
libsgutils.a has been part of the
sg3_utils
package since (about) version 1.09. This library is used
to retrieve VPD from SCSI devices. Static linking is used
to avoid a runtime dependency.
Currently none of the distributions' packages contain
libsgutils.a (although SLES-10 may
include it). The sg3_utils site has a
source archive, a source RPM package, and a binary RPM
package for i386.
/bin/bash (version >= 2)
Standard Linux commands:
Of these, the FHS (Filesystem Hierarchy Standard) requires
all but find, grep and
sort to reside in
/bin. In practice, most distributions
(including Red Hat and SuSE, but not Debian (for
sort)) also have grep
and sort in /bin.
Therefore, given the requirement for find, there are two possible scenarios:
/usr filesystem is available,
so /usr/bin/find exists.
/lib/lsvpd/find
is made that points to busybox.
Under Debian, similar requirements exist to ensure the availability of sort.
In the long term, the best choice seems to be to depend on busybox. This involves monitoring the options available to the busybox command implementations, since busybox doesn't generally implement a full range of (either POSIX-compliant or GNU-compatible) options. Commands should only use options that are available in busybox's find command.
This section lists and explains dependencies that help lsvpd provide useful functionality, and therefore more information.
Under Linux 2.4 lsvpd uses the sg_map command from the sg3_utils package to list SCSI devices. lsvpd used to also use the sg_inq command to retrieve VPD, but no longer does so. Without the sg_map, no SCSI devices will be listed by lsvpd under Linux 2.4.
The various distributions currently handle sg3_utils in different ways:
Note that the standard packages install
sg_map in /usr/bin,
so the issues discussed in Section 3.1, “Core” are
relevant. In this case, sg_map may be
copied into /lib/lsvpd at installation
time if operation without a /usr
filesystem is required.
See Section 2.3.1.1, “libsgutils.a” for more details about sg3_utils.
The current implementation requires a writable
/var. More exactly, it needs to be able
to work in a directory called
/var/lib/lsvpd.
Under Linux 2.6 recent versions of lsvpd
use sysfs to get information about
adapters that allows the operating system's name for the
adapter to be matched with, say, a node in the device-tree.
The current implementation uses the sysfs
devspec property to link to device-tree
nodes.
Under Linux 2.4 things are more difficult. Various techniques are used to get PCI address information for adapters and this information is used to locate device-tree nodes to get VPD information. However, there are some serious limitations.
On `bignum' pSeries machines (those with multiple PCI host buses), the kernel needs to ensure the node for each bus contains a property that contains that PCI domain. On pSeries machines the Linux 2.4 ppc64 kernel behaves as follows...
PCI bus numbers can contain more than 8-bits (although not
necessarily consistently) and
linux,phbnum properties are created
in the device-tree containing the top 24 bits of the bus
number (and this is essentially equivalent to the
2.6 PCI domain). Older versions may create
linux,global-number properties, or
may not have the associated functionality at all.
The Linux lsvpd package needs PCI bus
information about adapters. This is done by parsing
information in SCSI host adapter information files, such
as /proc/scsi/sym53c8xx/0.
Therefore, under Linux, 2.4, if information about both a SCSI host adapters and its associated devices is missing, this may be due to a missing or incorrect template for the SCSI host adapter.
Another possibility, under Linux 2.4 and on `bignum' machines, is that SCSI host adapter information files may only contain the bottom 8 bits of the PCI bus number. A workaround adds additional matching using the interrupt number - this works in many cases, but not all.
Unfortunately, it is impossible to implement full, reliable matching.
PCI address information for Ethernet adapters is retrieved using the ethtool ioctl interface. As with methods for retrieving PCI bus information from SCSI host adapters, this interface sometimes returns an incomplete bus number, so it is impossible to implement full, reliable matching.
On x86 systems that use the ServerWorks IDE chip-set,
information about the IDE controller in
sysfs and procfs
is not useful (PCI bus information can not be determined)
unless the ServerWorks driver is built-in to the kernel.
If the driver is built as a module, inserting it makes the
appropriate information appear in
procfs, but doesn't sufficiently
reorganise sysfs to be totally
useful. This means that programs in the
lsvpd package will be unable to find
information about the IDE controller and will not be able
to display some information about associated devices.