Date resets after rebase to f42

I have rebased to F42. But after rebasing the / date is reset. Date has become 1970. My hardware time is correct. Any solution?

$ ll /
total 52
lrwxrwxrwx.   1 root root    7 Jan  1  1970 bin -> usr/bin
drwxr-xr-x.   7 root root 4096 Mar 26 17:54 boot
drwxr-xr-x.  21 root root 4520 Mar 26 17:54 dev
drwxr-xr-x.   1 root root 4348 Mar 26 17:54 etc
lrwxrwxrwx.   1 root root    8 Jan  1  1970 home -> var/home
lrwxrwxrwx.   1 root root    7 Jan  1  1970 lib -> usr/lib
lrwxrwxrwx.   1 root root    9 Jan  1  1970 lib64 -> usr/lib64
lrwxrwxrwx.   1 root root    9 Jan  1  1970 media -> run/media
lrwxrwxrwx.   1 root root    7 Jan  1  1970 mnt -> var/mnt
lrwxrwxrwx.   1 root root    7 Jan  1  1970 opt -> var/opt
lrwxrwxrwx.   1 root root   14 Jan  1  1970 ostree -> sysroot/ostree
dr-xr-xr-x. 388 root root    0 Mar 26 17:54 proc
lrwxrwxrwx.   1 root root   12 Jan  1  1970 root -> var/roothome
drwxr-xr-x.  51 root root 1340 Mar 26 17:54 run
lrwxrwxrwx.   1 root root    8 Jan  1  1970 sbin -> usr/sbin
lrwxrwxrwx.   1 root root    7 Jan  1  1970 srv -> var/srv
dr-xr-xr-x.  13 root root    0 Mar 26 17:54 sys
drwxr-xr-x.   1 root root   74 Jan  1 01:05 sysroot
drwxrwxrwt.  26 root root 1460 Mar 28 11:18 tmp
drwxr-xr-x.  11 root root  224 Jan  1  1970 usr
drwxr-xr-x.   1 root root  228 Mar 26 17:54 var

These are the dates found in the distributed kinoite image, and there is nothing you can do about it. Only the dates in the writable parts of your system is really relevant. These are your home directory as well as /etc and /var.

2 Likes

Try timedatectl

sudo timedatectl set-timezone Europe/Berlin

For example

The reports of 1970 indicates that the dates on disk are stored as 0.
This is nothing to do with timezones.

2 Likes

A date of 1970 would seem to indicate that the RTC has lost battery backup and when that happens the first power on starts at the beginning of the epoch. Jan 1 1970.

Consider replacing the battery on the mobo which is the backup for the rtc when no power is applied.

I have also seen this happen with a bios firmware update.

I don’t know of any other way this may happen except on SBCs that have no rtc on the mobo. Those SBCs such as the RPi get the correct date/time as soon as they connect to the internet.

You said the hardware time is correct. Does that mean that the bios setup menu displays the correct UTC date & time?

The OP stated that " My hardware time is correct". The timestamps on the files in the read-only kinoite image are set when the image is built at the build server and can’t later be influenced by the local time.

1 Like

Even on a Rpi that has no RTC the time is automatically set correctly.

This is becuase booting a Fedora system uses NTP to sync the time.
This will be true of live images as well.

As it happens I have a x86 system with a RTC battery issue and it always boot to the correct time, becuase of NTP.

I also asked this, to find out how the OP was getting that information.

Only after connecting to the internet or another ntp service.

On Silverblue I have

root@fedora:~# ls -l /usr
total 8
drwxr-xr-x. 1 root root 29572 Jan  1  1970 bin
drwxr-xr-x. 1 root root  3936 Jan  1  1970 etc
drwxr-xr-x. 1 root root     0 Jan  1  1970 games
drwxr-xr-x. 1 root root    26 Jan  1  1970 include
drwxr-xr-x. 1 root root   822 Jan  1  1970 lib
drwxr-xr-x. 1 root root 88818 Jan  1  1970 lib64
drwxr-xr-x. 1 root root  8206 Jan  1  1970 libexec
lrwxrwxrwx. 3 root root    15 Jan 29 08:08 local -> ../var/usrlocal
drwxr-xr-x. 1 root root 10988 Jan  1  1970 sbin
drwxr-xr-x. 1 root root  3816 Jan  1  1970 share
drwxr-xr-x. 1 root root    24 Jan  1  1970 src
lrwxrwxrwx. 3 root root    10 Jan 29 08:08 tmp -> ../var/tmp
root@fedora:~# 

and roughly 100000 other files dated Jan 1970.

1 Like

For the records, the date of these directories is 1970 also on Fedora CoreOS 41.20250302.1.0

1 Like

systemd has code to set the time to the latest systemd build time if the RTC isn’t working or if it is set way in the past. This happens in initrd before mounting any file systems.

sudo hwclock --show
shows the correct synchronized time

Thanks for confirming it is not only me.