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@redhat.com>
AuthorDate: Wed Apr 6 14:43:25 2016 -0400
Commit:     Nick Carboni <ncarboni@redhat.com>
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