Hi, I’d like to talk about plans for Silverblue 30. First, it’s really cool to see the growing community here!
First, I would like to enable automatic updates by default, particularly for the rpm-ostree side - ideally including automating reboots. See this issue. It probably makes sense though for Silverblue to instead have this logic driven entirely by gnome-software. I may see if I can spend some time there.
Second, now that Fedora flatpaks exist, we should consider having FSB30 come with some out of the box. I’d love to see progress on actually shipping Firefox as a flatpak by default (anyone have a handy issue for that?).
Third, we just merged a PR to add fedora-toolbox. I think this helps to close a very important gap in our UX out of the box. I have only played with it a little bit myself (I have some custom scripts on top of podman I’ve been using for a while and changing my development workflow is a bit involved).
We also have an outstanding issue where we discussed alignment with the CoreOS side - which for us the toolbox is more about system-level debugging (want real root).
I’d love to get to the point where we have the Terminal app potentially even drop people directly into a toolbox shell - along with automatic updates, this helps a lot to de-emphasize doing things on the host.
Another thing I want to mention that I’ve been working on a bit in the background is reworking the build configuration to be compatible with coreos-assembler. This has some neat benefits (it makes building custom Silverblue-like systems way easier), and also aligns things better with the Fedora CoreOS direction (“dd to disk” install path instead of Anaconda), etc. Practically speaking though (since we need to support dm-crypt e.g.) I suspect the likely result of this would be that we’d support both. I can’t say for sure this work will land in FSB30 but I just want to highlight the work on it (the desktop system I’m typing on was installed via this method).
That’s about all I can see myself committing to work on some this cycle. Any thoughts? How does this align with other people’s plans?
The ability to install non-free software as “easily” as I can on Fedora Workstation, Arch Linux or Ubuntu. My laptop is useless without being able to access my NVidia 1050Ti GPU, for example.
All devices work out of the box on Silverblue if they work on another distro.
The rest is pretty much just cleaning up the documentation. I’ve got most of my workflow running except for the NVidia GPU and my SpiderOak One backup, which installs to /opt and symlinks in /usr.
Firefox as a flatpak? There’s already a flatpak for Nightly; it shouldn’t be difficult to make one for stable.
In the list of all pending updates, it might be cool if we could see what changed by the last update or since last visited that window. As when we get several updates staged until we reboot, we read mostly the same diffs again and again when we look for what has changed lately, and if this is worth a reboot.
Hello,
I have been using Fedora Silverblue since F28, through F29 beta, and current F29 (beta2?). When speaking of update/rollbacks, in the original light that was the concept of Silverblue as I understood it, being the separation of OS and Apps such that each could independently update without an adverse affect on stability of the running system. Plus the added benefit of being able to rollback to a known good state in the event of a near catastrophic failure, were the reasons I chose to use it. The promise of stability when using leading edge/near bleeding edge software is too hard to resist. As I write this note the automatic update and restart through Gnome Software is functioning, congrats. If I could have some more relating to the topic you linked in on it, I would ask for the ability to build different ostree images and select them freely at boot up.
WRT Fedora Flatpaks, I agree, more should be part of the Silverblue standard install. At least the minimum a user would expect to be there when they first turn on their brand spanking new OS.
I have used fedora-toolbox a bit, and notice it is now in F29SB if you do a clean install to bare metal.
Your last item is, I suspect, going to help with one of my wish list items, being able to easily build ostree images to my own flavour and select them freely at boot time. Thank you!
Actually I was talking about Gnome-software reacts differently when on normal Fedora and Silverblue. On Silverblue it actually installs first ( and the progress bar doesn’t work and button changes into cancel) and they restarts to boot into the updated deployment. That’s why I suggested “Update and Restart”.
Ah, points taken. The progress bar not responding to/receiving status updates is annoying for sure, and certainly could lead some to think the install was frozen and react prematurely. I thought the updating process was similar to the workstation version. I’ll pay closer attention the next time.
OK so I installed a couple of flatpaks via Gnome-software and there was updating of the progress bar for those, although a noticeable pause at the beginning. There was an update to do for two flatpak items that also had (sort of) progress indicators on the respective update buttons.
Well, It seems “auto updates” for flatpaks doesn’t work for some reason on both of my machines running Silverblue.
On top of that, rpm-ostree override remove $app_name doesn’t actually remove the app. The app still gets updates. The command only disables it which is kind of weird.
There are two ways to solve this:
Create a minimal my very own compose tree but the docs are empty.
Use normal Fedora as for now and keep testing Silverblue on a VM.
I’m going with the second one as of now. I will continue to test Silverblue on a VM.
The rpm-ostree override command is not for flatpak apps, only for the layered apps and lib’s you need on the basic ostree image. The flatpak apps would have to be downgraded/upgraded via flatpak, and that is merely and installation of the specific version you want. I don’t know how Gnome Software is handling the distinction between say something like App X version 1 was installed by user Z and there is also App X version 2 already on the system, when update time comes around. That’s an interesting question. Most things you can do with the rpm-ostree are to be done with the ostree command at the terminal, since rpm-ostree itself has a very limited set of commands.
Okay, I get your point there. I don’t personally ever allow an update to just happen, I like to review them before I implement. A life of Windows updates that broke my proprietary but critical use software setup’s, after applying updates freely and automatically led to that form of paranoia. So I just don’t auto-update anything, ever.
I’ll set my autoupdate on in Gnome SW and see what happens. It shouldn’t take too long there are updates happening pretty consistently from what I have noticed.
rpm-ostree override remove is designed to remove packages that are part of the base image. Packages you layer would be removed via rpm-ostree uninstall.
In addition, as mentioned by others, Flatpaks are completely unrelated to rpm-ostree. To remove a Flatpak, you’d run flatpak uninstall app-name. You can consult the Flatpak docs for more commands.
I think there is a bit of misunderstanding here. I said two different issues.
The first one was related to the auto updating of flatpaks in Gnome software.
The second was removal of a package which is included by default in the base ostree image.
Talking about the first one, it seems gnome-software doesn’t respect user settings. But that is hardly the problem,
But the problem was with rpm-ostree. Upon removing a package from base ostree, it still get updates. That means it doesn’t get removed. This is why I said in point 1 to build a custom ostree image which will not include some of the application that I don’t like…
I currently have podman and buildah downgraded on my image. I’ll watch for the next update to the ostree and note whether they get upgraded or stay the same. When I downgraded both podman and buildah, I did it separately and both times when the ostree image was written locally it noted the downgrade(s) as well as the number of layered packages. I thought the OS image was already stored on a server and the updating mechanism took that image and built a new one locally to reflect the current local running image makeup.
You are not alone in that interest for sure. There are others in the community that have expressed the same.
I should have clarified that my intention was this thread was to coordinate work people are either already planning on or willing to do - as well as to comment on those work items. So for example the automatic updates work needs coordination between the rpm-ostree and gnome-software developers.
Another good use of this thread then is if you have been using the existing automatic “staging” and have hit problems. Or trying out fedora-toolbox and how it compares with whatever container tools you’re using today.
But I guess at this point we should probably take the discussion of the individual items to the issue tracker or so.
