On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote:
On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
- distribution - https://bugzilla.redhat.com/2242759 - NEW
dnf system-upgrade fails on some RPi4 due to system boot date that pre- dates gpg key
We're still kinda kicking around ideas for "fixing" this, but I think if push comes to shove, we'll wind up revoting or waiving it as not practically fixable.
Not adding to the ticket (because "me too" is not useful there), but... I think Fedora should include SOME type of "fake hwclock"-type thing for systems with no RTC (make a systemd service depend on /dev/rtc not existing?), as other RPi-targeted distros do. This isn't RPi-specific, a number of the small boards have no RTC. I do typically add an RTC to my Pis, but not always (for various reasons).
We already have systemd-timesyncd. On startup, it syncs the time to the mtime of:
- /var/lib/systemd/timesync/clock file; or
- /usr/lib/clock-epoch file; or
- a time derived from the source tree at build time
timesyncd is mentioned in the bug, but I didn't read everything.
There are several ways we could certainly address the bug going forward. Say, starting with a Fedora 40 Change. But it seems less clear how we could safely fix it for upgrades from F37 or F38 to F39, without pushing a level of change that is inappropriate for a stable release.
On Sat, Oct 21, 2023 at 8:12 AM Adam Williamson adamwill@fedoraproject.org wrote:
On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote:
On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
- distribution - https://bugzilla.redhat.com/2242759 - NEW
dnf system-upgrade fails on some RPi4 due to system boot date that pre- dates gpg key
We're still kinda kicking around ideas for "fixing" this, but I think if push comes to shove, we'll wind up revoting or waiving it as not practically fixable.
Not adding to the ticket (because "me too" is not useful there), but... I think Fedora should include SOME type of "fake hwclock"-type thing for systems with no RTC (make a systemd service depend on /dev/rtc not existing?), as other RPi-targeted distros do. This isn't RPi-specific, a number of the small boards have no RTC. I do typically add an RTC to my Pis, but not always (for various reasons).
We already have systemd-timesyncd. On startup, it syncs the time to the mtime of:
- /var/lib/systemd/timesync/clock file; or
- /usr/lib/clock-epoch file; or
- a time derived from the source tree at build time
timesyncd is mentioned in the bug, but I didn't read everything.
There are several ways we could certainly address the bug going forward. Say, starting with a Fedora 40 Change. But it seems less clear how we could safely fix it for upgrades from F37 or F38 to F39, without pushing a level of change that is inappropriate for a stable release.
Could we initialize the time with the timestamp of the initrd and then update the timestamp to the current time after that? That should work around this specific problem, I think?
-- 真実はいつも一つ！/ Always, there's only one truth!
-
Adam Williamson -
Neal Gompa