Version-Release number of selected component (if applicable): katello-installer-0.0.64-1.el7sat.noarch How reproducible: rare Steps to Reproduce: yum install -y katello katello-installer Actual results: [...] [31m /Stage[main]/Foreman::Database/Foreman::Rake[db:seed]/Exec[foreman-rake-db:seed]: Failed to call refresh: /usr/sbin/foreman-rake db:seed returned 1 instead of one of [0] [0m[31m /Stage[main]/Foreman::Database/Foreman::Rake[db:seed]/Exec[foreman-rake-db:seed]: /usr/sbin/foreman-rake db:seed returned 1 instead of one of [0] [0mNotice: /Stage[main]/Foreman::Database/Foreman::Ra: 488/489, 99%, 0.0/s, elapsed: 00:07:03 [...] E, [2014-08-31T22:46:53.324338 #29233] ERROR -- : : 488/489, 99%, 0.0/s, elapsed: 00:12:33 [31m /Stage[main]/Foreman_proxy::Register/Foreman_smartproxy[ibm-ls22-03.rhts.eng.brq.redhat.com]: Could not evaluate: 500 Internal Server Error [0m[32mDone [0m: 489/489, 100%, 0.0/s, elapsed: 00:12:37 [32mDone [0m: 489/489, 100%, 0.0/s, elapsed: 00:12:37 [1m[31mSomething went wrong![0m Check the log for ERROR-level output The full log is at [1m[36m/var/log/katello-installer/katello-installer.log[0m :: [ FAIL ] :: Command 'katello-installer --foreman-admin-email 'root@localhost' --foreman-admin-username 'admin' --foreman-admin-password 'changeme'' (Expected 0, got 6) Expected results: Installer succeeds Additional info: The issue seems to be caused by race-condition in initializing the settings data (happen in an initializer). The httpd was sterted just before the db:seed (so that the rails environments started to be loaded at the same time, and probably started also filling the settings table: when initializing, the code first checks whether the settings are there, and if not, it creates them. It seems the case here is two parallel processes (on from passenger, the second form db:seed) look if some settings exist (bot get an information, that the settings are not there yet), so both try to create the settings, but the second one fails on conflict, because in the meantime, the first process have already managed to save that. Workaround: echo >> /etc/foreman/database.yml katello-installer
Created redmine issue http://projects.theforeman.org/issues/7353 from this bug
WORKAROUND: Clear the database.yml file: # echo >> /etc/foreman/database.yml Re-run the installer: # katello-installer
For the record, we are not clearing the yml file but rather changing it's MD5 content tag to trigger some actions in Puppet.
The fix should be part of https://github.com/theforeman/puppet-foreman/pull/225, but it seems we will need to go other direction (still not enough support for getting the changes in so far)
Moving to POST since upstream bug http://projects.theforeman.org/issues/7353 has been closed ------------- Ivan Necas Applied in changeset commit:puppet-foreman|dcde67122d8151e16b905201196a764671f0d63d.
The fix consists of (need to be applied in this order): https://github.com/theforeman/foreman/pull/1735 https://github.com/theforeman/puppet-foreman/pull/243 https://github.com/theforeman/puppet-foreman/pull/225
What is the corresponding upstream katello-installer commit?
Verified on: Satellite-6.1.0-RHEL-7-20150303.0 Steps to reproduce: Have been installing multiple times using recent versions of Satellite 6 on both RHEL 6.6 and RHEL 7.1 and was not able to raise that error. Seems that the bug is now fixed.
Just done a fresh deploy on a fully up to date RHEL 7.1 and hit this error.
This bug is slated to be released with Satellite 6.1.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2015:1592