https://bugzilla.suse.com/show_bug.cgi?id=1218618 https://bugzilla.suse.com/show_bug.cgi?id=1218618#c19 --- Comment #19 from Tony Walker <tony.walker.iu@gmail.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.