On Wed, Aug 8, 2018 at 7:58 PM, Robert Moskowitz <rgm(a)htt-consult.com> wrote:
On 08/08/2018 02:32 PM, Nicolas Chauvet wrote:
Le mer. 8 août 2018 à 16:15, Robert Moskowitz <rgm(a)htt-consult.com> 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