$Id: install.xml,v 1.8 2004/05/10 06:18:00 martins Exp $
Copyright © 2003, 2004 IBM Corporation
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 the same level of serviceability 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:
Note that there is no configure script.
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:
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. At the moment lscfg uses options that are not available in busybox's find command.
This section lists and explains dependencies that help lsvpd provide useful functionality, and therefore more information.
VPD is retrieved from SCSI devices using commands from the sg3_utils package (version >= 1.01). Without this package, no SCSI device VPD will be seen. The various distributions currently handle sg3_utils in different ways:
The sg3_utils site has a source archive, a source RPM package, and a binary RPM package for i386.
Note that the standard packages install the required commands (sg_inq, sg_map, sg_scan) in /usr/bin, so the issues discussed in Section 3.1, “Core” are relevant. In this case, they may be copied into /lib/lsvpd at installation time if operation without a /usr filesystem is required.
If running under Linux 2.4 and the ethtool command is available, it will be used to assist in the correct naming of Ethernet adapters. Under Linux 2.6 ethtool is not required, as the required information is taken from sysfs. As ethtool is usually installed in /usr/sbin the discussion about /usr/bin in Section 3.1, “Core” is relevant. As with sg3_utils, the command could be copied into /lib/lsvpd at installation time if operation without a /usr filesystem is required.
The current implementation requires a writable /var. More exactly, it needs to be able to work in a directory called /var/lib/lsvpd.
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 ppc64 kernel behaves as follows:
The Linux lsvpd package needs PCI bus information about adapters. Under Linux 2.6, this is done via sysfs. Under Linux 2.4, 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 has worked in all cases so far, but this method is not guaranteed to be 100% reliable.
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.