Comment 4 for bug 1795882

 - the casper service is racing plymouth; it doesn't wait for plymouth-reboot.service to have started before it checks to see if plymouth is available, so if plymouth is slow to start up, casper may write its message only to the console.
 - casper is writing to a different tty than the one plymouth runs on, because plymouth in shutdown mode defaults to running on tty63 - not tty1 which was used for everything at boot, and which casper writes its 'backup' message to.
 - if you do change VTs to tty1 and see the 'fallback' message telling you to reboot, you can't just press enter, because we're only listening to plymouth in this case, and not the tty. This is why a different message is displayed (as Dimitri mentions).
 - because we're calling plymouth --ping at two different times, we can actually get two different answers, especially since we're currently racing. So you can wind up with casper only writing the message to the console, and then listening for an answer via plymouth, and nobody's happy.

I think it is important that we fix the race by ensuring the casper service always starts after plymouth-reboot.service. I've raised an MP for this.

But I don't know if that's actually going to fix the bug reported here (which seems to actually be a metabug, describing different symptoms on UEFI vs BIOS).

Jean-Baptiste, can you please clarify:
 - what environment you see this behavior in (KVM? VirtualBox? Bare metal? UEFI or BIOS?)
 - what is the exact message you see on the console when you press alt-right 5 times