RTC date 100 years ahead

[borispr]

HP Microserver Gen7 and Rocky linux 8
after installation have got system time 100 years ahead (so had problems with https)
chronyd fixes system time, but RTC remains in future
Local time: Fri 2023-08-25 09:35:29
RTC time: Wed 2123-08-25 09:35:29

Suppose it’s about Y2K correction. Does it have any settings how to fix the year?

[LinuxGuy1997]

Is the time/date totally incorrect in the system BIOS? One potential easy fix for this is to enter the BIOS Setup on your HP and correct the date/time settings there, if needed.

You also can make changes to the RTC via the command line in linux, but it can be a bit tricky…

[borispr]

BIOS time is correct.
hwclock --systohc sets everything correct except year
seems that is wrong y2k correction while reading hw clock

[iwalker]

Try:

timedatectl set-local-rtc 0

it would also be good to see the full output from timedatectl, so:

[root@rocky8 ~]# timedatectl 
               Local time: Sun 2023-08-27 10:43:14 CEST
           Universal time: Sun 2023-08-27 08:43:14 UTC
                 RTC time: Sun 2023-08-27 08:43:15
                Time zone: Europe/Warsaw (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

for example. That way, we can see if something else is amiss, but try the previous command I gave to reset RTC. BTW, this has nothing to do with Y2K.

[borispr]

[root@hpmicro ~]# timedatectl
Local time: Sun 2023-08-27 13:11:50 EEST
Universal time: Sun 2023-08-27 10:11:50 UTC
RTC time: Fri 2123-08-27 10:11:50
Time zone: Europe/Vilnius (EEST, +0300)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
[root@hpmicro ~]# timedatectl set-local-rtc 0
[root@hpmicro ~]# timedatectl
Local time: Sun 2023-08-27 13:12:11 EEST
Universal time: Sun 2023-08-27 10:12:11 UTC
RTC time: Fri 2123-08-27 10:12:11
Time zone: Europe/Vilnius (EEST, +0300)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

[iwalker]

Hmm, so googling also suggests trying:

timedatectl set-local rtc 1

but I would also take a look at /etc/adjtime as well, mine looks like this:

[root@rocky8 ~]# cat /etc/adjtime 
0.0 0 0.0
0
UTC

there are also some threads about Fujitsu servers syncing RTC themselves, so disabling the option in the BIOS for these servers helped out. Not sure if you have such an option in the BIOS for your server. I know it’s not Fujitsu, but perhaps HP has something similar.

Either way, localtime and UTC is shown perfectly, there just seems to be some kind of offset for RTC somewhere. Obviously the normal date command shows things perfectly - the only time I’ve seen issues is the date time being incorrect, but the normal timedatectl commands would help fix that.

Anyway, let us know after trying the above timedatectl command, and also checking the contents of /etc/adjtime.

I’ve had issues with time syncing to hwclock before due to the /etc/adjtime file. This file can be deleted, and then using the usual commands to sync to the hwclock would generate a new /etc/adjtime in most cases fixing the offset issue.

[borispr]

timedatectl set-local-rtc 1
this boolean defines whether RTC is UTC or local time. it changes the hour of RTC, but not the year.
put zeros in adjtime also change nothing
right now in case there is no internet and chronyd cannot set correct date and time I run command after boot
[ $(date +%Y) -ge 2100 ] && date +%Y-%m-%d\ %H:%M:%S -s “20$(date +%y-%m-%d\ %H:%M:%S)”

before rocky linux 8 there was centos 7 and the year was correct

[LinuxGuy1997]

Definitely a bizarre issue – quite interesting!

Well, if the date and time when viewed from within the system BIOS utility is correct, the problem was not present when it was running on CentOS 7, and only started with RL8… I’m thinking of two possibilities:

1. there is a bug in whatever kernel RTC driver is in use now that you’re on RL8, or
2. there is a BIOS bug which is causing the issue with the RTC driver used in the current RL8 kernel

If nothing else, I’d definitely recommend ensuring you have the latest BIOS for this older system (which can be somewhat difficult as HPE usually requires a paid support subscription for these sorts of things).

Beyond that, perhaps investigating which RTC driver is in use by the current kernel vs. the one on CentOS7; could always try temporarily booting a CentOS 7.9 installer, dropping to the console to check the /sys/class/rtc/ device tree…

[borispr]

This server works 24x7 storing video from ip cameras. I’ll try to boot it into centos 7 but don’t know when.