During MR12.8 testing a user had a system that caused the Initializer process to hang after an upgrade of the MR12.7 system to MR12.8. The hang occurred because the upgrade script entered admin mode, executed a pause command, and exited admin mode, but got "stuck" such that it never processed the "ame" command to exit admin mode.
Analysis of the problem revealed that the issue has nothing to do with MR12.8, or an upgrade of MR12.7 to MR12.8, but due to the specific conditions of the existing system disks (root.dsk), the above "admin", "pause 120", "ame" sequence, and a bug in the user-ring IPC implementation.
The MCR that addresses this issue will go into much more detail of the issue, but a very short summary is this: there exists a weakness in the implementation of user-ring IPC, such that the implementation of ipc_$block can loop in the user-ring, without ever calling ring-0 to retrieve additional events. This situation can be provoked by having the process, set up an event call handler which sends a wakeup its own process on the same event call channel as associated with the handler. This effectively causes an "unterminated loop" in ipc_$block repeatedly handling event call channel wakeups, and never getting a chance to call hcs_$read_events to retrieve additional wakeups, such as the one that the original call to ipc_$block was waiting on.
I've allocated MCR10138 for this ticket in SVE's MCRs forum.