1

Since last week my Pi begin to take a long time during boot to check its sd card, and if plugged any external devices.

At first I thought the SD card was dead, but switching with another, and installing from scratch with latest lite image (2018-06-27) still yields me with this error.

So I got into internet and found this question, "checking in progress on 1 disk" runs every time I boot, and followed the first comment's links, one of them relates this issue with a wrong past datetime at boot.

So I proceed to do a sudo journalctl and surprisingly my Pi boots with November 3 2016 as the date, and it seems to be causing the check every boot.

My question is: How to fix that? Isn't the Pi supposed to save the shutdown/reboot date somewhere (since it didn't have a internal clock) and restore at boot? Are my Pi damaged in someway?

For information, my Pi is 3B and its uname is:

Linux raspberrypi 4.14.50-v7+ #1122 SMP Tue Jun 19 12:26:26 BST 2018 armv7l GNU/Linux

Vico
  • 121
  • 3

2 Answers2

1

After some more fiddling on internet i found the method raspbian uses to store the time at shutdown: fake-hwclock (via the answer of "How is time kept on the Raspberry Pi?" queston in this very same site).

Then i checked the file fake-hwclock stores the timestamp (cat /etc/fake-hwclock.data) and seems to be after a while powered the software finally stored the current time on that (2018-07-05 14:17:01), so i rebooted again and the system finally booted without any additional disk checks.

But i still can't figure out why fake-hwclock was using nov 2016 in first place (and across installs), because my pi is connected with internet via ethernet and DHCP.

Vico
  • 121
  • 3
0

So i got into internet and find this question and followed the first comment's links, one of them relates this issue with a wrong future datetime at boot.

Whoops, somebody got something backward. The problematic date isn't in the future, it's in the past. Notice that post is dated:

Posted by u/Werkstadt 5 months ago

Now keep in mind it is the middle of 2018, so that was sometime in January of 2018, and in fact one of the dates referred to in the log snippet is Jan 21, 2018. The system is complaining about that because it thinks that date is in the future. That's because it thinks today is:

Nov 03 18:16:43 magicmirror systemd-fsck[110]:         now = Thu Nov  3 18:16:43 2016

Scroll to the end there if you have to, and look at the year:

2016

That's not a future November, that's a past November.

This is pretty common on the Pi, which does not have a real time clock and must rely on a network connection to get the time. It doesn't have one during initial boot time -- in fact it may not get one until booting is more or less over.

I believe what it does before that is assume a time based on some particular file timestamp.1 In any case, that time is going to be in the past. In the post you linked, the log message is from fsck, and it is complaining the last mount time for some filesystem/partition -- which is probably pretty recent, but also in the past -- appears to be in the future, because the system datetime is in November 2016.

  1. As it turns out it's a string in /etc/fake-hwclock.data.
Community
  • 1
goldilocks
  • 56,430
  • 17
  • 109
  • 217
  • Uh, my bad, the logs says `now = Thu Nov 3 15:16:42 2016`. This is strange because it began to happen only from weeks ago and persists across sd cards. Thats why i asked if could be something with my pi, or a update of raspbian began to cause it. Anyway i've updated my question to reflect this. – Vico Jul 05 '18 at 14:06
  • It probably has something to do with the base image. I only looked in one (2017-09-07) and that `fake-hwclock.data` had the same date as the image, but that isn't necessarily policy. The reason it may not have affected you until a certain point is because `fsck` doesn't run at evey boot, and may not run at all until you have an unclean shutdown. – goldilocks Jul 05 '18 at 17:34