Locking of the tty device and then /dev/console was added to synchronize
vconsole-setup with other writers to the console. But it turns out that often
the locking doesn't work and we carved out various cases where we ignore
failure:
- lack of permissions (in the user manager)
- missing device node
It turns out that there's at least one more failure mode: we get -EIO when the
console is (mis-)configured to point to an invalid device. E.g. in
rhbug#2273069 the reporter has a VM in Proxmox without a virtual console
configured and has 'console=tty console=ttyS0' on the kernel cmdline. I
couldn't reproduce this under libvirt, but failure with EIO has been reported
by at least four users in #30501.
Note that in systemd-vconsole-setup we report this is a hard failure, while
in the manager, we only do a debug line. So it's possible that the failure
also occured there, causing the rest of the setup of the tty to be skipped
without further notice.
Ignore the locking failure, since there's just too many ways it can fail. If we
proceed without a lock, we're back to the situation before we started locking,
which wasn't too bad. OTOH, skipping setup of the console is problematic for
users, and it seems better to try to do the setup without locking.
Fixes https://github.com/systemd/systemd/issues/30501,
https://bugzilla.redhat.com/show_bug.cgi?id=2273069.
Follow-up for 6b34871f5d.
The general idea is that the list of credentials to load can and will specify
credentials which actually aren't provided, so a warning is too much. Let's
downgrade this to "info". If it turns out to be too noisy, we can downgrade
further in the future.
