So the issue with the server not starting seems to be the same one as https://bugzilla.redhat.com/show_bug.cgi?id=1301164 which was fixed upstream, but not backported. I have applied this fix to a test server but am still unable to get to the UI and am seeing the following in production.log [----] I, [2016-04-05T16:54:49.606592 #2025:47598c] INFO -- : Started GET "/dashboard/authenticate?button=login&method=post" for 127.0.0.1 at 2016-04-05 16:54:49 -0400 [----] F, [2016-04-05T16:54:49.614213 #2025:47598c] FATAL -- : ActionController::RoutingError (No route matches [GET] "/dashboard/authenticate"): actionpack (4.2.6) lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call' actionpack (4.2.6) lib/action_dispatch/middleware/show_exceptions.rb:30:in `call' railties (4.2.6) lib/rails/rack/logger.rb:38:in `call_app' railties (4.2.6) lib/rails/rack/logger.rb:22:in `call' actionpack (4.2.6) lib/action_dispatch/middleware/request_id.rb:21:in `call' rack (1.6.4) lib/rack/methodoverride.rb:22:in `call' rack (1.6.4) lib/rack/runtime.rb:18:in `call' activesupport (4.2.6) lib/active_support/cache/strategy/local_cache_middleware.rb:28:in `call' rack (1.6.4) lib/rack/lock.rb:17:in `call' actionpack (4.2.6) lib/action_dispatch/middleware/static.rb:120:in `call' actionpack (4.2.6) lib/action_dispatch/middleware/static.rb:120:in `call' rack (1.6.4) lib/rack/sendfile.rb:113:in `call' railties (4.2.6) lib/rails/engine.rb:518:in `call' railties (4.2.6) lib/rails/application.rb:165:in `call' rack (1.6.4) lib/rack/content_length.rb:15:in `call' thin (1.6.3) lib/thin/connection.rb:86:in `block in pre_process' thin (1.6.3) lib/thin/connection.rb:84:in `catch' thin (1.6.3) lib/thin/connection.rb:84:in `pre_process' thin (1.6.3) lib/thin/connection.rb:53:in `process' thin (1.6.3) lib/thin/connection.rb:39:in `receive_data' eventmachine (1.0.7) lib/eventmachine.rb:187:in `run_machine' eventmachine (1.0.7) lib/eventmachine.rb:187:in `run' thin (1.6.3) lib/thin/backends/base.rb:73:in `start' thin (1.6.3) lib/thin/server.rb:162:in `start' rack (1.6.4) lib/rack/handler/thin.rb:19:in `run' rack (1.6.4) lib/rack/server.rb:286:in `start' railties (4.2.6) lib/rails/commands/server.rb:80:in `start' railties (4.2.6) lib/rails/commands/commands_tasks.rb:80:in `block in server' railties (4.2.6) lib/rails/commands/commands_tasks.rb:75:in `tap' railties (4.2.6) lib/rails/commands/commands_tasks.rb:75:in `server' railties (4.2.6) lib/rails/commands/commands_tasks.rb:39:in `run_command!' railties (4.2.6) lib/rails/commands.rb:17:in `<top (required)>' bin/rails:4:in `require' bin/rails:4:in `<main>'
https://github.com/ManageIQ/manageiq/pull/7754
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/adba6b7391c4a474d0416d1cfe42a974028b8b7c commit adba6b7391c4a474d0416d1cfe42a974028b8b7c Author: Nick Carboni <ncarboni> AuthorDate: Wed Apr 6 14:43:25 2016 -0400 Commit: Nick Carboni <ncarboni> CommitDate: Wed Apr 6 14:43:25 2016 -0400 Hardcode the assets manifest file name This will allow us to update the assets without concern for what the previous manifest file was named. Before, when `rake evm:compile_assets` was run in the kickstart the manifest would be regenerated, creating a new filename. Updating leads to multiple manifest files being present which in some cases causes the asset pipeline to use the incorrect manifest. https://bugzilla.redhat.com/show_bug.cgi?id=1324202 config/application.rb | 3 +++ 1 file changed, 3 insertions(+)
Assigning to Satoe for additional changes.
verified in 5.6.0.5-beta2.4
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/RHBA-2016:1348