I use a Raspberry Pi 4 running Fedora 38 for home automation and a few small other services. Last week I wanted to update it to Fedora 39, but encountered a surprising problem - when DNF rebooted to apply the changes offline, the upgrade would not be applied.
dnf system-upgrade log revealed the packages were failing verification due to signature is not alive errors:
Mar 11 00:02:38 spud dnf-3[3922]: error: Verifying a signature using certificate E8F23996F23218640CB44CBE75CF5AC418B8E74C (Fedora (39) <fedora-39-primary@fedoraproject.org>):
Mar 11 00:02:38 spud dnf-3[3922]: Signature bbe9 created at Thu Mar 14 23:19:58 2024 invalid: signature is not alive
Mar 11 00:02:38 spud dnf-3[3922]: because: Not live until 2024-03-14T23:14:58Z
The problem appeared to be that the system was booting with a date of 11th March - and the new Fedora 39 packages were signed with a “not before” date of 14th April (which was the actual date.)
The root issue is that the Raspberry Pi’s lacks an RTC to maintain the time when powered off, and during a ‘normal’ boot, relies on a network connection and NTP to establish the correct date and time. These are not available during the offline upgrade step, and hence it was trying to perform the upgrade with the wrong time - triggering package verification failures.
Some distributions solve this using a ‘soft RTC’ like fake-hwclock, which remembers when the system last shutdown, and uses this timestamp for the next boot to get a slightly better estimation of the correct time.
However, no equivalent package is available in Fedora’s official repositories. There had to be a different way!
Turns out there was. A little extra searching for a thread reporting the same issue - and the workaround was simple:
$ sudo touch /usr/lib/clock-epoch