On my ThinkPad X200 (with libreboot), the system time is being reset to Thursday Jan 1st 1970 on every reboot with 14.2 (there was no problem on 14.1). I tried everything here, but nothing sticks after a reboot. The error in dmesg is;

The same error occurs with 'hwclock --show' from the command line. The only thing that makes 'hwclock' work is running 'hwclock --systohc --localtime' but this doesn't seem to persist after a reboot.

Then the Bios battery is empty.

And this occurred at the exact moment I installed 14.2? I found this bug report, but it doesn't help me too much.

Before installing 14.2 had you been hibernating the laptop or doing a complete shutdown? I could be wrong here, but I think you wouldn't have noticed a dead CMOS battery if you had been hibernating. Only when you booted from USB or DVD to install 14.2 would the problem have become apparent. Again, I could be wrong about this.

I had never bothered to set up hibernation on 14.1 (fully encrypted with LUKS/LVM), so always a complete shutdown.

I suppose I could install 14.1 again to test it.

On second thought Keruskerfuerst might be right if the 14.1 installation was just getting the time from NTP always, although I don't remember the time ever being 1970 if I had the WiFi switched off. I will have to test it and report back.

Well, booting from a freshly copied Ubuntu LiveUSB at least shows the proper date and time (although it still gives this error about reading the hardware clock). Hard to understand what's going wrong.

Just change the battery...

By which I just mean that there is no need look for any other cause until you do that.

What are the odds that it would go dead during the same time as the new install?

Ask it a different way, what are the odds of the battery eventually going dead? 100%.

What are the odds that you will be using the system for some purpose, including fresh install, when you notice it has happened?

It's not dead I just tested changing the BIOS time with hwclock using a 14.1 boot USB; no problem at all. I can set the date, power down, and boot back into the 14.1 USB and the right time is reported from hwclock (with no errors). But then when I switch to 14.2, I'm back to 1970 and "ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: Invalid argument" from hwclock. So I'm certain that this is not a hardware/battery problem.

1 members found this post helpful.

Hmmm... interesting, but not conclusive.

Does it remain correct in the BIOS (I mean as seen in the BIOS setup), but only reported incorrectly by Slackware 14.2? Or after booting to 14.2, if you then enter the BIOS setup, does it also have an incorrect date/time?

The only definitive way to say it is not the battery, is to change the battery.

As far as I know, there is no BIOS setup with libreboot (just a grub payload). But I can put it this way:

1) Start with machine powered off.
2) Boot 14.1 USB -> Set time/date manually with 'date --set' -> sync with 'hwclock --systohc --localtime' (no error) -> Power down.
3) Boot 14.1 USB -> 'hwclock' returns the correct time/date (no error) -> Power down.
4) Boot 14.2 -> 'hwclock' returns "hwclock: ioctl(RTC_RD_TIME) to /dev/rtc to read the time failed: Invalid argument" -> System time is Thu 1st Jan 1970, 10AM -> Power down.
5) Boot 14.1 USB -> 'hwclock' returns Thu Jan 1st 1970 10AM (no error).

Perfectly repeatable unfortunately. No way the problem is a flat battery.

1 members found this post helpful.

Way!

The fact that you must reset it in 14.1 indicates that it is in fact incorrect in the hardware clock (BIOS).

The fact that 14.1 reads it and 14.2 does not may result from any number of parameters from different access patterns, different timings, everything that has gone before during the boot which affects BIOS battery drain... with a marginal battery voltage one kernel might easily trip it while the other does not.

There _may_ be some other cause, but until you have actually changed the battery, you have not eliminated the battery as the possible cause. Eliminate the obvious first.

(Meanwhile, I am actually looking into other possible causes - but for confidence, how old is this system, and presumably the CMOS battery? What are the basic system specs, CPU, motherboard, etc.?)

You do not understand. Nothing needs to be "reset" in 14.1, I was just making the point of showing that it had been set in the example to be clear (it's a non-persistent USB). Step 3 (powering down and booting back into 14.1) can be repeated ad infinitum (i.e. normal computer use), nothing changes with the hardware clock, nothing needs to be reset. The hardware clock stays accurate permanently; that's not difficult to understand. The only thing that introduces the failure is booting into 14.2 (step 4).

To put it as simply as possible, when I use only 14.1 there is never any problem with the hardware clock. The time persists across boots (even into a non-persistent USB). hwclock does not throw errors. As soon as I boot into 14.2, I get errors from hwclock and the time is reset to 1970.

The machine is this. Yes it's old. If I am inclined to, I will just return to 14.1 and let the issue rest. But I would like to use 14.2, hence I would like to see if I can fix this. Changing the battery is not the answer when I have already demonstrated that 14.1 functions as expected.

But from your steps above...

...which would indicate that the hardware clock (i.e. battery) is in fact dead...

Differences in configuration between your 14.1 and 14.2 defaults may be masking that from your perspective in some way, but from here all indications are that the CMOS battery is toast.

I am not familiar at all with that brand, but it would be unusual if it did not have some UEFI/BIOS access. It might be worth looking into their support docs or even emailing them, but that could answer this and many other questions.

Anyway, I hope you get it sorted, just trying to helpful.

Hopefully someone else can jump in here with other ideas.

The whole point of the exercise was to show that the hardware DOES keep time; except when 14.2 is booted. If the battery is really dead (hardware), how can it possibly be keeping time across a full power down and non-persistent boots of the Slackware 14.1 installer? What software could possibly make dead hardware work?

As I've tried to show many times; the hardware works. If this battery is "toast" then 14.1 must be a very magical release

Libreboot BIOS settings (not really a brand btw). Yes, I will keeping trying and contact the libreboot devs.

I appreciate the effort.

2 members found this post helpful.