As subj says. I have a typical win-dos AT-compatible machine; i.e. the RTClock keeps local time, not GMT. I'm reasonable sure I specified it during the initial graphical installation to disk, however I still get that message & / file system check on each boot.

Other than this annoyement, there is no problem with my date/time either in Linux nor in any of half a dozen OSes I multiboot. How do I correct this permanently please ?

This problem usually happens when you have the time misconfigured. When the system wakes up it gets the time from the hardware clock. If your hardware clock settings are wrong then this will set your system time incorrectly and depending on the direction of the error can cause exactly the message that you get.

The reason it keeps repeating is likely because you have the ntpd (network time protocol) daemon running so once it gets set up it will correct your system clock to the correct time. But if your hardware clock settings are wrong then it will set the hardware clock incorrectly which allows the problem to repeat on the next boot.

If you have your timezone set up correctly then the problem is likely in your hardware clock setting. You tell your system whether the hardware clock keeps local time or UTC in the third line of the /etc/adjtime file. If it currently has"UTC" in the third line then edit that file as root and change it to"LOCAL".

Only a totally brain-dead operating would store local time in the hardware clock. Or an operating system that has to dual boot with a totally brain-dead operating system.

You tell your system whether the hardware clock keeps local time or UTC in the third line of the etc/adjtime file. If it currently has"UTC" in the third line then edit that file as root and change it to"LOCAL".

I'd checked that already. It is LOCAL, all caps, indeed.

... and I've just now again cycled, rebooted in MS-DOS, then AntiX again. As usual, it found a"superblock write time is in the future', by less than one day, blah... And did a fsck. Oh well I can live with that, since date/time is apparently correct for all OSes. Still it's bizarre.

(Edit, to add:) And agai;n this time shutting down and rebooting direct to Antix. Still same symptom ! Either it's for everyone (having the RTC time set to local), or else there are ghosts in the machine :=)

This almost always comes down to a misconfiguration somewhere. There are several tools available to help you track this down. If you have ntp installed then make sure it is disabled while you are debugging. You can see the time stored in the hardware clock with the command: This can be confusing because it relies on your utc vs localtime setting and also on your timezone. You can try running this right after the machine boots and then again before shutdown and see if the offset between the time stored in the hardware clock versus the system time changes significantly.

If the error message tells you the time offset and these are fairly consistent then the problem almost has to be a misconfiguration. If the offsets wander around then it is possible the battery inside the computer needs to be replaced.

The error message you get is caused by the time settings on your machine changing. This will happen if the battery needs to be replace, or if a system (like a live-usb/cd) accesses your partitions with the time not set correctly, or if the time on your system is misconfigured combined with an outside source for time information such as ntpd.

howabout: it's an older machine and the coin cell battery that's supposed to maintain the hardware clock is kaput.
That condition, along with the NTP check during boot, I think that has led to the"fsck every time" on some of my older PCs.

I don't think it's the cell battery. The RTC and"cmos" registers do'nt lose memory, furthermore this problem with the"superblock last write time" is specific to this new Linux install, never had such with the linuces I had installed here (2 versions).

Regarding NTP : this morning I booted the system withouta network connection, yet It gave the same as usual warning. I do understand the test is incomplete, I should do a full cycle while the box is non connected. Shall do sometime ;=)

Not precluding a hardware problem - but, my guts feeling is it's a software misconfiguration of sorts. Let us leave this mystery alone until later...