I'm running Fedora on my Raspberry Pi 4b. I recently tried to upgrade the release from Fedora 38 to Fedora 39 Beta. After the system-upgrade reboot, I got pages of errors about certificates not yet being valid. I realized that my system clock was set about 10 days in the past, September 17th to be exact.

Since the upgrade reboot doesn't come up with a network connection, ntp doesn't set the time. But the time isn't January 1, 1970. So where was this 10-day-old time coming from?

Since I have a pijuice hat, I spent a bunch of time trying to get the RTC to handle the issue in the upgrade. Eventually I decided it would be simpler to find the source of September 17th and change that.

It turns out systemd in the absence of a source of time such as an RTC at initialization sets the system time to systemd's build time. Ok, I don't want to rebuild systemd. So what else can be done?

systemd will also use a kernel command-line parameter to seed the system time: systemd.clock_usec. That allowed me to set the RPi time to something after the certificate-valid dates and enable the system upgrade to proceed.

Since after a full boot my RPi would have its time set correctly by ntp, I determined the initial time by looking at:

journalctl -b -0

As a quick refresher, here's what to do with systemd.clock_usec in Fedora:

• pick the time you want;

  date +%s

  will give you epoch time in seconds right “now” which is a good place to start; make it into usec by adding 6 0's to the end

• edit /etc/default/grub; find the line GRUB_CMDLINE_LINUX and add another argument to the end inside the quotes; after making the edit, my line looked like this:

  GRUB_CMDLINE_LINUX="rhgb quiet console=tty0 systemd.clock_usec=1696097631000000"

• regenerate grub config like this:

  sudo grub2-mkconfig -o /boot/grub2/grub.cfg

• prepare for the disti upgrade and do the system-upgrade reboot

After you are done with your upgrade, remove the systemd.clock_usec to put your system back to normal.