Man page for `dnf-offline-upgrade` specifies: " --poweroff When applied with the reboot subcommand, the system will power off after upgrades are completed, instead of restarting." Adding `--poweroff` doesn't change the default behaviour of `dnf offline-upgrade reboot`. The system reboots instead as without the `--poweroff` option. Reproducible: Always Steps to Reproduce: 1. `sudo dnf offline-upgrade download` 2. `sudo dnf offline-upgrade reboot --poweroff` Actual Results: 1. System reboots to upgrade in offline mode 2. System reboots after upgrade and waits for login Expected Results: 1. System reboots to upgrade in offline mode 2. System powers off after upgrade and stays shutdown $ dnf --version 4.15.1 Installed: dnf-0:4.15.1-1.fc38.noarch at Sat May 20 18:25:43 2023 Built : Fedora Project at Thu May 18 09:11:03 2023 Installed: rpm-0:4.18.1-3.fc38.x86_64 at Sun May 7 21:48:47 2023 Built : Fedora Project at Wed Apr 26 05:35:27 2023 $ dnf info dnf-plugins-core Installed Packages Name : dnf-plugins-core Version : 4.4.1 Release : 1.fc38 Architecture : noarch Size : 22 k Source : dnf-plugins-core-4.4.1-1.fc38.src.rpm Repository : @System From repo : updates Summary : Core Plugins for DNF URL : https://github.com/rpm-software-management/dnf-plugins-core License : GPL-2.0-or-later Description : Core Plugins for DNF. This package enhances DNF with builddep, : config-manager, copr, debug, debuginfo-install, download, : needs-restarting, groups-manager, repoclosure, repograph, : repomanage, reposync, changelog and repodiff commands. : Additionally provides generate_completion_cache passive plugin.
I've connected the related bug where the fix was verified in the RHEL 9: https://bugzilla.redhat.com/show_bug.cgi?id=2157844. But anyway, I've tested it in Fedora 38 VM and it really seems not working properly in some cases. First I tried (several times) using only the CLI mode (systemd target = multi-user.target). After the upgrades were installed, it rebooted the system, although according to logs, the shut down was triggered. Then I tried installing the GUI environment and setting up the graphical.target. After that, I did the same procedure and the system really shut down in the end. From the logs it seems, that in the CLI case both poweroff and reboot services were triggered for some reason. I will need to investigate it further... I am attaching the logs from CLI and GUI attempts also here.
Created attachment 1969293 [details] Journal from CLI attempt
Created attachment 1969294 [details] Journal from GUI attempt
In case of the CLI usage, dnf-system-upgrade.service gets killed before being deactivated successfully which will trigger the dnf-system-upgrade-cleanup.service doing the reboot instead of requested poweroff. The question is still why it is getting killed and why not in the GUI case...
There was a problem in missing systemd unit dependency. The following PR was created to fix this issue: https://github.com/rpm-software-management/dnf-plugins-core/pull/496.
Cloned into RHEL 9 bug: https://bugzilla.redhat.com/show_bug.cgi?id=2214510.
FEDORA-2023-dc793cd506 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-dc793cd506
FEDORA-2023-bb4b4355a7 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-bb4b4355a7
FEDORA-2023-bb4b4355a7 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-bb4b4355a7` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-bb4b4355a7 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-dc793cd506 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-dc793cd506` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-dc793cd506 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-bb4b4355a7 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-dc793cd506 has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
I hate to say that, but after upgrading I still see the same behaviour. I've confirmed that /usr/lib/systemd/system/dnf-system-upgrade.service contains the fix. I've also checked in a fresh and upgraded 38 VM. Same thing.
Created attachment 1986881 [details] Journal from offline-upgrade with poweroff option I'm also still seeing this issue. Looking through the journal, it seems like the poweroff is triggered, but then something overrides it and sends SIGTERM to dnf-system-upgrade.service. I think it's due to how systemd handles updates, looking through systemd.offline-updates(7). Here's the flow I came up with: 1. system_upgrade.py sends `systemctl poweroff` and exits. Some services start to shutdown. 2. system-update.target is reached, launching system-update-cleanup.service. 3. The cleanup service runs `ExecStart=rm -fv /system-update` on the symlink, triggering `SuccessAction=reboot` and overriding the poweroff. Based on the comments in system-update-cleanup.service, removing the `/system-update` symlink from system_upgrade.py should work. In the logs, the most interesting stuff starts at cursor "s=a695266c8a15476b81afa55a89bec9c0;i=91757;b=b6f138cf7f534435920cf49e81df2184;m=a00d78ff;t=604693a521459;x=9a6a50a0e913aec9", when the poweroff attempt begins.
Thanks Cameron for looking into this! During the next week, I will try to reproduce it and check the likely issue with the symlink.
I was checking the logs you've provided and it seems like the same cause as I've provided with the CLI attempt in Comment 2. You're right that the cleanup service is currently handling only the reboot. But the thing is, the cleanup is triggered only when the upgrade service fails (see 'OnFailure=dnf-system-upgrade-cleanup.service' in the dnf-system-upgrade.service). So, the main problem still is that for some reason, the upgrade process is killed before successfully finishing and that triggers the cleanup service and rebooting then. And according to logs, all upgrade actions should've been successfully done before the actual kill signal was sent. Perhaps, there might be issue that when triggering the systemctl poweroff from the dnf python process, it then kills the dnf process before it manages to finish successfully. Or maybe, dnf sometimes does not respond to SIGTERM properly? I was able to reproduce it in VM, but I'll definitely need to investigate further...
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
Still reproducible in Fedora 40
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
(In reply to Aoife Moloney from comment #19) > `dnf offline-upgrade reboot --poweroff` doesn't poweroff after upgrade dnf5 utilises quite different syntax. How does this remain applicable > F42?
Fedora ≥ 42 still contains dnf4.