www.linuxbase.org -> Sample Implementation -> Setting up the LSB-si

Setting Up and Configuring the LSB Sample Implementation

The LSB Sample Implelmentation (LSB-si) is a minimal LSB-conforming runtime environment. The LSB Certification program requires an application to be cross-checked in the LSB-si.

Installing the Base LSB-si

The LSB-si is distributed in several pieces: a base tarball which should simply be unpacked as root; some add-on tarballs which can be unpacked inside the tree created by the base tarball; and as an installable package providing the hosted (user-mode Linux) environment as a complete bundle.

For illustrative purposes, the ia32 (x86) architecture, version 1.3.0, will be used in the examples - subsititue the appropriate LSB architecture and version.

  # cd /opt
  # tar -xvjf path-to/lsbsi-ia32-1.3.0.tar.bz2

The tarball will unpack under a directory lsbsi.


Preparing to Run the Base LSB-si

Since the LSB-si is started by running the chroot command, only files inside the chroot tree will be accessible. Since the package to be tested will need to be available to install it, steps must be taken ahead of time to set this up. Some notes on this may be found at Copying files and Bind mounts.


Entering the LSB-si

The base LSB-si is started by running the /sbin/chroot command. (Some distributions may place it in /usr/sbin).

  # /sbin/chroot /opt/lsbsi

To simulate a login session, try:

  # /sbin/chroot /opt/lsbsi /bin/bash -l

Special considerations for the chroot

The pure chroot is missing many useful things since it limits itself to items required by the LSB spec. While this has some benefits, it also means there are likely to be some surprising or problematic areas. Here are a few that might come up:

Mounts

The rpm tool needs access to /proc to calculate disk space (the mounted file system table found through /proc. However, /proc is not part of the LSB spec. The simplest workaround is to add a line describing it to the LSB-si's /etc/fstab so that you can simply say mount /proc. This is an example line, it's probably best to simply copy the line from /etc/fstab on the host system:

  none  /proc  proc  defaults  0 0

Depending on your requirements, you may also need to do similar things for other pseudo-filesystems such as /dev/shm and /dev/pts.

Missing tools

Lots of commands you may be used to will be missing, including editors. The developers have found it useful to work in a windowed environment, with one window running the LSB-si chroot and others set up to be able to edit and otherwise modify files, should it be necessary.

Networking

For networked applications, some additional support is probably needed. For example, the /etc/services file is not described by the LSB, and thus is not present in the chroot. If needed, simply copy over from the host system.

Also, if a server (daemon) is to be tested, it will need to be set up to (a) listen on the appropriate port and (b) any conflicting service on the host system must be disabled so the connection actually reaches the daemon in the LSB-si chroot.

The LSB-si does not have an inetd or xinetd, so these cannot be used to set up listening for the service requests. The lsb-test package can be installed to provide inetd.


Augmenting the LSB-si with lsb-test

A supplementary package is available that primarily provides support for running the LSB Runtime Test Suite; however, it may be useful for other purposes. This package contains:

  • inetd
  • syslogd
  • ext2/ext3 utilities
  • telnet server
  • losetup
  • pax

To install, grab the lsb-test tarball and unpack it inside the LSB-si, before starting the chroot.

  # cd /opt/lsbsi
  # tar -xvjf path-to/lsbsi-test-ia32-1.3.0.tar.bz2

Building a Bootable System from the LSB-si

The base tarball plus the lsbsi-boot tarball make an almost-complete standalone bootable system. Here are the steps to build a bootable LSB-si partition on an already-bootable system. You will need to augment further to put these on a "fresh" system.

Locate an unused partition and make an appropriate file system on it (ext2, ext3, reiser, etc.)

  # mkdir /mnt/lsbsi
  # mount empty-partition /mnt/lsbsi
  # cd /mnt
  # tar -xvjf path-to/lsbsi-ia32-1.3.0.tar.bz2
  # cd lsbsi
  # tar -xvjf path-to/lsbsi-test-ia32-1.3.0.tar.bz2

This partition will now contain most of a runnable system. There are a few things that need to be done to it, such as building the correct file system mount table, and setting up a kernel that works appropriately for this system.

Here are the remaining steps:

  1. Handcraft an appropriate /etc/fstab which describes the root filesystem, swap (if any) and any additional mounts, remembering special filesystems such as /proc, /dev/pts, etc.
  2. Copy over the modules directory matching a bootable kernel that already works on this system. Something like:
      # cp -r /lib/modules/2.4.18-24.8.0 /mnt/lsbsi/lib/modules
    
  3. Copy over a working /etc/modules.conf or similar, as appropriate for the system you will be running.
      # cp /etc/modules.conf /mnt/lsbsi/etc
    
  4. Add instructions to boot the kernel of your choice, and using the appropriate partition to boot to. For example, to boot using lilo, you might add the following to /etc/lilo.conf:
    image=/boot/vmlinuz-2.4.18-24.8.0
            label=lsbsi-boot
            root=/dev/sda9
            initrd=/boot/initrd-2.4.18-24.8.0.img
            read-only
    
    If you're using a bootloader such as lilo that requires running a command to install the new configuration, don't forget to do so!

Setting up the UML LSB-si

to be written


Root Password

All of the LSB-si bundles come configured with an initial root password of: lsbsi123


Last modified 2003-08-15 mats wichmann