RPM Support in a Recovery / Rescue Boot Environment

Q: How can I unpack RPM files onto a system I'm recovering under a rescue disk (boot floppy or CD-ROM)?

A: You need RPM support in your rescue environment.

Specifically, RPM is a mutable binary format which has had several major changes over its lifetime, and which requires specific library support, as discussed in "Maximum RPM":

http://www.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html

GNU/Linux Packaging Formats

Unlike other package formats (DEB, SLK, TGZ), RPM is not directly accessible via standard GNU/Linux tools such as ar, cpio, gzip, tar, and (at a stretch) bunzip2. Specific RPM libraries are required. In the constrained space allowed by removable media boot environments, particularly floppies, this represents significant overhead, about 655 KiB.

By contrast, it's possible to recover, say, a Debian system using only the tools available on a minimal boot floppy such as tomsrtbt, a proprietary Unix, or even legacy MS Windows systems with the addition of a small number of POSIX tools or Cygwin.

Library Dependencies

You can get a gross understanding of the issue by checking library dependencies of RPM tools. 'ldd' shows shared library dependencies for a binary executable. Starred libraries are RPM-specific support:

      $ ldd $( which rpm )
    * librpmbuild-4.0.4.so =3D> /usr/lib/librpmbuild-4.0.4.so (0x4002a000)
    * librpm-4.0.4.so =3D> /usr/lib/librpm-4.0.4.so (0x4005a000)
    * librpmdb-4.0.4.so =3D> /usr/lib/librpmdb-4.0.4.so (0x400a5000)
      libdb3.so.3 =3D> /usr/lib/libdb3.so.3 (0x400ba000)
    * librpmio-4.0.4.so =3D> /usr/lib/librpmio-4.0.4.so (0x40164000)
      libz.so.1 =3D> /usr/lib/libz.so.1 (0x401a2000)
      libbz2.so.1.0 =3D> /usr/lib/libbz2.so.1.0 (0x401b4000)
      libpopt.so.0 =3D> /lib/libpopt.so.0 (0x401c4000)
      librt.so.1 =3D> /lib/tls/librt.so.1 (0x401cd000)
      libpthread.so.0 =3D> /lib/tls/libpthread.so.0 (0x401d3000)
      libc.so.6 =3D> /lib/tls/libc.so.6 (0x401e2000)
      /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)

Storage requirement for the above on a recent Debian testing/unstable (Sarge) system:

      $ du -sch $( ldd $( which rpm ) | awk '/rpm/ {print $3}' )
      112K /usr/lib/librpmbuild-4.0.4.so 
      260K /usr/lib/librpm-4.0.4.so 
      72K /usr/lib/librpmdb-4.0.4.so 
      212K /usr/lib/librpmio-4.0.4.so 
      656K total

...or 39% of a 1.7 MiB floppy's storage capacity (the space available on a Tom's Root Boot floppy).

Another utility is 'alien', a perl script which gets its RPM-handling capabilities through Alien::Package::Rpm. That itself relies on rpm2cpio, for which we see a familiar library list:

      $ ldd $( which rpm2cpio )
    * librpmbuild-4.0.4.so =3D> /usr/lib/librpmbuild-4.0.4.so (0x4002a000)
    * librpm-4.0.4.so =3D> /usr/lib/librpm-4.0.4.so (0x4005a000)
    * librpmdb-4.0.4.so =3D> /usr/lib/librpmdb-4.0.4.so (0x400a5000)
      libdb3.so.3 =3D> /usr/lib/libdb3.so.3 (0x400ba000)
    * librpmio-4.0.4.so =3D> /usr/lib/librpmio-4.0.4.so (0x40164000)
      libz.so.1 =3D> /usr/lib/libz.so.1 (0x401a2000)
      libbz2.so.1.0 =3D> /usr/lib/libbz2.so.1.0 (0x401b4000)
      libpopt.so.0 =3D> /lib/libpopt.so.0 (0x401c4000)
      librt.so.1 =3D> /lib/tls/librt.so.1 (0x401cd000)
      libpthread.so.0 =3D> /lib/tls/libpthread.so.0 (0x401d3000)
      libc.so.6 =3D> /lib/tls/libc.so.6 (0x401e2000)
      /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)

There is a Perl-based rpm2cpio script which does not rely on Perl libs. However it requires a Perl installation, which is unlikely to be found on most common boot disks:

http://linuxmafia.com/pub/linux/utilities-general/rpm2cpio

Further research turns up an rpm2targz script by Patrick Volkering, of Slackware fame:

http://www.mirror.ac.uk/mirror/ftp.slackware.com/slackware-3.3/contrib/rpm2tgz.tgz

...though this program relies on an accompanying executable rpmofset to determine the appropriate offset to strip off the RPM file to find the embedded cpio archive. These methods also lose some of the functionality of RPM formats in ways which are easier to work around with DEBs, specifically pre/post installation/removal scripts.

For those who want to explore further, the magic string to look for is \037\213\010, the gzip file header.

So, while a minimal boot environment sufficies for many package systems, RPM-based system recover requires RPM support, namely, the RPM libs. Which lay a 656 KiB storage overhead on your system.

There are other utilities which can handle RPMs on non-'Nix platforms, including 7zip, a Free Software utility.

Why do you need this? To unpack the archives. I'm talking about building up a system from scratch, or after gross damage.

Compare with a DEB's requirements: ar & tar:

      $ ldd $( which ar )
      libbfd-2.15.so =3D> /usr/lib/libbfd-2.15.so (0x4002a000)
      libc.so.6 =3D> /lib/tls/libc.so.6 (0x400b9000)
      /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)

      $ ldd $( which tar )
      librt.so.1 =3D> /lib/tls/librt.so.1 (0x4002a000)
      libc.so.6 =3D> /lib/tls/libc.so.6 (0x40030000)
      libpthread.so.0 =3D> /lib/tls/libpthread.so.0 (0x4016c000)
          /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)

...all libc or binary utilities deps.

Moot point?

Some people might argue that this is a moot point: If your system is so old that it does not have a bootable CD-ROM, it might be time to upgrade to one built after 1996.

However bootable floppies offer one advantage over (most) bootable CDs: you free both the floppy and the CD-ROM after boot allowing additional data to be loaded through either drive, as the system runs entirely in memory. While this is possible with a CD-ROM, you need memory sufficient for the entire disk image in memory, and a boot option on the CD. That's ~50MB + for a mini/businesscard CD, 650-700 MiB+ for a full image. Given there's a lot of systems with ~128 - 512 MiB RAM (and the latter being a bit "beefy" for standard desktop deployment), in-memory bootable CDs are an iffy proposition. Of the major bootable distros (Knoppix, LNX-BBC, Damn Small Linux, MEPIS), only MEPIS supports a RAM boot that I'm aware. There are also significant numbers of server systems which don't have permanently attached removable storage. Because they are Kickstart or FAI installed, they do have a floppy.

While one can moot the issue endlessly, there's a lot of extant hardware for which these techniques work, and alternatives don't. The point is that by keeping the bar, requirements, and dependencies to a minimum, you're left with a lot of flexibility when using DEBs (or Slack packages, or anything else built out of standard shell tools). RPM loses in this regard.

KISS. You've heard of it?