• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Hardware clock incorrectly set

E

ejstubbs

Member
Having had a couple of crashes in the last week, I decided to run fixdisk. It's thrown the following error/infomation message twice so far:

Superblock last mount time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set)
Click to expand...

So my questions are:
  1. Is this a cause for concern i.e. does it need to be fixed?
  2. If so, how can it be fixed?
I suspect this may be a hangover from the clock change at the end of March, although I don't recall seeing this message before.
 
Probably not.
You could try rebooting it, then note the current time, then run this from the command line:
dumpe2fs -h /dev/sda1 |grep time
and see what it reports. Repeat for sda2 and sda3 and see what the differences are, if any.
(sda may be sdb if you have one of the virtual-disk packages installed)
 
prpr said:
Probably not.
You could try rebooting it, then note the current time, then run this from the command line:
dumpe2fs -h /dev/sda1 |grep time
and see what it reports. Repeat for sda2 and sda3 and see what the differences are, if any.
(sda may be sdb if you have one of the virtual-disk packages installed)
Click to expand...

OK, thanks: I'll give a go once the fixdisk has completed.
 
IIRC, as standard, unless the hardware is able to set the clock from EPG data it thinks it's 1970. Is the system able to set the clock during maintenance mode? Does the system time survive a reboot? Maybe the system time survives the reboot or gets set from EPG, but is no longer able to account for BST?
 
Black Hole said:
unless the hardware is able to set the clock from EPG data it thinks it's 1970.
Click to expand...
This is not less than a day in the future though is it?

I get this on 2 out of 4 of my boxes, but only for /dev/sda1, the other two partitions being correct:
Last mount time: Sat Jan 2 00:00:03 1971
I can't explain the bizarreness of the year and the day both being out by 1 from what might be expected (Jan 1 1970).
 
Here's the dumpe2fs output once the fixdisk had completed (with no faults found) and the box had ben rebooted a couple of times:

humax# date
Mon May 31 15:42:57 BST 2021
humax# dumpe2fs -h /dev/sdb1 |grep time
dumpe2fs 1.42.13 (17-May-2015)
Last mount time: Mon May 31 15:28:04 2021
Last write time: Mon May 31 15:28:04 2021
humax# dumpe2fs -h /dev/sdb2 |grep time
dumpe2fs 1.42.13 (17-May-2015)
Last mount time: Mon May 31 15:28:07 2021
Last write time: Mon May 31 15:28:07 2021
humax# dumpe2fs -h /dev/sdb3 |grep time
dumpe2fs 1.42.13 (17-May-2015)
Last mount time: Mon May 31 15:28:07 2021
Last write time: Mon May 31 15:28:07 2021
humax#
Click to expand...

Anything stand out?
 
You can install the NTP package to set the clock from the network at boot. This is far more accurate than the EPG data will ever be.
 
Owen Smith said:
You can install the NTP package to set the clock from the network at boot. This is far more accurate than the EPG data will ever be.
Click to expand...
That would be particularly useful if it works in Maintenance Mode to ensure the system clock is correct.
 
Black Hole said:
That would be particularly useful if it works in Maintenance Mode to ensure the system clock is correct.
Click to expand...
I have no idea whether it works in Maintenance Mode. Technically there is no reason why not, all it needs is the network stack in order to work.
 
The whole point of maintenance mode is not to use anything installed on the hard disk.
Having said that though, there is a copy of the ntpclient executable in /usr/bin/ntpclient which is in flash that could be used. I'm not sure what the difference is - they are the same size, but different dates, and aren't a binary match.
 
The ntpclient in /usr/bin is presumably the one that the settop binary uses, suggested by this strings output fragment:
Code: 
...
uk.pool.ntp.org
ntpclient
...
Interesting that Humax programmed the UK servers into what otherwise appears to be a localisable product.

The Maintenance Mode script /etc/init.d/S89maintenance could try running /usr/bin/ntpclient -h uk.pool.ntp.org -c 1 somewhere around the beginning of the "start" case.
 
I wasn't aware the standard Humax firmware even had an NTP client. I always assumed that was custom firmware only. Do we know when the Humax firmware runs its NTP client?
 
You must log in or register to reply here.
Back
Top