On Wed, Aug 8, 2018 at 7:58 PM, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote: > > > On 08/08/2018 02:32 PM, Nicolas Chauvet wrote: > > Le mer. 8 août 2018 à 16:15, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> a écrit > : >> >> This is from the Centos-arm list. >> >> I have this running on a number of Centos7-armfhp Cubieboards. > > > There is a quicker workaround here: > https://bugzilla.redhat.com/show_bug.cgi?id=1074002#c7 > But it's only for battery-backed RTC. > > Best would be to have merge this feature into systemd or dracut I would say. > > > Better handling of boot time for SOCs without RTC battery is needed. Sure, but the fix of the above isn't really a fix, and ultimately something like systemd is the better handling because it's PID 1 and hence the first bit of the userspace that can handle this. > I noticed that this build is coming up with a time of Jun 22 this year, > rather than the old way of starting with EPOCH time. How does it get this > time? Is it from a timestamp on a file? the installer could mount the root > partition and touch the file used and thus first boot would be card install > time. I believe that is actually a systemd feature, I'm not 100% of where it gets this, I believe it might be around filesystem metadata time stamp of some sort. A quick google failed to come up with the actual answer and I'm not in a place where I have the time to dig out the complete answer. Ultimately the proper fix is likely to improve this functionality to ensure it's closer to the actual time as is possible. > I also noticed that each boot is with this Jun 22nd date. So whatever is > used, should have its date/time advanced. > > Would be nice... Sure, it would be nice, the expectation of a real battery backed RTC would be even nicer, and I'd like a pony too. Ultimately if real time ASAP is a requirement for you I suggest you pay a few more dollars to get a ARM SBC that has a battery backed RTC that provides that. The way the process works ATM is far from an ultimate solution but it works pretty well for the vast majority of users without a lot of investment in time from the people that can fix it. It's very easy to imply it should be fixed and commit other people's time to do it. Fedora and Fedora ARM is a meritocracy and I welcome you to engage to improve the situation for the community as a whole but also it needs to be supportable and work for a lot of different usecases not just your own. Peter _______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx/message/FBE252CHUD7HQBPRJWRKQNFJIEKKPJJZ/
