Richard Laager said: > I believe you're looking for "fake-hwclock". It periodically saves the time > to a file (allegedly* /etc/fake-hwclock.data) and restores it on boot.
Thanks. I discovered fake-hwclock via Google but it wasn't on my system and the discussion I was looking at was very old so I assumed it had been replaced or something. Looks like Ubuntu just didn't include it in their img file that I used. I installed it and things are happy. I think this is a good-enough solution. Basically, we have to document that the clock has to be close-enough and what close-enough means. Cold-stanbys sitting on the shelf for many years won't work. PCs with dead CMOS/TOY clock battries won't work. (Let's Encrypt certificates are only valid for 90 days.) IoT devices on a store shelf for a few months might not work. Working Raspberry PIs that sit on the shelf for long enough may not work. You can fix the stanby/store shelf problem by carefully setting up certificates with a long lifetime. ------ > I still think we need a more comprehensive approach to this bootstrapping > problem. The problem is, I don't have the time to write it. But I gave my > thoughts before: https://lists.ntpsec.org/pipermail/devel/2019-February/ > 007576.html That looks reasonable, but complicated. I'm not planning to work on anything like that. ------ >> That could backfire if, somehow, the system time got set into the future. >I had that happen once. It might have been due to a GPS rollover. GPS rollover seems more likely to go the other way -- that is step back by 20 years. It would go forwards if it was broken, you used fudge to fix it, and then the software got fixed and you installed the new software without removing the fudge. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org https://lists.ntpsec.org/mailman/listinfo/devel
