There seems to be a lot of breakage in SB30 ostree images lately. Is there any CI or manual test process run before a compose is allowed to be pushed to the SB30 repo?
I mean in this particular case, toolbox doesn’t really have much in the way if tests since it’s just a shell script, and podman does but probably just didn’t test it. It’s more just an unfortunate mix of circumstances.
I just started using Silverblue about a week ago and rebased to Silverblue 30. I want to try toolbox out. I am sure the problem will get fixed. It is a Beta after all so I should expect something is broken.
Apart from the toolbox problem I really am enjoying my experience with Silverblue right now.
The ostree compose uses the same packages that are pushed to Fedora stable, so any breakage in SB will also likely be seen in traditional Fedora, too.
toolbox is a relatively new package, so it is not out of the ordinary that problems are being uncovered.
As for CI/test, it really depends on each package. There are some standard tests run against toolbox for example (https://bodhi.fedoraproject.org/updates/FEDORA-2019-52e62c5725) but none that truly test the functionality of the package. I’m sure the maintainer would love to see some tests contributed for the package.
Silverblue on the whole gets tested by folks just using it every day. Some people are brave enough to run Rawhide and find problems early. Additionally, there is the Silverblue Test Day that gets scheduled before each major release. That is a chance for users to help out with the test of the new major version.
Thanks for the info. I was wondering about the quality process for Silverblue and was not clear if it got the same amount of testing that Fedora Workstation product did. I did go and look and I see that there is a very good CI process in place for Fedora. I was not sure if SB not being official had any impact on quality. I understand that sometimes things get through the testing process and it is good to have test days too. Unfortunately, the previous test day was before this bug occurred I guess. So does SB wait for the next upstream release of podman or toolbox to fix it, or does it get downgraded in the ostree to the earlier version until upstream it is fixed? How is that handled?
I had the same issue and from the suggestions I received from @otaylor on the Silverblue IRC, I was able to recover basically by deleting my .local info with this command sudo rm -r .local/share/containers. The first thing I tried was rm .config/containers/*.conf which didn’t solve it. Afterwards you should be able to create a pet container.
[gordy@silverblue ~]$ toolbox -v create
toolbox: Fedora generational core is f30
toolbox: base image is fedora-toolbox:30
toolbox: customized user-specific image is fedora-toolbox-gordy:30
toolbox: container is fedora-toolbox-gordy-30
toolbox: checking value /var/run/.heim_org.h5l.kcm-socket (Stream) of property Listen in sssd-kcm.socket
toolbox: parsing value /var/run/.heim_org.h5l.kcm-socket (Stream) of property Listen in sssd-kcm.socket
toolbox: checking if image fedora-toolbox-gordy:30 already exists
Error: error getting image “fedora-toolbox-gordy:30”: unable to find a name and tag match for fedora-toolbox-gordy in repotags: no such image
toolbox: looking for image localhost/fedora-toolbox:30
Pulling docker://localhost/fedora-toolbox:30
ERRO[0000] exit status 1
toolbox: looking for image registry.fedoraproject.org/f30/fedora-toolbox:30
Pulling docker://registry.fedoraproject.org/f30/fedora-toolbox:30
ERRO[0000] exit status 1
toolbox: failed to pull base image fedora-toolbox:30
[gordy@silverblue ~]$
Are you typing that at the prompt? Or is this the result you get when you type toolbox create? I’m just wondering is all. After I did blow away all containers in my local storage my problem (of not being able to pull from the registry) was solved and I could create a pet container with just issuing toolbox create, and afterwards enter it with toolbox enter. Try podman images if you have images there you should be able to see them. This is what I get …
You can see that there are two stored on my system at localhost/fedora-toolbox-ssnow:30 and localhost/fedorad-toolbox-ssnow:latest and one at registry.fedoraproject.org/f30/fedora-toolbox which is the base image the other two were pulled from. You should be able to manage the containers on your system with Podman if there are images there. If you don’t have any images showing then try to create the toolbox as noted with just using toolbox create and no options first. Post the results here if it fails, or succeeds.
sudo podman pull registry.fedoraproject.org/fedora:30
and then run:
sudo podman run -it registry.fedoraproject.org/fedora:30
but not with toolbox.
Gordy
Well that doesn’t seem to be the same issue I ran into after all. So now you have one image I would guess after having done the pull. I noticed that I can attach to my running toolbox container with podman attach but when I exit from the attached to container, then exit my running toolbox container, I cannot enter the toolbox again until I have exited the terminal session I used to attach with podman. The error I get is that the container cannot be created, and once I close the terminal I had open for podman, I can create the container.
I think you are correct. Anytime I have had recent issues with toolbox, it turned out to be a podman/buildah issue. What’s interesting is the fact I was having similar issues, in that toolbox create was failing to pull the image, but simply deleting my local storage (brute force I know) solved it for me. That would seem to indicate something I have layered is having an affect which positively benefits toolbox. It’s also interesting that issues with toolbox come and go as the Fedora release cycle progresses.
Thanks for that, I think I will use podman to pull and run the image.
I did this but it won’t save the changes in the container. Once I stop the container and go back the updates and changes have gone.
Just did an rpm-ostree upgrade and the latest fix for buildah fixed this issue for me. I run my silverblue 30 in hyperv so I had to comment out the volume mounts for /dev/bus and /dev/dri in a local copy since they do not exist, to get the toolbox to create but now I have it up and running.
