Comment # 19 on bug 1218618 from Tony Walker

Like Martin,

I see a few interesting journal entries...

I see some entries where the log source is mangled as if there is a pointer
arithmetic error or memory corruption somewhere in systemd, for example:
=> Jan 30 10:40:37 **REDACTED** (les-[317]: systemd-modules-load.service:
Executing: /usr/lib/systemd/systemd-modules-load
=> Jan 30 10:40:37 **REDACTED** (le-s[318]: systemd-vconsole-setup.service:
Executing: /usr/lib/systemd/systemd-vconsole-setup
I have grepped my journal entries without the debug kernel parameter and found
no entries like the above, so I can't say if this is really a bug or even
related to the bug report at hand.

The logs also remind me that I am using: 1) SELinux, 2) SDDM/Plasma, and 3)
TPM2 to unlock my disk. I doubt any of these matter, but...full disclosure.

I don't know enough to know if these entries are significant:
=> Jan 30 10:40:39 **REDACTED** systemd[1]:
run-credentials-systemd\x2dvconsole\x2dsetup.service.mount: Failed to load
configuration: No such file or directory
=> Jan 30 10:40:39 **REDACTED** systemd[1]: var.mount: Failed to load
configuration: No such file or directory
=> Jan 30 10:40:39 **REDACTED** systemd[1]: var-tmp.mount: Failed to load
configuration: No such file or directory
=> Jan 30 10:40:39 **REDACTED** systemd[1]: tmp.mount: Failed to load
configuration: No such file or directory
I will say that I created subvolumes for several directories (e.g., /var/tmp).

There is this entry, which has been reported elsewhere:
=> Jan 30 10:40:39 **REDACTED** systemd[1]:
/usr/lib/systemd/system/plymouth-start.service:15: Unit uses KillMode=none.
This is unsafe, as it disables systemd's process lifecycle management for the
service. Please update the service to use a safer KillMode=, such as 'mixed' or
'control-group'. Support for KillMode=none is deprecated and will eventually be
removed.

Then, the first real sign of a problem is:
=> Jan 30 10:40:46 **REDACTED** systemd[1]: Starting Load Kernel Module
efi_pstore...
=> Jan 30 10:40:46 **REDACTED** systemd[1]: plymouth-read-write.service:
ConditionPathExists=!/etc/initrd-release succeeded.
=> Jan 30 10:40:46 **REDACTED** systemd[1]: plymouth-read-write.service: Will
spawn child (service_enter_start): /usr/bin/plymouth
=> Jan 30 10:40:46 **REDACTED** (modprobe)[1093]: Found cgroup2 on
/sys/fs/cgroup/, full unified hierarchy
=> Jan 30 10:40:46 **REDACTED** (modprobe)[1093]: modprobe@efi_pstore.service:
Executing: /sbin/modprobe -abq efi_pstore
=> ...
=> Jan 30 10:40:46 **REDACTED** systemd[1]: plymouth-read-write.service:
Passing 0 fds to service
=> Jan 30 10:40:46 **REDACTED** systemd[1]: plymouth-read-write.service: About
to execute: /usr/bin/plymouth update-root-fs --read-write
=> ...
=> 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[1]: plymouth-read-write.service: Forked
/usr/bin/plymouth as 1094
=> ...
=> Jan 30 10:40:46 **REDACTED** systemd[1]: plymouth-read-write.service:
Changed dead -> start
=> Jan 30 10:40:46 **REDACTED** systemd[1]: Starting Tell Plymouth To Write Out
Runtime Data...
=> ...
=> Jan 30 10:40:46 **REDACTED** systemd[1]: plymouth-start.service: starting
held back, waiting for: systemd-vconsole-setup.service

There are several attempts to start systemd-vconsole-setup.service, but it will
not start once marked as failed. That is, I (and my logs) agree with Martin.
What is curious is the Plymouth forks and then waits for
systemd-vconsole-setup.service, but systemd-vconsole-setup.service is marked as
failed because seems to still won the console. BTW, my understanding is that
systemd-vconsole-setup.service is used anytime there is an attempt to configure
the console (e.g., for keymaps and fonts). That seems like a perfectly
reasonable thing for Plymouth to do, BUT it appears to be competing with
systemd-vconsole-setup.service.

Fedora applies a few patches to their Plymouth packages, but I can't tell if
any of them are relevant. I did not look at the Tumbleweed packages. To see if
there is a difference.

I wish I could be more helpful.