Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Installation occasionally fails: failed to call refresh: /usr/sbin/foreman-rake db:seed returned 1 instead of one of [0] with "Validation failed: Name has already been taken" in katello-installer.log
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
Moving to POST since upstream bug http://projects.theforeman.org/issues/7353 has been closed
-------------
Ivan Necas
Applied in changeset commit:puppet-foreman|dcde67122d8151e16b905201196a764671f0d63d.
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.
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
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