Fixing rpm-ostree automatic updates!

Project Discussion
, ,
21

I dont know what you mean exactly, but my persistent notify-send message showing all package chages should deal with that. If you see that a package caused an issue, you can just boot in the fallback deployment 1 or pin the current one.

To the backwards compatibility again, the current message should help with that.

So we have a passive message that will not disappear. How to implement a good way to pause updates and pin the current one?

I would like a kdialog/zenity with the changed packages and buttons

  • reboot now
  • pin this deployment
  • rollback & pause updates (with input field for amount of days)

To sum up by perspective, I think your need for staying on a specific version is not the norm, so autoupdates should be opt-out and this way would be woooorlds better than what we currently have. And also similar to how Linux Mint etc. do it.

1 Like
22

It would be for anyone using a containerized work flow that was dependant on Podman.

1 Like
23

Yeah for sure. Excluding packages in rpm-ostree does not exist, even though that would be the best solution.

But such a dialog should still solve this issue.

24

Right, and that makes sense. The Fedora Atomic model is slightly different than ours, in that we strongly discourage any injection of non-default rpm’s into the system root.

That being said, we also do provide a persistent notification, via dbus to the user, when “new” updates are available, advising the user to reboot. So if you are in an edge case like that, you could still reboot, and be aware that you might need to reboot into the prior snapshot. Which for Fedora Atomics, the rough equivalent would be selecting the previous deployment at the grub screen.

It’s not a one-to-one comparison, and I hope I’m not confusing people, but it is a solvable problem.

2 Likes
25

True, this message could improve the process.

26

It’s a pretty big deal. A recent example would be Blender excluding support for hardware when going from version 3.x to 4.x or versions in between. An automatic update would have destroyed any work done, forcing you to revert, and maintain or mask an application from updating.

There’s an interesting Github Argument about these things i do not recommend peoiple waste time reading. I chimed in to aid the user into finding a the last point release, building a Manifest file and building a flatpak, then setting up a mask to avoid the update disaster waiting to happen.

2 Likes
27

Damn good work! Yes for sure if things like that happen, it is a huge deal.

An alternative method would be installing an old RPM in a (rootful or rootless) Distrobox and masking it with DNF which should also work in most cases, even if some hardware privileges would be needed.

28

So just to go a little deeper in the example, The last point release if I recall was Blender 3.8x, did not get a flatpak and that version went to Blender 4 ( which was already a big deal ).
The Flatpak team does not build / maintain LTS specific versions and does not often offer point release from LTS versions, a double negative. Needless to say, the jump in versions totally skipped over the drop in hardware. I personally can build, maintain, and mask software but this is not specific to people who are creatives. It far too technical.
The same could be said for LibreOffice and it’s “Still” releases but that software is not too hardware dependent unless built with Hardware Acceleration to take advantage of HSA.

Unfortunately, the “Just run toolbox/Distrobox” does not work for everyone.

1 Like
29

This would be a good case for a podman container. Download the rpm, pin it somehow and add all the surrounding stuff. Maybe run it in offline mode.

Then users can use a single podman run command to get the app. Ublue does this with OBS and Davinci Resolve AMDGPUPro I think.

1 Like
30

Which is essentially flatpak mask without having to write a Dockerfile with all requirements and forwarding Display to the container, while running it as root? but that then leads you back to the toolbox/distrobox build to run a rootless container !

The never ending cycle ! TBH, Writing manifest, dockerfile, and building toolbox images for a non developer is hard, let alone troubleshooting these issues. There just needs to be a better way, hopefully on the horizon.

31

Well, Appimages are not.

Dnf is safe against issues when masking an app and updating the rest, right? But some day there will be compatibility issues.

1 Like
32

AppImages? ? ? My friend, I have many a thing to teach/discuss with you then. :sunglasses: fuse-3? · Issue #1120 · AppImage/AppImageKit · GitHub

The truth is, for our containerized future, we need Portals. it’s the only way. I’m no zealot, but the functionality it offers, is the :100: way.

My container projects a thing or two I have posted here on the forums, are ways to functionally help users move into the rpm-ostree future we will have for various workloads and requirements. Many things need to happen, this includes your OP of Auto Updates, which I half agree with in the present, but definitely in the future.

For now this is the way. :100:

1 Like
33

I am confused by that issue. It is resolved but I could not find where it was solved. Is fuse3 finally done?

This does not resolve the tons of issues with Appimages but for this specific case (which should generally not be normal, people should never rely on unmaintained software) they may be perfect.

Same with yuzu, I missed backing up the flatpak files and now its gone


But tbh I think this discussion should be moved to another thread :smiley:

34

