On 2017-03-17 T 09:52 +0100 Per Jessen wrote:

What is the real problem - that it takes too long before time is set? That might suggest that ntpd is having trouble talking to the time server. Maybe DNS delays?

Try adding the "iburst" option to the ntp servers in /etc/ntp.conf - helped for me on the RPi3 (running SLES 12 SP2), e.g. ------------------------< snip >------------------------ server ntp1.t-online.de iburst # server ptbtime1.ptb.de iburst server de.pool.ntp.org iburst ------------------------< snap >------------------------ // please pick an ntp server close to you / your provider's // network See "man ntp.conf" for an explanation on "iburst". HTH - So long - MgE -- Matthias G. Eckermann, Director Product Management SUSE Linux Enterprise SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On 17/03/2017 11:37, Freek de Kruijf wrote:

Op vrijdag 17 maart 2017 09:52:14 CET schreef Per Jessen:

...

Eric Curtin wrote:

...

Hi Guys,

On the rpi3 since it does not seem to have any CMOS battery type thing (correct me if I'm wrong), it boots with the epoch time on boot every time.

Same on my nanopi neo air.

...

I have added an internal corporate ntp server to /etc/ntp.conf, which works fine, but it takes quite a while for the ntp daemon to sync the time. The time needs to be correct as some things I am using on the rpi3 depend on the time being correct (such as docker). Generally about four minutes in, the time successfully changes:

Thu Jan 1 01:03:50 IST 1970 Thu Mar 16 11:45:19 GMT 2017

I am connected via ethernet, I see the daemon is configured in systemd to start after network.target, but it seems this is not enough (maybe it's too soon to start the ntp daemon?) to get the time synced quickly.

The ntp start up script includes a '-g' option to allow big jumps (clearly needed). How much delay do you see between the network coming up and time being set?

...

Also when this time jump occurs, XFCE decides to lock my screen, so I have to login again.

Any ideas on solutions, before I come up with my own?

What is the real problem - that it takes too long before time is set? That might suggest that ntpd is having trouble talking to the time server. Maybe DNS delays?

There is a package, not available in openSUSE, called fake-hwclock, which contains a number of scripts. A file in /etc/fake-hwclock.data is updated by means of a script in /etc/cron.hourly/fake-hwclock.cron.hourly which calls a script in /sbin/fake-hwclock. On a regular shutdown the time in /etc/fake- hwclock.data is also updated. Rather early in the boot process systemd calls fake-hwclock.service, which is a script in /usr/lib/systemd/system/fake-hwclock.service, which takes the time from /etc/fake-hwclock.data. So the time is already close to the time of booting.

The way this usually gets handled in openSUSE is by reading the unmount time of your root file system. There should be a script in dracut that finds out when your rootfs was last unmounted and sets the system time to that if the system time is bogus. I'm not quite sure why that doesn't kick in for you. Maybe it only works on ext4? Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Yeah "iburst" was all that this needed. It's perfect for my needs at least. Haven't seen anything like that in my dracut scripts either. Similar to Per, I may not be looking for the right thing. On 17 March 2017 at 12:14, Per Jessen wrote:

Alexander Graf wrote:

...

The way this usually gets handled in openSUSE is by reading the unmount time of your root file system. There should be a script in dracut that finds out when your rootfs was last unmounted and sets the system time to that if the system time is bogus.

I'm not quite sure why that doesn't kick in for you. Maybe it only works on ext4?

I looked through the dracut scripts (usr/lib/dracut), I can't find anything like that. Maybe I'm not looking for the right thing.

-- Per Jessen, Zürich (17.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf wrote:

On 20/03/2017 16:11, Eric Curtin wrote:

...

Yeah "iburst" was all that this needed. It's perfect for my needs at least. Haven't seen anything like that in my dracut scripts either. Similar to Per, I may not be looking for the right thing.

I can't find it anymore either. Odd.

So historically we used to have a hack that set the system time to the initrd build time if it was bogus:

https://github.com/openSUSE/mkinitrd/blob/ad190ad24a9f3881afa11c47aecc8625b2...

That got removed with the transition to dracut and I seem to remember that the hack we then added was to take the last mounted time from your / file system and apply that as system time. But I agree that I can't find any reference to it.

Sounds like a pretty good idea.

I'm surprised any of the non-RTC ARM systems boot at all then - ext3 used to complain really loudly if the last mount time was newer than the system time.

AFAICT, my nanopi neo air does have an RTC, but it still comes up with clock set to 1970 <something> on boot. -- Per Jessen, Zürich (11.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf wrote:

On 21/03/2017 09:52, Per Jessen wrote:

...

Alexander Graf wrote:

...

On 20/03/2017 16:11, Eric Curtin wrote:

...

Yeah "iburst" was all that this needed. It's perfect for my needs at least. Haven't seen anything like that in my dracut scripts either. Similar to Per, I may not be looking for the right thing.

I can't find it anymore either. Odd.

So historically we used to have a hack that set the system time to the initrd build time if it was bogus:

https://github.com/openSUSE/mkinitrd/blob/ad190ad24a9f3881afa11c47aecc8625b2...

That got removed with the transition to dracut and I seem to remember that the hack we then added was to take the last mounted time from your / file system and apply that as system time. But I agree that I can't find any reference to it.

Sounds like a pretty good idea.

...

I'm surprised any of the non-RTC ARM systems boot at all then - ext3 used to complain really loudly if the last mount time was newer than the system time.

AFAICT, my nanopi neo air does have an RTC, but it still comes up with clock set to 1970 <something> on boot.

There's a separate RTC module on sale as far as I can tell, but nothing built in.

I think I saw that too, but then I noticed these messages : # dmesg | grep rtc [ 6.850912] sun6i-rtc 1f00000.rtc: rtc core: registered rtc-sun6i as rtc0 [ 6.850920] sun6i-rtc 1f00000.rtc: RTC enabled [ 6.960530] sun6i-rtc 1f00000.rtc: setting system clock to 1970-01-01 00:00:13 UTC (13)

You can usually tell quite easily whether you have a working RTC by searching for a battery on the board. No battery means no working RTC, as there's nothing that would preserve the time while it's not plugged in.

There is definitely no battery, not enough room :-) -- Per Jessen, Zürich (12.0°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Alexander Graf wrote:

On 20/03/2017 16:11, Eric Curtin wrote:

...

Yeah "iburst" was all that this needed. It's perfect for my needs at least. Haven't seen anything like that in my dracut scripts either. Similar to Per, I may not be looking for the right thing.

I can't find it anymore either. Odd.

So historically we used to have a hack that set the system time to the initrd build time if it was bogus:

https://github.com/openSUSE/mkinitrd/blob/ad190ad24a9f3881afa11c47aecc8625b2...

That got removed with the transition to dracut and I seem to remember that the hack we then added was to take the last mounted time from your / file system and apply that as system time. But I agree that I can't find any reference to it.

I'm surprised any of the non-RTC ARM systems boot at all then - ext3 used to complain really loudly if the last mount time was newer than the system time.

I've just had to reboot my nanopi, it came up with "2017-01-10 11:53:57". In dmesg, the built-in rtc reports [ 6.965339] sun6i-rtc 1f00000.rtc: setting system clock to 1970-01-01 00:00:13 UTC (13) Looking at the root file system: # tune2fs -l /dev/mmcblk0p2 tune2fs 1.43.3 (04-Sep-2016) Filesystem volume name: ROOT Last mounted on: / [snip] Filesystem created: Thu Jan 19 04:00:24 2017 Last mount time: Tue Jan 10 11:54:03 2017 Last write time: Tue Jan 10 11:53:59 2017 Mount count: 57 Maximum mount count: -1 Last checked: Tue Mar 7 21:59:21 2017 So, something did set the time? I mean, that timestamp from 2017/01/10 must come from somewhere? -- Per Jessen, Zürich (5.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Stefan Bruens wrote:

On Mittwoch, 22. März 2017 08:43:43 CET Per Jessen wrote:

...

Alexander Graf wrote:

...

On 20/03/2017 16:11, Eric Curtin wrote:

...

Yeah "iburst" was all that this needed. It's perfect for my needs at least. Haven't seen anything like that in my dracut scripts either. Similar to Per, I may not be looking for the right thing.

I can't find it anymore either. Odd.

So historically we used to have a hack that set the system time to the

initrd build time if it was bogus:

https://github.com/openSUSE/mkinitrd/blob/ad190ad24a9f3881afa11c47aecc8625b

...

...

286d0d4/scripts/boot-start.sh#L210> That got removed with the transition to dracut and I seem to remember that the hack we then added was to take the last mounted time from your / file system and apply that as system time. But I agree that I can't find any reference to it.

I'm surprised any of the non-RTC ARM systems boot at all then - ext3 used to complain really loudly if the last mount time was newer than the system time.

I've just had to reboot my nanopi, it came up with "2017-01-10 11:53:57". In dmesg, the built-in rtc reports

[ 6.965339] sun6i-rtc 1f00000.rtc: setting system clock to [ 1970-01-01 00:00:13 UTC (13)

Looking at the root file system:

# tune2fs -l /dev/mmcblk0p2 tune2fs 1.43.3 (04-Sep-2016) Filesystem volume name: ROOT Last mounted on: / [snip] Filesystem created: Thu Jan 19 04:00:24 2017 Last mount time: Tue Jan 10 11:54:03 2017 Last write time: Tue Jan 10 11:53:59 2017 Mount count: 57 Maximum mount count: -1 Last checked: Tue Mar 7 21:59:21 2017

So, something did set the time? I mean, that timestamp from 2017/01/10 must come from somewhere?

If you only reboot, i.e. keep the power supply connected, the RTC does its job. It is not battery backed, but still an RTC.

Ah, of course. However, I've just repeated the experiment - power off and reboot, and it comes back up with a timestamp in January 2017: ssh root@nano1 Password: Last login: Wed Mar 22 09:40:28 2017 from 2001:db8:4c68:1:21d:92ff:fe39:a132 Have a lot of fun... nano1:~ # date Tue 10 Jan 11:55:33 CET 2017 -- Per Jessen, Zürich (7.0°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

On Montag, 20. März 2017 16:11:10 CET Eric Curtin wrote:

Yeah "iburst" was all that this needed. It's perfect for my needs at least. Haven't seen anything like that in my dracut scripts either. Similar to Per, I may not be looking for the right thing.

On 17 March 2017 at 12:14, Per Jessen wrote:

...

Alexander Graf wrote:

...

The way this usually gets handled in openSUSE is by reading the unmount time of your root file system. There should be a script in dracut that finds out when your rootfs was last unmounted and sets the system time to that if the system time is bogus.

I'm not quite sure why that doesn't kick in for you. Maybe it only works on ext4?

I looked through the dracut scripts (usr/lib/dracut), I can't find anything like that. Maybe I'm not looking for the right thing.

While ext filesystems have a mount time stamp in the superblock, at least btrfs has none, so the filesystems as time source is not always available. You may use systemd-timesyncd instead. It touches /var/lib/systemd/clock each NTP poll interval (i.e. starting with 32 seconds, exponential backoff up to 34 minutes), and uses the file timestamp on startup. Kind regards, Stefan-- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org