Comment # 20 on bug 1218618 from Franck Bui

From your logs, it seems that systemd-vconsole-setup can find /dev/tty1, the
only allocated console (dev/vcs2+ don't exist yet), but it's already taken by
plymouth, which has set it to graphic mode: 

> Jan 30 10:40:46 **REDACTED** systemd-vconsole-setup[1086]: Failed to check VC /dev/tty1 display mode: Device or resource busy
> Jan 30 10:40:46 **REDACTED** systemd-vconsole-setup[1086]: VC 2 existance check failed, skipping: No such file or directory
> Jan 30 10:40:46 **REDACTED** systemd-vconsole-setup[1086]: VC 3 existance check failed, skipping: No such file or directory
> ...
> Jan 30 10:40:46 **REDACTED** systemd-vconsole-setup[1086]: VC 63 existance check failed, skipping: No such file or directory

In this situation systemd-vconsole-setup complains that it can't find any other
free source console to setup and fails. Note that a bunch of VCs is
pre-allocated by logind hence if systemd-vconsole-setup is run again after
logind is activated (but tty1 is still busy), s-v-s will be happy this time to
find a VC (tty2 for example) to configure.

On my setup, the problem doesn't occur because when systemd-vconsole-setup is
launched, after switching root and plymouth was started again, the boot process
is fast enough (or plymouth slow enough) to make plymouth not show the boot
splash at all. And in this case s-v-s finds tty1 in text mode.

Anyway I think that in this specific case s-v-s should not return a failure
when it's asked to configure any potential free tty it may find but all
allocated ttys are already busy, just logging a message should be fine.

I'll send a patch to upstream that does that.