Our school’s local LUG had an InstallFest this past weekend. I encountered and solved a problem with RHEL/CentOS and extra repositories with conflicting dependencies for media players like vlc and mplayer which seems to be rather common, so I decided to document it here.

I’m a Debian user, so I’m used to having a very large set of packages in the base repositories. On a typical Debian desktop system of mine, I may have the base repos with main, contrib and non-free plus debian-multimedia.org (and backports.org and volatile.debian.org on servers running stable). On RHEL, the set of base packages is much smaller; CentOS (plus the CentOS plus) has a little bit more but basically the same issues. So people tend to add a bunch of other repositories like the EPEL, rpmforge, RPM Fusion, or individual repos included in those umbrellas like Dries, DAG, Livna, etc. With the proliferation of repositories comes duplicated effort and problems with mutual compatibility.

For example, consider loading a RHEL 5.4 system from scratch and adding the EPEL and rpmforge repos:

• Install EPEL: rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm
• Install rpmforge: rpm -Uvh http://packages.sw.be/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.`uname -m`.rpm [0]

On CentOS I would now add yum-priorities (yum install yum-priorities) and set relative priorities for the different repos. But either way, let’s say you now try to install vlc with yum install vlc and it explodes with the following:

vlc-0.9.9a-3.el5.rf.x86_64 from rpmforge has depsolving problems
  --> Missing Dependency: libcucul.so.0()(64bit) is needed by package vlc-0.9.9a-3.el5.rf.x86_64 (rpmforge)
vlc-0.9.9a-3.el5.rf.x86_64 from rpmforge has depsolving problems
  --> Missing Dependency: libdvdread.so.3()(64bit) is needed by package vlc-0.9.9a-3.el5.rf.x86_64 (rpmforge)
Error: Missing Dependency: libdvdread.so.3()(64bit) is needed by package vlc-0.9.9a-3.el5.rf.x86_64 (rpmforge)
Error: Missing Dependency: libcucul.so.0()(64bit) is needed by package vlc-0.9.9a-3.el5.rf.x86_64 (rpmforge)

Why is this happening? Well, for the libcucul.so.0 dependency, the EPEL packages libcaca, and so does rpmforge, but they are not entirely substitutable (there’s a similar problem with libdvdread). Usually I trust the EPEL more (and give it a better priority) since it is more “official” and Redhat-endorsed (and has high quality packaging standards), but in this case we need to satisfy all of the dependencies from rpmforge. So, I use the following command:
yum --disablerepo='epel' install vlc

For the system at the InstallFest, it was even more complex because it had the EPEL, rpmforge and RPM Fusion and some packages from each. I had to disable all but rpmforge and install libcaca and caca-utils and then disable RPM Fusion to properly install vlc (and first I had to remove the libcaca package that was pulled in from the EPEL). yum was developed in part to resolve “rpm dependency hell”, but these warring packaging factions are causing the same problems to be exposed again to the user through yum, which is frustrating.

[0] Right now packages.sw.be seems to be broken in some places so you can grab from say http://mirror.cpsc.ucalgary.ca/mirror/dag/redhat/el5/en/`uname -m`/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.`uname -m`.rpm

So we got a new storage box in our lab with a Supermicro X8DT3 motherboard and a bunch of 15k SAS drives. The motherboard comes with an integrated LSI 1068E SAS controller and lspci identifies it as an “LSI Logic / Symbios Logic MegaRAID SAS 8208ELP/8208ELP.” The primary user of the system had a bit of trouble getting the damn thing to work in Linux, though, so I investigated the issue.

So apparently there’s a few different drivers that could support the card, and they all have their quirks. Some people have had success with the open-source and in-kernel megaraid driver, and LSI provides some 1068E Linux drivers on their site. Their drivers are the semi-closed mptsas drivers, but they do provide the source and dkms support, so they can be recompiled against different kernels (provided they aren’t changed to the point where stuff breaks).

Our problem was that the mptsas driver was compiling and loading fine but we weren’t seeing any disks. It turns out the integrated X8DT3 has two modes controlled by a hardware jumper: SR mode (Software RAID Mode) and IT (Integrated Target Mode). SR mode is the default, and that is where the card exports logical arrays to the host OS, but the mptsas driver doesn’t seem to work in that mode. In IT mode, the card just exports individual drives, and the mptsas driver works fine. However, the primary user didn’t want individual drives, he wanted the logically configured arrays (yes, I’m aware that Linux md/software RAID could have probably done just as good a job as the LSI controller’s SR mode, but I wanted to see if I could get it to work in SR mode).

Anyway, a blog post that informed me about the IT/SR mode distinctions had a pointer to Supermicro’s FTP site, and there I found some promising “SR” drivers. I had seen references to a megasr closed source driver in some forum posts, but I couldn’t find it from LSI (at least not a RHEL5u3 version). Well, the megasr is apparently what is on Supermicro’s FTP site. I navigated to ftp://ftp.supermicro.com/driver/SAS/LSI/1064_1068/SR/Driver/Linux/ and grabbed a disk image for the version of RHEL 5 we’re using (luckily we hadn’t updated to the newly released 5.4, because there doesn’t seem to be an image for it). I grabbed the .img file and saw that it was a floppy image using the file command. I mounted it loopback and extracted the compiled megasr.ko using the following process:

• mount -o loop megasr-13.10.0708.2009-1-rhel50-u3-all.img /mnt/
• zcat /mnt/modules.cgz | cpio -idv

The last command will extract the modules to the current directory (making subdirectories for various kernel versions and architectures). The .img file is compiled for use with the RHEL installer, hence the floppy image format and the modules packed as a gzipped cpio archive. We had a working install on a standalone SATA disk and the SAS drives off of the controller were just going to be used for data storage, so we just needed to add the kernel module after the system was already installed.

So I removed the LSI provided modules (with rpm -e to remove the mptlinux dkms package), copied the appropriate megasr.ko to /lib/modules/`uname -r`/extra, ran depmod, rebooted and everything was finally working in SR mode. Luckily we were using RHEL — it looks like people who are using non-RHEL or SLES distros are out of luck because they don’t seem to provide source to recompile the module against vanilla (or other) Linux kernels.