Fedora 34: can't install chromium in toolbox

Project Discussion
1

One of my toolboxes needs chromium installed. When I try to install it inside the toolbox via dnf, it fails validating the GPG keys of packages that appear to be coming from Rawhide.

Reproducer:

$ toolbox create --container chromium
$ toolbox enter --container chromium
[chromium]$ sudo dnf install -y chromium

Some concerning messages I see during the dnf install:

Module yaml error: Unexpected key in data: static_context [line 9 col 3]
...
The GPG keys listed for the "Fedora - Rawhide - Developmental packages for the next Fedora release" repository are already installed but they are not correct for this package.

Looking at the packages to be installed, many are referencing Rawhide and have f35 in their version scheme. Are the repos for Fedora 34 Silverblue misconfigured?

1 Like
2

What versions of Silverblue do you have?

rpm-ostree status

Here’s mine, for example:

                   Version: 34.20210719.0 (2021-07-19T00:46:43Z)
                BaseCommit: 7720609643b1cb0d2a69c42692d887dd0d1703e81fdf5e31f243b6bdb8fb35a6

My guess: You might have an old version of a toolbox container from around Fedora 34 beta before the container was switched. Perhaps try running:

podman pull registry.fedoraproject.org/fedora-toolbox:34

And then try again? (You’ll have to remove the toolbox chromium container if you want to re-use the same name.)

BTW: I’ve been using Chromium in containers for a long time for browser-based testing. And I just did a pull on the container (which updated it here too) and installed Chromium and it still worked. So doing a podman pull on the image will hopefully be the solution for you.

1 Like
3

I probably should have recorded that before I rolled back :frowning:.

This was, however, after a fresh rebase from Fedora 33 20210401.

I did have a few layered packages for libvirt support that may have gotten in the way - reverted those so hopefully the next rebase is “clean.”

4

Oh, I coincidentally have libvirt and a few other packages as overlays on Fedora 34 just fine. It’s specifically these packages:

gnome-boxes kexec-tools libvirt-client libvirt-dbus qemu virt-install virt-manager virt-viewer
(…and more; these are just the virtualization-related packages I have layered)

When you run rpm-ostree status it’ll list the packages you have as an overlay. I added all of mine into a script and adjust the script whenever I add or remove an overlay, so I can reset and re-add easily. If you still have your older version around, you could consult the rpm-ostree status to see what packages you did have installed previously and try to re-add them again if you need them.

It might’ve been the case that you used a Fedora 34 container while in Fedora 33 right after the branch. It took a week or two for them to update the container to F34 sources instead of rawhide (as it was an oversight) and you might have had the image still sitting around on your disk.

At least, that’s when I hit this error… but I was running the pre-betas and betas of Fedora 34 (using Silverblue) and had to use Fedora 33 containers in toolbox until this was solved. But I hadn’t seen it in a long time.

TL;DR: podman pull registry.fedoraproject.org/fedora-toolbox:34 should be your fix, hopefully?

5

Was able to revisit this, and found something peculiar. Tl;dr this seemed to work:

$ podman rmi registry.fedoraproject.org/f34/fedora-toolbox:34
$ toolbox create --container test-34
$ toolbox enter --container test-34
[test-34]$ sudo dnf install -y chromium

I initially had registry.fedoraproject.org/f34/fedora-toolbox:34 pulled onto my machine. This seems to have been an early beta version of the f34 toolbox, and hasn’t been updated in a while. When I created my new toolbox, toolbox create seemed to use that image as the base (perhaps detecting that there was an f34 toolbox already on the system).

I then removed the /f34/fedora-toolbox:34 image, and then pulled the :34 tag from the top-level fedora-toolbox repo. Afterwards, toolbox create set up my toolbox with the correct base image.

6

Hello @adambkaplan
podman system reset can also be used to remove all containers and images from the system.