Background: I got stuck on RDO packstack Kilo install onto CENTOS7. I got some strange log entries I didn’t understand – I post the problem and the solution here for my records and maybe to help someone else.
For my RDO packstack Kilo install setup, I followed the normal Quick Start steps on a bare metal installed version of CENTOS 7 (CentOS-7-x86_64-LiveKDE-1503).
I ran the following step in the install guide:
# packstack --allinone
The packstack installed failed with the following error on the console:
Error: Execution of '/usr/bin/rpm -e mariadb-server-5.5.41-2.el7_0.x86_64' returned 1: error: Failed dependencies: You will find full trace in log /var/tmp/packstack/20150704-200908-
This is an error pointing to the following log file entry:
Error: Execution of '/usr/bin/rpm -e mariadb-server-5.5.41-2.el7_0.x86_64' returned 1: error: Failed dependencies: mariadb-server is needed by (installed) akonadi-mysql-1.9.2-4.el7.x86_64
This is only my second install using packstack, and it is my first attempt at installing RDO packstack Kilo; so, I wasn’t familiar with the troubleshoot this kind of problem. It didn’t make sense to me that packstack would be trying to uninstall (rpm -e) MariaDB. The error indicates that the uninstall wouldn’t work because another package akonadi-mysql was using it — right? is that how I read this? FYI: Akonadi is a storage service that runs under KDE… I wasn’t familiar with it.
Browsing the RDO Workaround archives , I found a short article on this topic: Packstack fails when mariadb-server is installed. The body of the article shows a log file message that is different enough from mine that I didn’t find it right away.
I tried the recommended fix to uninstall MariaDB and re-run RDO packstack Kilo:
# yum remove mariadb-server # packstack --answer-file=packstack-answers-20150704-200908.txt
This fixed my problem!
I was able to run packstack to completion and bring up the openstack horizon dashboard. Note: I didn’t re-run packstack –allinone; I followed the packstack workflow requirement to re-run an install using the answer file previously generated.
Since the workaround was written for Juno and Fedora 20, I thought the fix was just a coincidence, but in reading the details, the original problem was triggered by installing KDE ontop of Fedora 20. Since I picked a KDE distribution of CENTOS7, maybe my problem and the original workaround write-up are related?!