I’ve been stuck on Fedora 41 for a but too long and finally had the time to dig into what’s going wrong with it. I’ve tried an incremental upgrade to 42, an upgrade to 43, and an upgrade to 44 by updating the GPG key.
All fail after reboot and revert back to 41.
This has all been in the teminal with the DNF system plugin using this guide:
type or paste code here
and output of cat /var/log/dnf5.log | grep ERROR reveals this:
2025-06-27T00:00:07+0000 [1061] ERROR [rpm] Verifying a signature using certificate 466CF2D8B60BC3057AA9453ED0622462E99D6AD1 (Fedora (41) <fedora-41-primary@fedoraproject.org>):
2025-06-27T00:00:07+0000 [1061] ERROR [rpm] rpmdbNextIterator: skipping h# 37507
2025-06-27T00:00:07+0000 [1061] ERROR [rpm] Verifying a signature using certificate 466CF2D8B60BC3057AA9453ED0622462E99D6AD1 (Fedora (41) <fedora-41-primary@fedoraproject.org>):
2025-06-27T00:00:07+0000 [1061] ERROR [rpm] rpmdbNextIterator: skipping h# 37512
2025-06-27T00:00:12+0000 [1061] ERROR [rpm] Verifying a signature using certificate B0F4950458F69E1150C6C5EDC8AC4916105EF944 (Fedora (42) <fedora-42-primary@fedoraproject.org>):
2025-06-27T00:00:12+0000 [1061] ERROR [rpm] /usr/lib/sysimage/libdnf5/offline/./packages/kernel-devel-6.19.14-108.fc42.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 105ef944: BAD
2025-06-27T00:00:12+0000 [1061] ERROR Command returned error: Failed to read package header from file "/usr/lib/sysimage/libdnf5/offline/./packages/kernel-devel-6.19.14-108.fc42.x86_64.rpm"
Notably the RTC on my motherboard does not work in the BIOS version that works with the rest of my hardware. I have a custom systemd service to jump chrony to the correct time when waking from sleep.
I am unsure of the best way to work around this when doing a system update or if there’s a better more permanent way of working around my clock issues.
so mine is a custom service I made and it lives at /etc/systemd/system/sync_time.service
it looks like this now:
[Unit]
Description=Sync RTC after wake from suspend because firmware updates to the MOBO are a HOE!!!
After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target
[Service]
Type=simple
ExecStart=/bin/chronyc -a makestep
User=root
#Environment=DISPLAY=:0
[Install]
WantedBy=sleep.target suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target system-update-pre.target
I’m not super clear on how to implement this. I’m assuming I have to do this as a systemd service so it happens at boot before the rest of the upgrade proceeds???
Nope - that’s what I’d use. It’s just files on disk so you could actively empty /usr/lib/sysimage/libdnf5/offline but the net result would be the same.
How about upgrading from 41 to 43, and skipping 42 out.
I’d tried that previously to similar effect. I think I needed an --allowerasing tag due to some conflicts. I’m giving the distro-sync method Vladislav had mentioned a try
sleep.target
A special target unit that is pulled in by suspend.target, hibernate.target, suspend-then-hibernate.target, and
hybrid-sleep.target and may be used to hook units into the sleep state logic.
In order to hook external programs before the actual system sleep operation, place their command line in a service
unit file's ExecStart= line (use Type=oneshot), and ensure the unit is pulled in by sleep.target and ordered before
it. In order to hook program code after the actual system sleep operation (i.e. to be run after the system woke up
again), place the command in ExecStop= instead, and make sure to enable StopWhenUnneeded= and RemainAfterExit=. Both
approaches can be combined into one unit file in order to run programs both before and after the sleep operation.
Example 1. Combined Example
[Unit]
DefaultDependencies=no
StopWhenUnneeded=yes
Before=sleep.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/some-before-command
ExecStop=/usr/bin/some-after-command
[Install]
WantedBy=sleep.target
I only do this before a system-upgrade on my raspberry pi.
As a normal boot will start chronyd abd set the time from the network.
But setting the ti e using chrony does not happen when doing a system-upgrade.
This is a good reason to switch to systemd-timesyncd that activates before offline upgrade and has it’s own automatic timestamp to deal with incorrect RTC.
There can be good reasons to switch to sd-typesyncd, but this is not one of them.
The file /usr/lib/clock-epoch is read by systemd itself according to man systemd
SYSTEM CLOCK EPOCH
When systemd is started or restarted, it may set the system clock to the
“epoch”. This mechanism is used to ensure that the system clock remains
somewhat reasonably initialized and roughly monotonic across reboots, in
case no battery-backed local RTC is available or it does not work
correctly.
Automation helps avoid human errors and this way it should just work for any future offline upgrades with minimal footprint and without the need to reinvent the wheel.