As in the subject
The OS in the image that toolbox list returns is a bit old
How do I update the os of existing containers ?
And how do I update the image itself ? So that new ocntainers don’t start with an old OS ?
Please be more specific. At least the Fedora and Kernel version would be good to know.
If you speaking from toolbox as a container with sudo dnf upgrade
If you talk from official toolbox images just download/create a new one.
Manual:
Toolbox :: Fedora Docs
In general, in container-based workflows, you usually don’t update the components within containers from within the container. Though technically there is nothing stopping you from running dnf upgrade from within the container.
Typically, for containers, you want to update the underlying container image. In the case of toolbox, the podman container is “fedora-toolbox”. And you can update it by running podman image pull <image name>:<tag>. If there is a newer version of the container, this will pull it and update it as necessary.
For Example:
yosuke@Yosuke-Thinkpad$ podman image list
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.fedoraproject.org/fedora-toolbox 36 1113918107fb 2 weeks ago 496 MB
yosuke@Yosuke-Thinkpad$ podman image pull fedora-toolbox:36
Trying to pull registry.fedoraproject.org/fedora-toolbox:36...
Getting image source signatures
Copying blob e6ba7c6e6f56 skipped: already exists
Copying blob 2bfab29d2ca9 skipped: already exists
Copying config 1113918107 done
Writing manifest to image destination
Storing signatures
1113918107fb793917c01c4ecbeb94ff66a48bd2c9aa5a12b3dfd0332143fd9b
5 Likes
Thank you !
Since dnf won’t be able to reboot, you’lle need to run the sudo dnf system-upgrade upgrade step instead of the reboot subcommand.
3 Likes
As toolbox uses your home & etc etc. drive you do not loose the settings while push a new/updated toolbox.
but you would lose installed apps that you use from inside the box?
I dont think this can be a solution, as traditional containers are built for a purpose, while toolbx/distrobox containers are minimal and empty, and the acually used things are all manual.
I think @kxra 's useful comment is the solution for toolboxes
Did I say something else ?
The design of a toolbox has been made for development. If you develop something for F38 as an example you push a F38 toolbox and you do your tests/developments.
If you need to develop for F39 on the same system you push a new toolbox with F39 and do the thests/devlopments. This way you can compare in between the two versions.
From this point of view I gave my answer above.
p.s.
What is the reason that you dig in old topics with a solution? As I remember my answer was not even marked as solution, right?
I did not dig up an old topic with a solution, as I have the same problem (testing distro upgrades with dnf5 currently, which doesnt even have sudo dnf system-upgrade upgrade anymore.)
The way toolbx works is very much worse for desktop use than using rpm-ostree, even though both use OCI containers (using ublue) and add packages on top of that. Rebasing and upgrading is totally painless on rpm-ostree, how you would imagine the perfect dnf system-upgrade, but better.
It is officially recommended to use toolbx for installing RPMs when there is no Flatpak (or… Appimage if you consider that an option).
I layer small things, but 2 “monsters”, QGis and RStudio (and maybe also Libreoffice if I use want to use the Zotero Connection) need to be installed in Distrobox/Toolbox.
I use the current release fedora version for that as I cannot run prerelease software. But this means I need to
- Export config to home
podman pullordistrobox remove&createto the current Fedora version- Install the apps in the new container
- Import the configs again
- Adapt the old .desktop entries
(I think I will write a script for doing that, as it sounds pretty well automatable.)
As there is no way to reboot, there is no way to system-upgrade from within a podman container.
Toolbx and Distrobox are used for doing stuff in Podman containers that is unusual, so saying “well ackshually containers are updated with podman” is not really helpful 
I just opened an issue about a feature to do this on Distrobox. It will likely requring a lot of manual stuff but should work well.
It detects the user package manager, exports configs, upgrades the box and imports the configs again.
This topic comes from the time of F36, which has not been supported for long. Since the topic has become already several times re-opened and also got a little blurred, I close it.
Keep in mind that blurring/mixing information from different eras and packages (e.g., dnf5 was not a topic here, and also not in F36 at all) without explicit indication and delimitation is likely to cause more confusion and distract from the actual problem rather than identifying the problem anyone has as of today. Therefore, please open a new topic in case.