Can you find the manifest and build it yourself? Keep localized build, it will not update.

1 Like
35

Okay back to the automatic updates:

UBlue Discussion

Ublue just enables Fedoras automatic updates here.

Their own method uses topgrade which is some complex “update everything there is at once” app, to reduce/outsource complexity. They have basically the same as I did in their ublue-update which is opt-in in images.

So I suppose ublue-update is a bit complex to implement in Fedora? But it ticks all the boxes. Apart from that, changing the existing rpm-ostreed-automatic to add the needed changes would be the way to go.

They also had problems with notifications, as there are many ways they could be done.

Priority is to not annoy users, but warn when they could cause problems.

My idea would be to only warn when rpm-ostree db diff contains a word in a specific file, by default nvidia drivers, but possibly more. That would allow users to get a warning if a problematic package got updated, so that they can pin the current deployment.

2 Likes
36

Some pretty interesting reads there. Some more topics sure to pop up from them.

37

This is a good argument for keeping the 6-month release, 13-month life cycle for Atomic Desktops — and for providing our own stream of Flatpaks for each. That way, you can digest big change on your own terms — and with Flatpaks done in that way, separately for each application. (Flatpak and GNOME Software might need some modification to be able to handle multiple versions more cleanly
 I know it’s not designed for that and I’m not sure of the current state.)

2 Likes
38

As a silverblue user I still don’t see why the automatic updates shouldn’t be handled by the software stores. Most of the problems raised seem to me like a problem of the implementation. A current less optimal implementation doesn’t mean that the store shouldn’t handle it. Let me try to explain what I think.

  • they arent even updating but just fetching updates, and still take so much time and resources. Stopping it leads to crashes on Plasma6 currently, 50% of the time.

Yes, the store downloads the update so it can be applied the next boot. The resources are more of a implementation problem, and I don’t think moving it out of the store will help much. Isn’t the store only triggering rpm-ostree so it updates?

  • it makes them really unpleasing to use for searching and installing Flatpak apps, which should be their only use case (apart from firmware updates)

Sure, that is annoying, but could probably be improved and it is not like the problem doesn’t exist when installing flatpaks (in gnome software anyway). But lets say the rpm-ostree upgrade stuff is moved out of the store. Where would a user see the updated packages? How would a user trigger a manual update? If that is the store, there is no guarantee that this will fix the problem.

  • only update on power (AC) connected (optional but may be required)
  • only update when the battery is over a certain percentage

This would be great. But probably not required because rpm-ostree wouldn’t break the install if the computer unexpectedly loses power or crashes. Isn’t that one of ostree’s most important design goals?

  • the stores start slower and stay in the background, annoying users.

How does something that stays in the background annoy users? Genuinely curious. I personally don’t notice things that are running in the background. Update notifications though, those do annoy me. If a update breaks something after a reboot, I would just do another reboot and select the older version in grub. What would be a great addition is maybe a label on the reboot button.

I think you have pointed out some important problems, but I don’t think moving it out of the store is necessarily the solution. A user expects the software store to update the system, moving it into a service makes it less visible.

It’s not like I completely disagree, I do see some advantages of moving it out of the store. A good argument would be that when moving it out of the store all editions can use the same auto-update implementation. And this implementation can receive all the focus. But this would still not convince me though, otherwise I wouldn’t write this post.

Note that I do not have any experience with the software stores on other editions than silverblue,
and am just a user and not an expert on this topic. But to me it seems a step backwards for the user experience. I do think some of the proposed things are great though, a GUI option for rpm-ostree rollback or a more accessible grub would be great.

2 Likes
39

My current position is that automatic updates are the responsibility of the software manager apps on each variant. GNOME Software, Plasma Discover, etc. The stores are the graphical interface exposed to users to manage their systems, update it and manage applications.

If you want the stores to behave differently then the changes should happen there.

Auto-updates are already enabled in GNOME Software. Plasma Discover is coming “soon” once the bugs are fixed: Changes/KDEKinoiteAutoUpdateByDefault - Fedora Project Wiki

3 Likes
40

Yes I understand this stance.

My point would be that a standalone implementation may be pretty simple.

On Plasma autoupdates are enabled somewhere kinda hidden in systemsettings. The store is just for displaying and clicking. (Which is the opt-in approach I think is fundamentally broken). So I dont know if your statement is true, it seems the UI for autoupdates is not in Discover?

Discover/ the stores could be used for opt-out actions, for example actions when critical updates where detected. I am on OCI ublue so I never did an ostree version upgrade and dont know the UI, will try it out.

On GNOME Software idk, but I imagine adding a separate tab for managing updates with the wanted details would not match the “GNOME philosophy” ?