On Silverblue, I’m keen to upgrade to Fedora 34, but keep running into the major roadblock that is the impossibility of upgrading containers given the need for a reboot to upgrade. I’ve found myself reliant on one core container in which a lot important things for day-to-day work are run (in addition have a few others for specific tasks not related to day-to-day usage) and the lack of ability to upgrade appears to make it a fairly big effort to properly update my system and get a fedora 34 container going that runs just like the core 33 one. What do you all do to upgrade? Are there any tips or tricks you have to make it frictionless?
1 Like
I’m a little confused by this question. By “container” do you mean upgrading a toolbox container from 33 to 34, or a general container using Fedora. For the latter I would just rebuild the Docker file. For the former I’m not entirely sure as I usually just throwaway and create new toolboxes. dnf history userinstalled may be of some use.
2 Likes
In addition there is nothing stopping you from keeping using your Fedora 33 toolbox container in 34, you just need to provide a--container fedora-toolbox-33 command line or something like that.
1 Like
I mean a toolbox container. Since there’s no way to update, indeed it seems that throwing away is the only way ultimately. But I rely so much on one of them, to do so will be a real pain, and certainly not something I want to do every nine months. How do you bring things over when you “throwaway and create new toolboxes”? Just looking for any good practices I can copy.
Ultimately that will be unsustainable. I’ll eventually need to move to a new container. So I’m looking for something to make it easier. Also, they way I’d set things up is the default “container” is the on that has the generalized tools, whereas the more specific containers are the project-specific ones and are specifically named. That made it easy upfront with all the “toolbox enter” and “toolbox run” that you use in Silverblue in scripts, desktop files, etc.
It’s a bummer that you can’t just update a toolbox container.
You can update a toolbox container, but it’s really much better to keep a script around to recreate it. The script is probably as simple as creating the container and installing software inside. (At least that’s what my script is.)
I’m assuming you only really care about the packages you have installed inside the toolbox, as toolboxes can access most of the host system just fine.
But, what packages do you have installed? If you haven’t kept track yourself, there’s a command to show you. Inside your existing toolbox, run:
dnf repoquery --userinstalled --disableexcludes=all --queryformat "%{name}" > packages.txt
(Edit: Better command than the original in my post. The old one was dnf history userinstalled | sed -e 's/-[0-9].*//' > packages.txt, but the above drops the need for sed and the output is more concise.)
This should be within a directory available on the host system, of course. Your home directory is fine for this. Or Documents or Downloads or wherever you choose, as long as your host system and any toolboxes you create can access the file, you’re fine.
Edit the packages.txt file (this can be done on your host system; there’s no need to edit it in a toolbox, unless you want to) and remove the first line. Then remove all the packages you don’t recognize or need. There will be a lot. The dnf history userinstalled command lists too many packages compared to what you actually installed. But it’s a great starting point.
Then, create a new toolbox container with the new version of Fedora (it will default to the same version as what you’re using on your Silverblue host). In the new container, make sure you’re in the same directory as packages.txt. Run the following in your bash shell (which is the default; other shells may be similar or slightly different) inside your new toolbox container:
sudo dnf install --skip-broken $(cat packages.txt)
This tells dnf to install the packages as listed in the file and skip any that it doesn’t understand. (If you had a third party repo, some packages might not be available.)
When you run the command, you’ll first see a summary of packages dnf found that match. And it will show you the packages it intends on installing, along with a confirmation prompt. Type “y” and hit enter, of course, to install. (We could’ve added a -y in the above command, but you should look at what’s being installed, unless you’re doing this in a script.)
Keep this package list around somewhere for the next time you need to upgrade (or start a new container from scratch), else you’ll have to repeat the process and hand-edit it again later. If you do keep it around, you might want to add to the list every time you add a package inside the container.
If you want, you can do what I do and turn the list of packages into a script that creates the toolbox, runs dnf, and contains the list of packages. Keeping the list and the one-line command above as documentation somewhere is probably enough too, unless you have needs more than just installing official Fedora packages. (My script sets up a couple 3rd party repos first, for example.)
So, because there’s a wall of text above (which explains everything, but it’s a lot), here’s a quick summary:
- Run the history command in your old toolbox:
dnf repoquery --userinstalled --disableexcludes=all --queryformat "%{name}" > packages.txt - Edit the packages.txt file and remove the first line and anything you don’t recognize
- Create a new toolbox
- Run the dnf install command in the new toolbox:
sudo dnf install --skip-broken $(cat packages.txt)
I hope this helps!
9 Likes
That is ridiculously helpful! Thank you.
I actually do have a solid list of packages that I’ve installed already via the package manager. There are also various things via npm, pip, cargo that should be pretty easy to find (though most I believe are installed in .local/bin). Then there are a few things that I’ve built I will need to make install again (maybe the odd clean build).
But ultimately there shouldn’t be a problem at all just getting a script set up for upgrades. It will be a pain this first time through, but once it’s done it should be more-or-less replicable for each upgrade (depricated packages nothwithstanding) as I have my system more-or-less where I want it now.
Indeed it’s that feeling of having things where I want them that has me nervous about an upgrade. This is my first time with Fedora at all. I’ve mostly just used Debian, with the occasional rolling distro. But for whatever reason, I’m finding Fedora to provide the ideal balance for day-to-day use. But the 9 month upgrade cycle just got real to me, because of the toolbox container reliance. So I guess it’s important to just spend the time now on the script and update it going forward.
Out of interest, though, how do you upgrade a toolbox container?
2 Likes
By re-creating it would be the only way. Containers are meant to be ephemeral. The image for the F33 container is to be found at, well you can go back as far as F29 today …
fedoraproject.org registry.fedoraproject.org/f29/fedora-toolbox
fedoraproject.org registry.fedoraproject.org/f30/fedora-toolbox
fedoraproject.org registry.fedoraproject.org/f31/fedora-toolbox
fedoraproject.org registry.fedoraproject.org/f32/fedora-toolbox
fedoraproject.org registry.fedoraproject.org/f33/fedora-toolbox
fedoraproject.org registry.fedoraproject.org/f34/fedora-toolbox
fedoraproject.org registry.fedoraproject.org/fedora
fedoraproject.org registry.fedoraproject.org/fedora-minimal
fedoraproject.org registry.fedoraproject.org/fedora-toolbox
The above is part of the output of the podman search fedora command. The registry.fedoraproject.org/fedora-toolbox image should always point to the most up to date toolbox image and so if your script was tuned with that in mind, recreation of the container would be ensuring it is always a container with an up to date Fedora image, without having to be release version specific.
Of course there are these Fedora Magazine articles about building your own …
https://fedoramagazine.org/how-to-build-fedora-container-images/ and https://fedoramagazine.org/build-smaller-containers/ for a good place to get your feet wet quickly and easily.
1 Like
Awesome. Thanks very much!
Yep you’ve totally hit on it with the concrete statement that “containers are meant to be ephemeral.” That’s exactly it and a good reminder of why I wanted to be using Silverblue in the first place.
I’ve never upgraded from version to version. But I have used Fedora 32 containers on Fedora 33 beta before (last year). There’s nothing stopping you from running a different version of Fedora (or RHEL or CentOS or even Debian or Ubuntu) in your toolboxes than what you’re using on the Silverblue host.
I have kept containers up to date with upgrades inside the toolboxes before. When there aren’t many changes, it’s quicker than rebuilding the container. But for a lot of churn, you really should build a new container.
Yeah, totally. At least for the cargo stuff and a few other minor things that are useful on the host, I do have both ~/.cargo/bin/ and ~/.bin/ in my path so containers and the host can benefit.
Yep, totally. It’s great when you’re done and can rebuild your toolbox container on a whim. Just make sure that script is backed up somewhere (off your computer), and you’ll be good for the future too. It’s pretty neat when you can pretty easily recreate your working setup if you ever need to restore from backups, switch computers, or use a secondary computer for whatever reason (such as desktop vs. laptop).
1 Like
Now I have a project! Thanks for the responses. Much appreciated.
This question actually reminded me of this: GitHub - xsuchy/fedora-upgrade: Upgrade Fedora to next version using DNF upgrade without the need to reboot during the upgrade.
A similar (probably simpler) script could be implemented for toolbox. I might do a little messing around to see what I can come up with.
I am wondering if a Dockerfile based approach might be helpful here. ie., instead of running dnf install ... inside the container, using a Dockerfile to add the extra packages to the fedora-toolbox:N image, and using that to create a container.
Just curious, because some folks have mentioned going this route in the past.