I have an old RedHat5 server I can't upgrade the OS and new san XtremeI/O storage EMC recommended to install device-mapper-multipath 0.4.9-72 as a native multipath package.But the only available package on Redhat 5 is device-mapper-multipath 0.4.7-64. So, if I manually installed device-mapper-multipath 0.4.9-72 on redhat5 it will be compatible or it will appear a problem on top?
1 Answers
Have you tried getting the storage to work with the version of device-mapper-multipath natively shipped with Red Hat 5? It might work and besides Red Hat 5 is EOL so it's unlikely any vendor is going to support it these days anyway.
If you're talking about installing the device-mapper-multipath package from a newer release of Red Hat, (6 or 7), then I would say it's unlikely to work as the binaries in that package will have been compiled against a newer release of glibc and other libraries and it probably also expects a specific version of the kernel too, after all that's the primary purpose of the package.
Try test-installing the new package, (with rpm --test -Uvh ...
), if it complains about missing dependencies then you can always resort to using --force
and/or --nodeps
but then you are potentially damaging the RPM database for any future package installs, and the binaries may not work anyway.
You can also try taking the SRPM of the newer package and recompiling/rebuilding it on the target Red Hat 5 system however the compilation may fail if the dependencies aren't the right version.

- 4,751
- 16
- 27
-
Personally, I wouldn't even try installing newer multipath drivers on such an old OS, especially one that "can't be upgraded". That implies to me that there's likely no real backups nor recovery plan should the server die, and installing something as low-level as a **device driver** that, as you say, "will have been compiled against a newer release of glibc and other libraries and it probably also expects a specific version of the kernel too" is really extremely risky and probably a really good way to create an unbootable system. – Andrew Henle Aug 16 '18 at 14:03