Toolbox not working, again

You can boot into the previous ostree deployment and pin it. Then whenever you need to use that old container you can boot that deployment. Create a new container in the new deployment if you need to for other purposes.

Thanks @mmorrell2016, but I was more worried about this being a bug than about to recover my old container.
This kind of behavior (the container fails after upgrade) doesn’t feel right and can be confusing for normal users.
I saw in a previous comment that the issue was fixed, but I got the same (or very similar) error, so I guess it’s not really fixed.
Thanks anyway for the temporary solution :smile:

1 Like

Yeah, looking at the track record of toolbox it probably is a bug. Not sure if a bug report was already submitted for this. IMO there is a lack of thorough testing on toolbox before release. I think it is because toolbox and podman are being developed independently by different groups of people and they are not working together on testing IMO.

1 Like

I wonder what you might be doing differently than my own usage of toolbox. I haven’t suffered from not being able to enter containers made with previous versions of Podman/Buildah. Didn’t even see much difference when toolbox switched from a script to current version written in Go. But I am a casual user of toolbox. I did notice

Anyway, if you can use the pinned boot to select the commit where it was running, you could commit the container image with buildah or podman. Then boot into the F32 commit you are having troubles entering the container on, and try and run it with podman. You may be able to get toolbox to create a new container based on that image.
Or you could use buildah mount to mount the containers filesystem for manipulation if you want.
In any case, my understanding of toolbox containers is that they are meant to be disposable for the most part. Plus, since they share the users home directory and environment, created content should still exist even after the container is no longer running. The same reasons to have specialized toolbox containers is also a stronger argument for me to use custom built pet containers that address specific needs, and can be built from a smaller image than a toolbox container image. Buildah is a wonderful tool for doing just that.

This was just using toolbox with the more basic workflow. Basically, toolbox create + toolbox enter, nothing fancy.

I did play with buildah to create personalized containers, but the error was with the base container and normal workflow.

I don’t mind to rollback, create a new image from the old container for later use, I’m more concern about (for example) a web dev using toolbox for his/her local development and having this kind of issues after upgrade.
I love the Silverblue model and I’d like to see it stable enough so less technical people can use it at work.

Did you file a bug with toolbox on github (Issues · containers/toolbox · GitHub)? So this can be brought to the attention of the dev’s, and maybe help others in the community with the same or similar problem.

No, actually I didn’t know where was the right place to do it. I wasn’t sure if this was a toolbox’s issue, packaging’s issue, Silberblue specific issue or known issue. After search for it, I found this thread, which looks very similar to what happen to me, so I decided to write my experience for getting some feedback or directions.

I looked again now at the Toolbox’s issues at Github and I found someone with what looks like the same problem:
“Error: failed to start container fedora-toolbox-32” on Fedora Silverblue

I’ll give my feedback there. Thanks for the pointer :slight_smile:

1 Like

~~I’m also having troubles with Toolbox on a reinstall of Silverblue. My issue appears a bit different so I opened a new bug report here: Issues · containers/toolbox · GitHub

Can anyone else replicate this issue?

I updated my rpm-ostree tonight and it works now so :man_shrugging:

Suddenly I can’t enter some of my containers any more (just relogged Desktop):

[bam@host ~]$ toolbox --verbose  enter --container kde.f33 
DEBU Running as real user ID 1001                 
DEBU Resolved absolute path to the executable as /usr/bin/toolbox 
DEBU Running on a cgroups v2 host                 
DEBU Checking if /etc/subgid and /etc/subuid have entries for user bam 
DEBU TOOLBOX_PATH is /usr/bin/toolbox             
DEBU Toolbox config directory is /home/bam/.config/toolbox 
DEBU Current Podman version is 2.0.4              
DEBU Old Podman version is 2.0.4                  
DEBU Migration not needed: Podman version 2.0.4 is unchanged 
DEBU Resolving container and image names          
DEBU Container: 'kde.f33'                         
DEBU Image: ''                                    
DEBU Release: ''                                  
DEBU Resolved container and image names           
DEBU Container: 'kde.f33'                         
DEBU Image: 'fedora-toolbox:32'                   
DEBU Release: '32'                                
DEBU Checking if container kde.f33 exists         
DEBU Calling org.freedesktop.Flatpak.SessionHelper.RequestSession 
DEBU Starting container kde.f33                   
DEBU Inspecting entry point of container kde.f33  
DEBU Entry point PID is a float64                 
DEBU Entry point of container kde.f33 is toolbox (PID=13093) 
DEBU Waiting for container kde.f33 to finish initializing 
DEBU Checking if initialization stamp /run/user/1001/toolbox/container-initialized-13093 exists 
Error: failed to initialize container kde.f33

Could someone help to debug?

@bam you could run it with podman to get more info and try to see if there is something wrong inside:

$ podman --log-level debug start --attach kde.f33

What version of toollbox and Fedora are you using?

BTW, kde.f33 is a fedora-toolbox:32 container upgraded to Fedora 33 or is just the name?
At Fedora 33 were some issues with toolbox and podman, maybe the issue comes from there…

Thanks, already did: Container doesn't start because of missing /media possibly due to failed RPM transaction · Issue #539 · containers/toolbox · GitHub, the error is:

Error: failed to redirect /media to /run/media

Toolbox version 0.0.93, Fedora Silverblue 32.
I don’t remember I upgraded it, don’t know why it’s fedora-toolbox:32

Some update. I’ve upgraded Toolbox to 0.0.94 (thanks @rishi) and it gave me more info:

[bam@host ~]$ podman --log-level debug start --attach kde.f33
...
level=debug msg="Redirecting /media to /run/media"
Error: failed to redirect /media to /run/media: remove /media: no such file or directory`

I spent 2 days trying to restore it and still fruitless. I almost give up.
I’ll have to recreate my containers from scratch if no other ideas come. It would be a less pain that struggling it further… :frowning:

It is probably time to deploy a version before the problem started.

It’s more complicated that that. For the problem to begin started, it was enough for me just re-login to the desktop session.

I’m having a toolbox issue now as well, it is really weird. It is requiring root privileges for all dnf commands but when I type in my password it tells me it is wrong. I do a podman system reset and try again but it keeps giving me this error:

/usr/bin/id: cannot find name for group ID 1000

This is a brand new installation. I keep blowing it up to do it better and this time I thought I had it… only gnome-tweaks as a layered package, everything else was working exactly as I wanted and pretty much default settings.

Anyway the toolbox is supposed to be a staple of Silverblue. What can we do to get it stable?

This is due an update of the podman version at Fedora 32. There is a known bug with toolbox + that version of podman, which is being working on:

I hope this gets fixed upstream (at podman) soon and it gets into Fedora 32, so toolbox get stable again.

I think the only way to eliminate this and other problems in the future is to make Silverblue’s podman containers covered by automated CI tests. It’s essential for an immutable system.
For now, the system is not really useful for the production use.

I think that would be a good idea. IMO, if a new podman version breaks toolbox, then it should not be integrated and if a new version of toolbox does not pass integration testing, then it should be held back too. Leave it in rawhide to cook a little longer.

1 Like

This issue as noted above, is now closed. The newest version of toolbox is 0.0.95-1.fc33 and it has fixed the problem caused by the latest podman version 2.1.0 in my case. I had to override toolbox in my Silverblue install to get this resolved, and I reset my containers since mine are ephemeral generally.

1 Like