upgrade --reboot is silently ignored for --trigger-automatic-update-policy

[rugk]

Host system details
Fedora Iot 34

Provide the output of rpm-ostree status.

$ rpm-ostree status
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 7h ago
Deployments:
  ostree://fedora-iot:fedora/stable/aarch64/iot
                   Version: 34.20210515.0 (2021-05-15T12:49:19Z)
                BaseCommit: 0c0a876d4b5411614d386c27831dcca0113ca2abb9a31277c64d4c613e5b4ad3
              GPGSignature: Valid signature by 8C5BA6990BDB26E19F2A1A801161AE6945719A39
                      Diff: 1 upgraded
           LayeredPackages: ****

* ostree://fedora-iot:fedora/stable/aarch64/iot
                   Version: 34.20210515.0 (2021-05-15T12:49:19Z)
                BaseCommit: 0c0a876d4b5411614d386c27831dcca0113ca2abb9a31277c64d4c613e5b4ad3
              GPGSignature: Valid signature by 8C5BA6990BDB26E19F2A1A801161AE6945719A39
           LayeredPackages: ****

  ostree://fedora-iot:fedora/stable/aarch64/iot
                   Version: 34.20210508.0 (2021-05-08T12:24:06Z)
                BaseCommit: ed8c70443ee317aabfc0fea14a191a74cbe34832754d67794ec03f32ab5ffd77
              GPGSignature: Valid signature by 963A2BEB02009608FE67EA4249FD77499570FF31
           LayeredPackages: ****

Use case: I want to automatically reboot my system to apply updates. Because it makes sense, I of tried to do so after applying updates via rpm-ostreed-automatic. (Read the link for more details.)

Expected vs actual behavior

$ sudo systemctl edit rpm-ostreed-automatic.service

And enter this:

[Service]
ExecStart=
ExecStart=/usr/bin/rpm-ostree upgrade --trigger-automatic-update-policy --reboot

Now wait some time.

After some time, I saw the rpm-ostree status actually does stage the result, but it apparently did not reboot, because well… the system still uses the “old” state there…

Expected:

Similar to #2829, please:

• either show an error that the options do not work together and e.g. note that they must not be used together in the docs/help/man page/…
• or (in my case I’d prefer it) make them work (just reboot)

Steps to reproduce it

see above

Would you like to work on the issue?

No.

BTW, if you wonder what was updated there, it was a layered package apparently:

$ rpm-ostree status -v
State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: last run 7h ago
Deployments:
  ostree://fedora-iot:fedora/stable/aarch64/iot
                   Version: 34.20210515.0 (2021-05-15T12:49:19Z)
                BaseCommit: 0c0a876d4b5411614d386c27831dcca0113ca2abb9a31277c64d4c613e5b4ad3
                            |- repo-0 (2021-04-23T10:47:46Z)
                            |- repo-1 (2021-05-15T12:37:34Z)
                            |- repo-2 (2021-05-12T10:34:37Z)
                            `- repo-3 (2021-05-15T01:28:33Z)
                    Commit: 6fa3079892eb59d39663e5a7cf61f8c99b75cbfdfd18ba82b2f11f88feda690d
                            |- fedora (2021-04-23T10:47:46Z)
                            |- updates (2021-05-16T01:50:36Z)
                            `- fedora-cisco-openh264 (2021-02-23T00:49:00Z)
                    Staged: yes
                 StateRoot: fedora-iot
              GPGSignature: 1 signature
                            Signature made Sat May 15 14:49:25 2021 using RSA key ID 1161AE6945719A39
                            Good signature from "Fedora <[email protected]>"
                  Upgraded: python3-perf 5.11.19-300.fc34 -> 5.11.20-300.fc34
           LayeredPackages: ***
[…]

[jlebon]

That flag is hidden for a reason. :) The policy name is stage because it only stages the deployment. We noodled on a reboot policy a bit in #247, but as you can see at the end there, the conclusion is essentially that updates should in general be driven by higher-level software. It's likely that IoT will want the same too (possibly even reusing Zincati).

Wouldn't be opposed to a simple reboot policy which is basically just stage+reboot, though I don't think it's worth implementing the various update strategies like Zincati supports. And again, should instead chat with the IoT maintainers to see what they have planned there.

[rugk]

And again, should instead chat with the IoT maintainers to see what they have planned there.

As you can see, I did… 🙃

Wouldn't be opposed to a simple reboot policy which is basically just stage+reboot,

NIce, then would you want to track this in a new – open – issue. Currently this looks as if you’d decline that…

And BTW, I agree, as my use case also shows a very very simple “stage+reboot” is enough for me.

That flag is hidden for a reason. :)

Well… don’t you think it would be useful to show an error if I as a user try to use such a flag in a non-supported way?
After all, I could only find out that my modification to the existing service does not work though trail and error…

[jlebon]

As you can see, I did… 🙃

Ahh, can you link to that here? I don't see it. Interested in the response.

Well… don’t you think it would be useful to show an error if I as a user try to use such a flag in a non-supported way?

The flag is already marked as hidden (i.e. it doesn't show up in the --help output). But yeah, I guess we could make it more obvious by erroring upfront.

NIce, then would you want to track this in a new – open – issue. Currently this looks as if you’d decline that…

Sure, SGTM!

[rugk]

Yes, it’s mentioned here:
https://discussion.fedoraproject.org/t/what-advantages-does-fedora-iot-have-over-fedora-coreos/29719/3?u=rugk

The actual question on how to do it is here, though maybe not the best channels for raising it.

Sure, SGTM!

So… shall I create a new one or do you?

[rugk]

The question for me would be, is there any way to detect if --trigger-automatic-update-policy did some changes and trigger a reboot then? Or do I really have to resort to not using rpm-ostree’s automatic update system at all and just do rpm-ostree upgrade –reboot?

[Service]
ExecStart=
ExecStart=/usr/bin/rpm-ostree upgrade --trigger-automatic-update-policy
ExecStart=/bin/systemctl reboot

[jlebon]

Right yeah, rpm-ostree upgrade --reboot in a timer right now would more or less give you the same end result as a simple reboot policy (minus the better feedback/UX).

[rugk]

Uhm so what? Do you argue for a simple service that only contains ExecStart=/bin/systemctl reboot?

I.e. just unconditionally reboot?

If so, the problem is that even if rpm-ostree upgrade did not install any update, the reboot would happen…

[rugk]

Wouldn't be opposed to a simple reboot policy which is basically just stage+reboot,

NIce, then would you want to track this in a new – open – issue. Currently this looks as if you’d decline that…

Sure, SGTM!

So… shall I create a new one or do you?

Opened that now: #2843

[jlebon]

No, with rpm-ostree upgrade --reboot, it'll already only reboot if an upgrade actually happened.

[rugk]

with rpm-ostree upgrade --reboot, it'll already only reboot if an upgrade actually happened.

Wait sorry for the question again but: Then you have to disable AutomaticUpdatePolicy actually, as otherwise an upgrade could be staged, and rpm-ostree upgrade --reboot does not stage a new one and thus does not reboot then, does it?

[jlebon]

Right yeah, this would essentially be your own update service, so you'd disable the built-in one.