fake hwclock

[Robert Moskowitz]

This is from the Centos-arm list.

I have this running on a number of Centos7-armfhp Cubieboards.

I have just tested it on Fedora-Minimal-armhfp-Rawhide-20180807.n.0-sda

The result in journalctl -b is below

-------- Forwarded Message --------
Subject: 	Re: [Arm-dev] Security auditing service
Date: 	Tue, 7 Aug 2018 10:36:32 +0000
From: 	Kristján Valur Jónsson 
Reply-To: 	Conversations around CentOS on ARM hardware 
To: 	Conversations around CentOS on ARM hardware

aproppos incorrect time, I wrote a fake-hwclock service for centos, 
available here:
https://github.com/kristjanvalur/fake-hwclock

[Robert Moskowitz]

One more detail form boot log below

On 08/08/2018 09:27 AM, Robert Moskowitz wrote:
> This is from the Centos-arm list.
>
> I have this running on a number of Centos7-armfhp Cubieboards.
>
> I have just tested it on Fedora-Minimal-armhfp-Rawhide-20180807.n.0-sda
>
> The result in journalctl -b is below
>
> -------- Forwarded Message --------
> Subject: 	Re: [Arm-dev] Security auditing service
> Date: 	Tue, 7 Aug 2018 10:36:32 +0000
> From: 	Kristján Valur Jónsson 
> Reply-To: 	Conversations around CentOS on ARM hardware 
>
> To: 	Conversations around CentOS on ARM hardware
>
> aproppos incorrect time, I wrote a fake-hwclock service for centos, 
> available here:
> https://github.com/kristjanvalur/fake-hwclock
>
> -- 
> Kv,
> Kristján Valur Jónsson, RVX
>
> ==========================================
>
> Jun 22 11:12:15 localhost kernel: audit: type=1130 
> audit(1529680335.963:83): pi>
> Jun 22 11:12:16 localhost systemd[1]: Received SIGRTMIN+20 from PID 
> 372 (plymou>
> Jun 22 11:12:16 localhost systemd[1]: Started Tell Plymouth To Write 
> Out Runtim>
> Jun 22 11:12:16 localhost audit[1]: SERVICE_START pid=1 uid=0 
> auid=4294967295 s>
> Jun 22 11:12:16 localhost kernel: audit: type=1130 
> audit(1529680336.052:84): pi>
> Jun 22 11:12:16 localhost audit[1]: SERVICE_STOP pid=1 uid=0 
> auid=4294967295 se>
> Jun 22 11:12:16 localhost kernel: audit: type=1131 
> audit(1529680336.079:85): pi>
> Jun 22 11:12:16 localhost systemd-tmpfiles[610]: 
> [/usr/lib/tmpfiles.d/mdadm.con>
> Jun 22 11:12:16 localhost fake-hwclock[607]: 1
> Jun 22 11:12:16 localhost fake-hwclock[607]: loading saved time 
> 2018-08-08 08:5>
> Aug 08 08:55:48 localhost fake-hwclock[607]: Wed Aug  8 08:55:48 EDT 2018
> Aug 08 08:55:48 localhost kernel: audit: type=1130 
> audit(1533732948.014:86): pi>
> Aug 08 08:55:48 localhost audit[1]: SERVICE_START pid=1 uid=0 
> auid=4294967295 s>
> Aug 08 08:55:48 localhost systemd[1]: Started Fake Hardware Clock.
> Aug 08 08:55:48 localhost systemd[1]: Reached target System Time 
> Synchronized.
>
> This gives you real time sooner than Chrony does.

Aug 08 08:55:49 localhost chronyd[641]: chronyd version 3.3 starting 
(+CMDMON +>
Aug 08 08:55:49 localhost chronyd[641]: Frequency -3.478 +/- 1.341 ppm 
read fro>
Aug 08 08:55:49 localhost chronyd[641]: Using right/UTC timezone to 
obtain leap>

...

Aug 08 08:56:28 localhost chronyd[641]: Selected source 108.61.73.243
Aug 08 08:56:28 localhost chronyd[641]: System clock TAI offset set to 
37 secon>
Aug 08 08:56:28 localhost chronyd[641]: System clock wrong by 129.951151 
second>
Aug 08 08:58:38 localhost chronyd[641]: System clock was stepped by 
129.951151 >
Aug 08 08:58:39 localhost audit[1]: SERVICE_STOP pid=1 uid=0 
auid=4294967295 se>
Aug 08 08:58:45 localhost audit[1]: SERVICE_STOP pid=1 uid=0 
auid=4294967295 se>
Aug 08 08:59:44 localhost chronyd[641]: Selected source 23.131.160.7
Aug 08 09:03:04 localhost login[695]: pam_unix(login:auth): 
authentication fail>
Aug 08 09:03:04 localhost audit[695]: USER_AUTH pid=695 uid=0 
auid=4294967295 s>
Aug 08 09:03:06 localhost login[695]: FAILED LOGIN 1 FROM ttyS0 FOR 
root, Authe>
Aug 08 09:03:06 localhost audit[695]: USER_LOGIN pid=695 uid=0 
auid=4294967295 >

[Steve McIntyre]

On Wed, Aug 08, 2018 at 09:27:23AM -0400, Robert Moskowitz wrote:
> This is from the Centos-arm list.
>
> I have this running on a number of Centos7-armfhp Cubieboards.
>
> I have just tested it on Fedora-Minimal-armhfp-Rawhide-20180807.n.0-sda
>
> The result in journalctl -b is below

It would be nice if this didn't clash in terms of naming with the
"fake-hwclock" package I wrote for Debian 5 years earlier that does
very similar things. :-(

Cheers,

[Robert Moskowitz]

On 08/08/2018 01:32 PM, Steve McIntyre wrote:
> On Wed, Aug 08, 2018 at 09:27:23AM -0400, Robert Moskowitz wrote:
> > This is from the Centos-arm list.
> >
> > I have this running on a number of Centos7-armfhp Cubieboards.
> >
> > I have just tested it on Fedora-Minimal-armhfp-Rawhide-20180807.n.0-sda
> >
> > The result in journalctl -b is below
>
> It would be nice if this didn't clash in terms of naming with the
> "fake-hwclock" package I wrote for Debian 5 years earlier that does
> very similar things. :-(

Kristján's email is in my missive.  You can contact him directly and 
work things out.

[Nicolas Chauvet]

Le mer. 8 août 2018 à 16:15, Robert Moskowitz  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.

[Robert Moskowitz]

On 08/08/2018 02:32 PM, Nicolas Chauvet wrote:
> Le mer. 8 août 2018 à 16:15, Robert Moskowitz <[e-mail] 
> > 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.

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 also noticed that each boot is with this Jun 22nd date.  So whatever 
is used, should have its date/time advanced.

Would be nice...

[Peter Robinson]

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