How do I actually poweroff after `dnf offline-upgrade reboot`?

Based on the output of dnf offline-upgrade --help I assumed that including the --poweroff switch would power off the machine after installing upgrades, but that didn’t work. After dnf offline-upgrade --poweroff reboot my PC did install upgrades as expected, did not power off after that. So how do I actually power off after upgrades?

Personally I never use an offline upgrade. My concern is the same as with a major system upgrade that involves a forced reboot managed automatically. I have several things installed that require some time delay after a kernel update occurs while the drivers are being compiled and installed to match the new kernel and interrupting that process can cause corruption and driver failure.

Just looking at your command above I seem to see what may be conflicting options. --poweroff and reboot seem to potentially be trying two different actions and might be the issue.

I would think from reviewing the content shown with dnf offline-upgrade --help that you may be better served using dnf offline-upgrade --poweroff upgrade instead.

1 Like

If they are akmods then they get automatically rebuilt during the next boot following an offline upgrade. For example this applies to Nvidia and VirtualBox modules installed from RPM Fusion.

This results in trigger file does not exist. exiting quietly.

This is definitely meant to work. What happens instead? It reboots at the end?

1 Like

That’s what happened to me, yeah. After I entered the command dnf offline-upgrade --poweroff reboot my PC rebooted, installed upgrades, and then rebooted again instead of shutting down like I expected. Afterwards I even checked and made sure that I included the --poweroff flag, and sure enough it was there. Could it be a matter of argument order? As in maybe it needs to be dnf offline-upgrade reboot --poweroff instead? I’ll try that next time.

I tried it in a VM and had the same experience. DNF is in fact calling systemctl poweroff:

Mar 07 14:48:42 fedora python3[860]: Upgrade complete! Cleaning up and powering off...
Mar 07 14:48:42 fedora dnf-3[860]: Cleaning up downloaded data...
Mar 07 14:48:42 fedora systemd-logind[1501]: The system will power off now!
Mar 07 14:48:42 fedora systemd-logind[1501]: System is powering down.

But then later:

Mar 07 14:48:43 fedora systemd[1]: dnf-system-upgrade.service: Main process exited, code=killed, status=15/TERM
Mar 07 14:48:43 fedora systemd[1]: dnf-system-upgrade.service: Failed with result 'signal'.
Mar 07 14:48:43 fedora systemd[1]: Stopped dnf-system-upgrade.service - System Upgrade using DNF.
Mar 07 14:48:43 fedora systemd[1]: dnf-system-upgrade.service: Triggering OnFailure= dependencies.

What seems to have happened is that systemd stopped dnf-system-upgrade.service by sending SIGTERM, which is fine for normal services, but since 2016 that’s interpreted as a failure for Type=oneshot . That triggers OnFailure=dnf-system-upgrade-cleanup.service, which runs systemctl reboot.

As a oneshot service, it needs to exit before systemd terminates it, or possibly it could add SuccessExitStatus=SIGTERM as a workaround.

If you see the same log output on your system, you can open an issue if you’d like, but this is all slated for replacement with dnf5

2 Likes

I see, thanks for looking into it. If the plugin is on its way out anyway then I don’t think it makes sense to open an issue. Thanks again.

The issue would allow for a fix for f39 and f40, it will be f41 until dnf5 is the default.

1 Like