Upon advice I have migrated the machine to "testing", resetting /etc/apt/sources.list and running `apt-get update ; apt-get dist-upgrade`. That process did not go without errors but `apt --fix-broken install` run in a root terminal did complete.
My problem remains. At any time that I allow an unattended reboot, it gets to a certain point and there is repetitive screen blanking, a brief flash back to text mode, more screen blanking, etc. Attempts to switch to a text console (via <ctrl-alt-F5> for example) provide no relief nor a usable screen. Flashing continues. Rebooting and using GRUB to go rescue mode, I can watch the progress, I get to the "reached rescue target" and login prompts. I give root password and from there 'service dbus start ; systemctl default' takes me right to the X login and from there all goes well and as expected. This is all very repeatable. Previous attempts to debug this seemed to indicate that 'dbus' was never started by systemd but that doesn't seem possible. Yet that's how I hit on the simple workaround of starting D-Bus from the rescue commandline. My clue was messages in logs to the effect that /var/run/dbus did not exist. I have /var on a "spinner" drive along with /home and /tmp, and / and /usr are on two different partitions of an NVME/PCIe solid-state drive. /etc/fstab mounts these partitions from the "spinner" drive using UUID rather than calling (for example) /dev/sda1 to mount on /var. Possibly irrelevant. Is it possible that somewhere in the process of mounting the spinner partition for /var, the dbus directory with dbus.service and dbus.socket becomes inaccessible and need to be recreated with `service dbus restart`? If this seems likely, please advise on how to add a workaround to the systemd startup process. I admit to being less than proficient in systemd, having come from sysv init. Regards,