Linux lsvpd installation notes

Martin Schwenke

$Id: install.xml,v 1.8 2004/05/10 06:18:00 martins Exp $


Table of Contents

1. Introduction
2. Basic Installation Instructions
2.1. Basic Requirements
2.2. Installing Binary Packages
2.3. Installing From Source
3. Software dependencies
3.1. Core
3.2. Recommended
3.2.1. sg3_utils
3.2.2. ethtool
3.3. Suggested
3.3.1. dmidecode
4. Filesystem dependencies
4.1. /var
4.2. sysfs
5. Kernel dependencies
5.1. PCI domains
5.2. SCSI host information
5.3. ServerWorks /sysfs/procfs strangeness
6. Legal Statement

1. Introduction

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.

2. Basic Installation Instructions

2.1. Basic Requirements

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.

2.2. Installing Binary Packages

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.

2.3. Installing From Source

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:

  • General documentation (although man(1) pages are installed).
  • Init script(s). This is done differently on different systems. The recommended init script is in debian/init.d.
  • cron(8) job(s). lsvpd.cron.daily is generated during the make process.

Note that there is no configure script.

3. Software dependencies

3.1. Core

  • Linux 2.4 kernel or more recent.
  • /bin/bash (version >= 2)
  • Standard Linux commands:

    • cat
    • cp
    • date
    • dd
    • find
    • grep
    • ls
    • mkdir
    • mv
    • rm
    • sed
    • sort
    • uname

    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:

    • The /usr filesystem is available, so /usr/bin/find exists.
    • A dependency on busybox is added, and a link called /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. At the moment lscfg uses options that are not available in busybox's find command.

3.2. Recommended

This section lists and explains dependencies that help lsvpd provide useful functionality, and therefore more information.

3.2.1. sg3_utils

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:

  • SuSE integrate the commands from sg3_utils into their scsi package.
  • Red Hat do not appear to ship sg3_utils at all.
  • Debian has an sg3_utils package.

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.

3.2.2. ethtool

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.

3.3. Suggested

3.3.1. dmidecode

On x86 machines, the dmidecode command, if available, is used to retrieve certain information about the system. Currently this is only used to get machine type/model and serial number information.

4. Filesystem dependencies

4.1. /var

The current implementation requires a writable /var. More exactly, it needs to be able to work in a directory called /var/lib/lsvpd.

4.2. sysfs

On Linux 2.6, sysfs provides improved functionality. On non-pSeries systems sysfs is required to get useful functionality.

5. Kernel dependencies

5.1. PCI domains

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:

  • Under Linux 2.6, proper PCI domain support has been implemented and linux,pci-domain properties are created.
  • Under recent versions of Linux 2.4, PCI bus numbers can contain more than 8-bits (although not necessarily consistently) and linux,phbnum properties are created 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.

5.2. SCSI host information

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.

5.3. ServerWorks /sysfs/procfs strangeness

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.

6. Legal Statement

  • This work represents the view of the author and does not necessarily represent the view of IBM.
  • Linux is a registered trademark of Linus Torvalds.
  • IBM, AIX and pSeries are trademarks or registered trademarks of International Business Machines Corporation in the United States and/or other countries.
  • Other company, product, and service names may be trademarks or service marks of others.