On Wed, 29.04.15 11:48, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
> I agree that it's not possible to make this work under every circumstance, > but a compromise existed that worked well enough so that most people were > not complaining. I propose that a system that possibly hiccups every year or > two is better than a system that misbehaves all the time. Why can't the > startup just treat the RTC as if it was GMT with an unexplained offset? e.g. > measure that offset when time syncing with reliable sources, write it down > and use it on the next boot? Hmm? we *do* support rtc-in-local at a basic level already (i.e. without DST handling). What doesn't work is rtc-in-local in early-boot, that's all. And that doesn't matter really, except if you are crazy enough to manually enable time-based fsck in ext234, which has been turned off by default in fedora since time begain, and even has been turned off upstream now, because it's simply a crazy feature. I am not sure it is worth discussing this any further. This only trips you up if you combine two known broken settings, and I am pretty sure we have much bigger problems to fix than this. > By the way, it'd be nice if the startup dealt gracefully with all kinds of > clock problems. Many embedded systems have no persistent realtime clock at > all; I seem to remember that Beaglebone uses a hack that initializes clock > from a fixed value from a file. systemd-timesyncd implements this, too, it will ensure that the clock is monotonic at least. It will save the local clock to disk at shutdown and each time it acquires an NTP fix. fedora doesn't use timesyncd by default however. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
