In a Debian 12 Bookworm installation I faced some problems at bootstrap. Some services does not start basically because the /run hierarchy was not properly initialized with the required subdirectories. E.g. one OpenVPN service does not start beacuse the /run/openvpn/ directory does not exists:

ovpn-office[2853]: Options error: --writepid fails with '/run/openvpn/office.pid':
    No such file or directory (errno=2)

An enlightening error message is displayed by dmesg:

systemd[1]: sysinit.target: Found ordering cycle on systemd-tmpfiles-setup.service/start
systemd[1]: sysinit.target: Job systemd-tmpfiles-setup.service/start deleted to break
            ordering cycle starting with sysinit.target/start

I.e. the service sysinit.target cannot start due a service ordering problem, so Systemd decided to delete the systemd-tmpfiles-setup.service. The problem could be with other Systemd unit too, e.g. the avahi-daemon.socket:

systemd[1]: avahi-daemon.socket: Found dependency on systemd-tmpfiles-setup.service/start
systemd[1]: avahi-daemon.socket: Job systemd-tmpfiles-setup.service/start deleted to break
            ordering cycle starting with avahi-daemon.socket/start

Others problematic Systemd units can be: sockets.target, basic.target.

systemd-analyze verify default.target

The command highlights an ordering cycle problem, which causes the deleting of a service:

sockets.target: Found ordering cycle on avahi-daemon.socket/start
sockets.target: Found dependency on sysinit.target/start
...
sockets.target: Job avahi-daemon.socket/start deleted to break ordering
                cycle starting with sockets.target/start
...

Notice that the ordering (and the deleting choice) is not deterministic: on each execution the path of ordering (and deleting) may change.

The problem was introduced by this custom Postfix/Courier setup: Postfix with Courier Authdaemon in Debian 12 Bookworm. In fact disabling the Systemd var-spool-postfix-var-run-courier-authdaemon.mount unit, solves the issues listed by systemd-analyze.

In this specific case the problem was completely solved changing the dependencies of the mount unit created to have the Courier socket inside the Postfix chroot. Instead of the strong Requires= and After= dependencies upon the courier-authdaemon.service, declaring the weaker Wants= dependency sovled to cycle problem.