Excessively slow boot after normal shutdown, but not so after forced power off?

General Help
1

I’m still in the process of preparing my T43p with Zorin Education Lite 32bit for my grandson. I’ve had startup problems before, see
Slow boot after moving swap partition
In the meantime I decided to do a clean install using the SSD for / and /boot, and the HDD for swap, /var, /var/log, and /home.

The system runs fine and is quite responsive once it is up, and the emphasis lies on once it is up. What I see is an excessively long boot time whenever the system is booted after an orderly shutdown (and power off), or when restarting it. I’m calling this “long boot” hereafter.

However, when I force a power-off (by holding down the power button) during that long boot time, and then power on the system, it comes up quickly. I’m calling this “quick boot” hereafter.

The “long boot” lasts 4 minutes and up until the graphical login is shown, whereas the “quick boot” doesn’t take a minute. Note that I cannot open a tty during “long boot”, the system not react on ctrl-alt-Fn at all.

I’ve been looking at log files but haven’t been able to identify the cause.
Running systemd-analyze blame in both situations shows plymouth-read-write.service to behave strangely. It takes 4 minutes and up to be ready on “long boots”, whereas it is ready after ~100ms on “quick boots”.

I could not find what this service is supposed to do exactly; the only discussions I’ve found talk about plymouth-quit-wait.service, but that one completes in less than a second in both cases.

I’m desperate :frowning_face:

The only changes I had applied after installation are listed below. However, I have undone all of them (except the general system upgrade, of course), but the problem persists.

  • I made sure the system is up-to-date:
    apt update
    apt upgrade
    Some 135+ packages needed to be updated.

  • installed the tlp package:
    add-apt-repository ppa:linrunner/tlp
    apt install tlp
    apt install tp-smapi-dkms
    apt install acpi-call-dkms

  • disabled the veyon service, since it will not be used:
    systemctl --now disable veyon

  • told systemd to kill all user processes at log-out by adding the following line to /etc/systemd/login.conf:
    KillUserProcesses=yes
    I saw xfcci to hog the CPU after log-out, and log-in w/o reboot. This was a recommended solution I found in the net.

  • to avoid unneccessary writes to the SSD, the following was added to the lines for / and /boot in /etc/fstab:
    noatime

I’m open for any recommendation which can help isolate the cause of this very srtange behaviour.

  • What is plymouth-read-write.service good for?
  • What might it be waiting for?
  • What might be different between a system that was orderly shutdown and one that was brough down by forcing a power-off?
2

In the course of debugging this further, I found that if I remove the splash parameter from the kernel parameters in the grub menu, the problem does not occur.

This is not a solution but only a circumvention with the unwanted effect that a few kernel messages are seen during boot and shutdown. Not what I want.

So the question remains: What is wrong with the plymouth-read-write.service when the system is booted after an orderly shutdown or with by restarting it?