Comment # 20 on bug 1145193 from Fabian Vogt

(In reply to Thorsten Kukuk from comment #19)
> (In reply to Fabian Vogt from comment #18)
> 
> > That's exactly what disabling chrony-wait.service achieves. chronyd.service
> > is still running in the background, but does not block booting.
> 
> That's an ugly hack breaking everything depending on the correct time, not a
> correct solution.

AFAIK time-sync.target was not used before the change in YaST at all.
The best option is probably to not let critical services depend on
time-sync.target, that way the system is up and running while time is not yet
synchronized.

> That was the main cause for all the "permission denied"
> errors, since the time was wrong and thus the certificates not valid.
> If I don't have network during installation and configuration, it's already
> questionable, why we configure an always running time sync daemon. That's in
> my opinion already wrong.

Because the system clock is unreliable. There's a noticeable skew between
different hardware and on power loss the time might get lost entirely. This
gets even worse when it's a dual-boot setup, as the different OSs might not
agree on whether to store the UTC or local time in the hwclock.