[opensuse-arm] ntp, a couple of minor issues
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. I am using the following image: http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/appliances... 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. 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? -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
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? -- Per Jessen, Zürich (12.2°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
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
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 package is noarch. The tar file with these files and more can be downloaded from: http://http.debian.net/debian/pool/main/f/fake-hwclock/fake-hwclock_0.11.tar... -- fr.gr. member openSUSE Freek de Kruijf -- 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
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
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 <per@computer.org> 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
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. *shrug* Alex -- 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
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. 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. Alex -- 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
On 21/03/2017 11:06, Per Jessen wrote:
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)
Yes, most Allwinner SoCs these days have a built-in RTC IP block. Unfortunately that block isn't very useful if it can't preserve time due to lack of attached battery. Some cheaper boards like the pine64 expose at least battery pins that you can use to make the RTC useful: https://www.pine64.org/?product=rtc-backup-battery-cr-battery However, at that price point you can usually get a full external RTC chip with battery :). Alex -- 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
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. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- 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
Am 22.03.2017 um 09:50 schrieb Stefan Bruens:
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.
Wouldn't it have printed something other than 1970 above then? Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany 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 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 <per@computer.org> 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
participants (8)
-
Alexander Graf -
Andreas Färber -
Brüns, Stefan -
Eric Curtin -
Freek de Kruijf -
Matthias G. Eckermann -
Per Jessen -
Stefan Bruens