Fixing automatic rpm-ostree updates

General
1

Fedora Discussion

My Github post

Automatic updates are needed but can cause trouble.

I experimented a bit and think I found a pretty good way to drastically improve them.

Core issues:

  • do not respect metered networks
  • always run also when on low battery
  • may run under high load
  • may be wanted to only run on AC
  • no message displayed, which may be needed to pin a deployment before testing out a new NVIDIA driver etc.

I would be happy if you can test the resulting systemd service and timer, so that we can implement it in ublue.

2

A little off topic from Bluefin or other custom images, but Bazzite actually fixes the following:

  • always run also when on low battery
  • may run under high load

May want to take a look at how Bazzite uses system76-scheduler and the config for it.

  • no message displayed, which may be needed to pin a deployment before testing out a new NVIDIA driver etc.

We used to have this, but removed it because users found it annoying. Most of the intended audience for our image play video games, so notifications coming up telling them their system was updating gave us complaints. You can enable it manually though in /etc/ublue-update/ublue-update.toml but I’m not sure if every image has this.

Anyways, this does not help you if you do not use Bazzite, but it is possible to do some of these things. I think others should look at this thread and give their thoughts too.

1 Like
3

Yeah we fixed just about everything in that thread like two years ago lol.

4

Found the main config

Will take a look at it!

This seems to only solve the metered network issue, but not the AC and batterystate issues, which are easy fixes though, should I open PRs for adding these?

And also it seems to have the same issue, that if the condition was not met, it will wait a full period until testing again. If a user is in metered wifi 23h a day and still wants automatic updates, this will cause the system to likely never update, right? You would need a timer that runs every 15min or so, and the service itself pauses for the wanted period, AFTER successfully updating the system.

@nicknamenamenick yes that is true, I am also struggling a bit with that.

5 options:

  • dont display notifications at all, or somehow only displayed with a little searching, like a textfile in the users homedir
  • display them and they disappear quickly, users may be able to see them in the notification history (Which not every system has)
  • display them so that they dont disappear
  • display non-disappearing messages only when the db diff contained an app (string) that should be tested. By default this could be NVIDIA, but people could put all sorts of apps in a specific configfile, for example non-backwards compatible layered programs. Only if one of these is updated, the message appears, maybe as a warning, maybe interactive.
  • display them using zenity or kdialog, and make them interactive so that users can opt-out anytime.

I think the last option is really rare, but users mentioned that. Having a persistent notification would also already be good for them, as they could pin the current deployment before NVIDIA is broken after reboot or something.

It is a difficult thing to solve, thats for sure.

5

Check here:

1 Like
6

okay wow this is of course it. Why are there 2 different implementations?

and is the “Persistent=true” a solution for the said “23h metered” edge case scenario?

oh and this also looks like it is incompatible with this PR in upstream Fedora, allowing unprivileged (nonwheel) users to update, as the polkit rule seems to only allow wheel users to execute the update service?

7

One is just stock for the main images as we don’t want too much opinion there, we just want to turn on what fedora uses. ublue-update is what you’d opt into for your custom image and what covers most use cases.

Not sure, file an issue in ublue-update and someone with more knowledge than me can take a look, thanks!

If it breaks we’ll fix it. :smiley:

1 Like