I’ve made several attempts to upgrade a Fedora Server 43 installation to 44 following the official DNF upgrade guide. The upgrade consistently gets stuck at the %posttrans step for the rootfiles package.
I’ve asked around on the internet and learned that the posttrans script for the rootfiles package is essentially nothing but a comment, which makes this problem even more confusing.
This system was installed using Fedora Server 43 (so it has not been upgraded before) and the only additional repositories present on this system are Remi’s. I have not made any significant changes to the system, apart from installing standard packages from the official and Remi’s repo’s.
You can get the log of the offline upgrade from dnf using dnf offline log command.
That command lists all the offline upgrade. Use dnf offline log --number=X where X is the last log.
Do you see any errors or other clues towards the end of the log?
Thank you, that seems to be revealing some things. And it’s really weird.
I have a couple of rootless podman containers running on this machine under various user accounts which are started automatically using the podman-restart service. Apparently, as the DNF offline logs show, it is continuously trying to start all these containers during the offline upgrade process… I didn’t even know that was possible.
The log file is huge because I let the upgrade run for quite a while (over 4 hours), but quickly scanning over it I don’t really see anything obvious standing out, other than the containers trying to start.
Is this a known thing? How can I solve this? I mean I suppose I could temporarily disable the auto restart of the containers but that seems like a workaround (if it even solves the problem) rather than a fix.
I finally had a successful upgrade. It seems like the containers weren’t to blame after all, well at least not directly. The log shows that systemd kept trying to execute something (I’m not sure what exactly that would be) for lingering users. Only after I disabled lingering for all users the upgrade succeeded.
Here’s the relevant part of the log:
Aug 26 04:09:52 localhost systemd[1]: Queuing reload/restart jobs for marked units…
Aug 26 04:09:52 localhost systemd[1]: Reloading user@1003.service - User Manager for UID 1003...
Aug 26 04:09:52 localhost systemd[605]: Received SIGRTMIN+25 from PID 1 (systemd).
Aug 26 04:09:52 localhost systemd[605]: Reexecuting.
Aug 26 04:09:52 localhost systemd[1]: Reloading user@1004.service - User Manager for UID 1004...
Aug 26 04:09:52 localhost systemd[606]: Received SIGRTMIN+25 from PID 1 (systemd).
Aug 26 04:09:52 localhost systemd[606]: Reexecuting.
Aug 26 04:09:52 localhost systemd[1]: Reloading user@1002.service - User Manager for UID 1002...
Aug 26 04:09:52 localhost systemd[604]: Received SIGRTMIN+25 from PID 1 (systemd).
Aug 26 04:09:52 localhost systemd[604]: Reexecuting.
Aug 26 04:09:52 localhost systemd[607]: Received SIGRTMIN+25 from PID 1 (systemd).
Aug 26 04:09:52 localhost systemd[1]: Reloading user@1005.service - User Manager for UID 1005...
Aug 26 04:09:52 localhost systemd[607]: Reexecuting.
Aug 26 04:09:52 localhost systemd[1]: Reloaded user@1002.service - User Manager for UID 1002.
Aug 26 04:09:52 localhost systemd[605]: Reexecuting.
Aug 26 04:09:52 localhost systemd[1]: Reloading user@1004.service - User Manager for UID 1004...
Aug 26 04:09:52 localhost systemd[606]: Received SIGRTMIN+25 from PID 1 (systemd).
Aug 26 04:09:52 localhost systemd[606]: Reexecuting.
Aug 26 04:09:52 localhost systemd[1]: Reloading user@1002.service - User Manager for UID 1002...
Aug 26 04:09:52 localhost systemd[604]: Received SIGRTMIN+25 from PID 1 (systemd).
Aug 26 04:09:52 localhost systemd[604]: Reexecuting.
Aug 26 04:09:52 localhost systemd[607]: Received SIGRTMIN+25 from PID 1 (systemd).
Aug 26 04:09:52 localhost systemd[1]: Reloading user@1005.service - User Manager for UID 1005...
Aug 26 04:09:52 localhost systemd[607]: Reexecuting.
Aug 26 04:09:52 localhost systemd[1]: Reloaded user@1002.service - User Manager for UID 1002.
Aug 26 04:09:52 localhost systemd[1]: Reloaded user@1005.service - User Manager for UID 1005.
Aug 26 04:09:52 localhost systemd[1]: Reloaded user@1003.service - User Manager for UID 1003.
Aug 26 04:09:52 localhost systemd[1]: Reloaded user@1004.service - User Manager for UID 1004.
Aug 26 04:09:52 localhost systemd[1]: Got disconnect on API bus.
Aug 26 04:23:42 localhost systemd[1]: Received SIGINT.
Aug 26 04:23:42 localhost systemd[1]: Activating special unit reboot.target...
I don’t know enough about the internals of systemd/DNF to judge whether this is a bug or not, would this be worth reporting?