Comment 6 for bug 1269073

If the test @Robie suggests above resolves the issue it might indicate that this commit below (which was introduced to improve security) might be the underlying change which makes this worse:

  commit 40db23e5337d99fda05ee6cd18034b516f8f123d
  Author: Theodore Ts'o <email address hidden>
  Date: Sun Nov 3 00:15:05 2013 -0400

    random: make add_timer_randomness() fill the nonblocking pool first

    Change add_timer_randomness() so that it directs incoming entropy to
    the nonblocking pool first if it hasn't been fully initialized yet.
    This matches the strategy we use in add_interrupt_randomness(), which
    allows us to push the randomness where we need it the most during when
    the system is first booting up, so that get_random_bytes() and
    /dev/urandom become safe to use as soon as possible.

    Signed-off-by: "Theodore Ts'o" <email address hidden>

Note that i has been suggested that the machine does come up if you wait long enough. If we take the contention that this is indeed entropy related then if an init job hangs the system boot progress (preventing ssh etc) as it is waiting on entropy then all sources of entropy will also be gone other than network. This implies that if you ping the machine in this phase or increase the rate of ssh attempts that the machine might boot faster; which would also be confirmatory of this conjecture.