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...