http://bugzilla.suse.com/show_bug.cgi?id=1145193
http://bugzilla.suse.com/show_bug.cgi?id=1145193#c20
--- Comment #20 from Fabian Vogt
(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. -- You are receiving this mail because: You are on the CC list for the bug.