Quick PSA: how to create a new F30 toolbox container and migrate your old packages

Project Discussion
1

So with the Silverblue branch for F30 set up and the beta around the corner, I figured it was time to stop running toolbox --release 29 enter to use my old F29 toolbox and upgrade it + renam—oh wait, you can’t rename podman containers. Well, then…

I just decided to create a new toolbox container for Fedora 30 and figured I should write this here for anyone else coming along.

Creating the container

registry.fedoraproject.org’s F30 toolbox image is still targeting rawhide. Now, the easiest way to grab a proper branched 30 is to create the image with toolbox create --candidate-registry, which will use the candidate registry that has a branched F30 toolbox image.

Failing that (for some reason), you can convert the rawhide image to a branched one via:

sudo dnf config-manager --set-enabled fedora --set-enabled fedora-modular --set-enabled updates --set-enabled updates-modular
sudo dnf config-manager --set-disabled rawhide --set-disabled rawhide-modular
sudo dnf distro-sync

If you already ran an upgrade as rawhide, you’ll have to add a --releasever 30 to distro-sync.

Moving your packages

Of course, I don’t want to trial-and-error all the packages I want. There are three steps to moving them all over:

Run a system upgrade

Yes, you should run a full upgrade first, sudo dnf upgrade.

Move over your repos

You can run sudo dnf repolist to see all your enabled repos. The TL;DR for the most common ones:

  • RPMFusion: Follow the standard directions.
  • Negativo17 multimedia: sudo dnf config-manager --add-repo=https://negativo17.org/repos/fedora-multimedia.repo.
  • Any COPRs: sudo dnf copr enable -y copr-name-goes-here, make sure there’s an F30 version. If not, you can kindly email the maintainer asking them to enable F30 builds (and maybe wait for the beta to release first).
  • Any that you may not know the source from: If it properly uses $releasever, you can cp /etc/yum.repos.d/my-repo.repo to your $HOME on your old F29 container and then cp it in your new container. That being said, I’d question how you ended up with repos you don’t know the source for…

Actually installing the packages

Run sudo dnf history userinstalled to see all installed package and flag down any you may want to remove. Next, we’re going to generate a list of all the installed packages (excluding the ones you want to remove) from the F29 container:

dnf repoquery --qf '%{name}' --userinstalled | grep -Ev 'debuginfo|^fedora-' > ~/playground/f29-package-list

This will list all the packages, excluding the fedora-release and debuginfo ones. If you want to add more, add them to the end of the regex, e.g. if you want to omit zstd then the new regex would be debuginfo|^fedora|zstd.

Now you can install them in the new container:

sudo xargs -a ~/f29-package-list dnf install -y

If you also want the debuginfo packages, you can grab them with this running on the F29 toolbox:

dnf repoquery --qf '%{name}' --userinstalled | grep -Po '^.*(?=-debuginfo$)' > ~/f29-debuginfo-list

And then run this on the F30 toolbox:

sudo xargs -a ~/f29-debuginfo-list dnf debuginfo-install -y

Happy toolboxing! (Err, tool boxing? Tool-boxing? Toolboxxing? Ehh…)

1 Like
2

Even without the renaming issue, how can you upgrade a toolbox container?
https://discussion.fedoraproject.org/t/how-to-upgrade-fedora-version-inside-a-toolbox-container/67464

3

You really shouldn’t upgrade toolbox containers from one version of Fedora to another. It’s much better to recreate them with the same manually installed packageset (as dependencies can change).

I wrote about this too a while back:

I have a script to create my containers, so throwing them away and creating a new one is easy. Upgrading to a new Fedora base is usually just incrementing a number in the script, from 34 to 35.

A coworker of mine runs his own custom variant of Silverblue, modified to use Sway instead of GNOME. (Public lightweight sway developer desktop with OSTree and podman/toolbox · Martin Pitt) But he also uses toolboxes and has scripts to automate his building too. My script is very similar to an older version of his (it’s a fork): build-devtoolbox · master · Garrett LeSage / silverblue · GitLab — this has a bunch of stuff that I use for development. If you use something similar, I’d suggest highly customizing it to the packages you want installed.

As for finding the packages you’ve installed, that’s above in this post or in the post I linked. The summary I wrote in the other post to find the manual packages you installed in your old container and to install the same set in the new one is:

  1. Run the history command in your old toolbox:
    dnf repoquery --userinstalled --disableexcludes=all --queryformat "%{name}" > packages.txt
  2. Edit the packages.txt file and remove the first line and anything you don’t recognize
  3. Create a new toolbox
  4. Run the dnf install command in the new toolbox:
    sudo dnf install --skip-broken $(cat packages.txt)

More details are in the post (Any tips and tricks for upgrading? - #6 by garrett), but that’s the gist of it.

Also: Normally, when you do upgrade your base Silverblue installation, you can still run your old containers, like running a Fedora 34 container on Fedora 35 Silverblue. However, at the moment, there’s a bug preventing this… but it’s being worked on: Toolbox fails to start on Fedora 35 - #2 by garrett

So it’s usually possible to postpone replacing your old toolbox containers with new ones, but this time around, the aforementioned bug prevents that. You’ll have to replace your old containers with new ones (or rebase back to Fedora 34 until the bug is fixed).

1 Like