Remove default distrobox config - NOT A BUG - design choice

[klmcwhirter]

Describe the bug

As mentioned elsewhere, the default config for distrobox is setup to use ubuntu-toolbox. This seems to be a carry over from the early days of this project.

But it is getting in the way of proper state detection / error reporting.

The default config should be empty.

When setting up distrobox the way I use it (with fedora-toolbox) ...

• if I end up in a place where the image referenced in my distrobox.ini does not exist (e.g., an error in the Containerfile prevents the local image from being built)
• distrobox automatically pulls ubuntu-toolbox and then tries to create the referenced container using it instead

This results in an undesirable outcome. Does not fail fast.

What did you expect to happen?

I would prefer to get an error.

If I copy /etc/distrobox/distrobox.conf to ~/.config/distrobox/distrobox.conf and change it to look like the following then I get an error instead of an incorrect result. This is the desired behavior.

container_always_pull="0"
container_generate_entry=0
container_manager=""
container_name_default=""
container_image_default=""
non_interactive="0"

Result:

$ alias box='distrobox enter -a --env=HOSTNAME=fedora41-python-dx fedora41-python-dx -- bash'
$ box
Error response from daemon: No such container: fedora41-python-dx
Create it now, out of image ? [Y/n]: 
Creating the container fedora41-python-dx
unknown shorthand flag: 'n' in -n
See 'docker pull --help'.

Shouldn't the person(s) desiring ubuntu-toolbox be required to customize their local ~/.config/distrobox/distrobox.conf instead of all the rest of us now?

Output of bootc status

No staged image present
Current booted image: ghcr.io/ublue-os/bluefin-dx-nvidia:stable
    Image version: 41.20250119.1 (2025-01-19 06:13:33 UTC)
    Image digest: sha256:dfdbfb5acd4390ed61d024aaa356568db90c20aff5c75ae76724a344f2f95cae
Current rollback image: ghcr.io/ublue-os/bluefin-dx-nvidia:stable
    Image version: 41.20250114 (2025-01-14 03:48:52 UTC)
    Image digest: sha256:d6b172709a6a09bb9a309c3beb4ce970ed3724a005af8eaee897040203ba4ae6

Output of groups

klmcw wheel docker incus-admin libvirt

Extra information or context

I am in the process of creating a sophisticated set of OCI images whose purpose are to be used for both distrobox and dev containers.

I will need to add to this setup over time as I encounter projects that use different sets of technologies. E.g., nodejs, zig (for wasm) and python in a multi-repo for my pi-day-2025-with-py project.

I have to create a series of OCI images to make sure pre-requisites are installed; and can build on each other. The result is that the OCI image layers are shared between whatever distroboxen and dev containers I need.

The top of the image hierarchy is ghcr.io/ublue-os/fedora-toolbox:latest.

[castrojo]

I agree that we should fix this.

Can you go into more details on what you're building? Sounds interesting!

Edit: oh your link has all the info, I'll go read!

[klmcwhirter]

@castrojo , that link is an example project where I am using a .devcontainer for development.

I did not push the .devcontainer dir. But have one locally that starts like this:

Expand to see how I reference local image in `devcontainer.json`

{
	"name": "pi-day-2025",
	"image": "fedora41-zig-dx:latest",
    [snip]
}

But as I documented else where (a topic you are pretty familiar), using distrobox and dev containers together is a little challenging.

So this is my next experiment.

Note I am not 100% satisfied with it - one should not use inheritance for these type of multi-dimensional problems - but the way layers in OCI images work I get a lot of reuse. Think shared hd space usage for the same tool chains. I.e., the python layers in fedora41-*-dx are all shared - are not duplicated. See the bottom of this comment.

Here is roughly what I have so far. I have a script and a set of Containerfile files I use to create the hierarchy.

        ghcr.io/ublue-os/fedora-toolbox:latest
                        |
                fedora41-dev-base                   includes git, vscode, emacs-nw, tmux, just, fastfetch, fzf, zoxide
                        |
                fedora41-python                     includes py313, py314, py314t, tkinter, tk, gitk
               /        |       \
              /         |       fedora41-zig        includes clang, llvm, cmake, zig
             /          |             \
    fedora41-go         |              |            includes go
       |                |              |
fedora-go-dx fedora41-python-dx  fedora41-zig-dx    adds USER, GROUP - built with Containerfile.img-dx with IMG and USER build args

Expand to see the script I use to create the setup.

#!/bin/bash

# CM_OPTS="BUILDKIT_PROGRESS=plain"
CM_OPTS=""

# Make sure lets is installed first ...
curl --proto '=https' --tlsv1.2 -sSf https://lets-cli.org/install.sh | sh -s -- -b ~/.local/bin

# Create image
export DBX_CONTAINER_MANAGER=docker

dx_imgs=(fedora41-go-dx fedora41-python-dx fedora41-zig-dx)

for name in fedora41-dev-base fedora41-python fedora41-go fedora41-zig ${dx_imgs[*]}
do
    ${DBX_CONTAINER_MANAGER} stop ${name}
    ${DBX_CONTAINER_MANAGER} rm -f --volumes ${name}
    ${DBX_CONTAINER_MANAGER} rmi -f ${name}

    cf_suffix=${name}
    if [[ "${name}" =~ "-dx"$ ]]
    then
        build_args="--build-arg USER=$USER"
        build_args+=" --build-arg IMG=${name%-dx}"
        cf_suffix="img-dx"
    fi

    echo ${CM_OPTS} ${DBX_CONTAINER_MANAGER} buildx build -f Containerfile.${cf_suffix} -t ${name}:latest ${build_args} .
    ${CM_OPTS} ${DBX_CONTAINER_MANAGER} buildx build -f Containerfile.${cf_suffix} -t ${name}:latest ${build_args} .
done


# coallesce
sleep 5


# assemble

create_img_idxs=(1)
for container_idx in ${create_img_idxs[@]}
do
    # echo container_idx=${container_idx}

    container_name=${dx_imgs[${container_idx}]}

    echo DBX_CONTAINER_ALWAYS_PULL=0 distrobox assemble create --replace --name ${container_name}
    DBX_CONTAINER_ALWAYS_PULL=0 distrobox assemble create --replace --name ${container_name}
done

The idea is that I can create distrobox OR dev containers from any of the fedora41-*-dx images.

All the artifacts are pretty specific to my local setup and so I have them in a local (to my lan) git repo right now.

But I hope that gives an idea of the nature of my experiment.

Layers of fedora41-*-dx images

Note to get the most reuse, I try to put all common things in fedora-dev-base:latest. I am currently considering collapsing fedora41-dev-base and fedora41-python into fedora41-dev-base. I always need python as well as emacs-nw, tmux, etc. Keeping them separate does have a readability benefit; but makes the hierarchy a little more confusing.

Still thinking about it.

$ docker inspect fedora41-python-dx:latest | jq -r .[0].RootFS.Layers
[
  "sha256:0c2b6a377a20da8b9ac82b59bbbcfa9bd456c9b84d34e3061c7983dad7a8f099",
  "sha256:6f4594002dd81c7615b0d286661b38c93ff3a7c08c69701d07a072139766afa6",
  "sha256:c4fbfc22f91bedd7125843ff159cba09a0c277210494e260a5e3a486fc40e173",
  "sha256:0b769960c4864e57d9fa3aba8fcc775771ea94bb8c970fbc4fad45904e2c7678",
---
  "sha256:e05d71a70ad271c294da12c09f9a3ca85d38a84660aefcded4b3409eb4e40462",
  "sha256:771dd03a9949355ac9d12e05270bcb6ce52d617e13bcc36db0d649566c066709",
  "sha256:1fb9d703e4c99b20fcf25cc4b2c34a1d3981e0017e9d5a20aa1f3110c32d0e18"
]

$ docker inspect fedora41-go-dx:latest | jq -r .[0].RootFS.Layers
[
  "sha256:0c2b6a377a20da8b9ac82b59bbbcfa9bd456c9b84d34e3061c7983dad7a8f099",
  "sha256:6f4594002dd81c7615b0d286661b38c93ff3a7c08c69701d07a072139766afa6",
  "sha256:c4fbfc22f91bedd7125843ff159cba09a0c277210494e260a5e3a486fc40e173",
  "sha256:0b769960c4864e57d9fa3aba8fcc775771ea94bb8c970fbc4fad45904e2c7678",
---
  "sha256:5656f12b4b1e6ba85961328d49e8f74fcf0fe83e8feba69aa9491e1a40a235b7",
  "sha256:842fc8e951d9474c466d2242732117da4412e1ca94fa4c871f8551468598dfff",
  "sha256:8996f77b56dd86784d2dcb256b2654d83e8e26abcb16f65913cddf2694686c80",
  "sha256:5d6d1be2b6d11d87a1ff13102f18fa97f33735877aceacfd3e2a031f56216ffb"
]

 docker inspect fedora41-zig-dx:latest | jq -r .[0].RootFS.Layers
[
  "sha256:0c2b6a377a20da8b9ac82b59bbbcfa9bd456c9b84d34e3061c7983dad7a8f099",
  "sha256:6f4594002dd81c7615b0d286661b38c93ff3a7c08c69701d07a072139766afa6",
  "sha256:c4fbfc22f91bedd7125843ff159cba09a0c277210494e260a5e3a486fc40e173",
  "sha256:0b769960c4864e57d9fa3aba8fcc775771ea94bb8c970fbc4fad45904e2c7678",
---
  "sha256:fbe3697bf7e543f48a30eac92855873b1ab33404906a748463bbaa0a3e3b1b81",
  "sha256:465b4dd1ae7ab01eb4aabc6cb25e95b594c740e641e62eb19cee6f198c717a37",
  "sha256:e05d71a70ad271c294da12c09f9a3ca85d38a84660aefcded4b3409eb4e40462",
  "sha256:771dd03a9949355ac9d12e05270bcb6ce52d617e13bcc36db0d649566c066709",
  "sha256:8d2dbb7dcc585d1db0bede7f8c59aa1c38561c63eb759c8b251b381883b82967"
]

[klmcwhirter]

FYI - I do plan to post the details on universal-blue.dicourse.group when I am further along...

[klmcwhirter]

@castrojo I just pushed up the .devcontainer dir in case you would like to see what a usage of this work is about: pi-day-2025-with-py

And, I am happy to announce that I have captured my initial results of this experiment at: klmcwhirter/oci-shared-images

and have posted at Bluefin - rely on OCI layer sharing for distrobox and devcontainer.

Thanks to @tulilirockz for volunteering to take on the change for this request.

[tulilirockz]

Our distrobox config seems to not really be affecting any of this? The configuration file you sent is invalid, you want to use podman instead of docker there. I believe the only really "actionable" thing here would be to use a simpler config by not specifying the default container.

[klmcwhirter]

@tulilirockz I am going to have to disagree with you here. My testing shows the config is the root cause of the problem. But, yes, as a compromise not setting the default image would be a good start. But many of the other options override distrobox defaults and should probably be reviewed.

Current:

container_always_pull="1"
container_generate_entry=1
container_manager="podman"
container_name_default="ubuntu"
container_image_default="ghcr.io/ublue-os/ubuntu-toolbox:latest"
non_interactive="1"

Maybe?

container_always_pull="1"  # should this be set? I could argue both ways. Defer to ublue-os team.
container_generate_entry=1
container_manager="podman"

I recommend you analyze the other options as well while you are at it. Or just delete the distrbox.conf file altogether in favor of distrobox defaults.

I can understand why you would want to keep container_manager="podman" since that setting provides the best experience with Ptyxis which is part of the bluefin offering.

I override it only when I need to work with docker (e.g., for devcontainer compatibility - podman doesn't work in that context). And I do so via the env var provided for that purpose:

export DBX_CONTAINER_MANAGER=docker

But, as mentioned above, until a strategy around this can be decided upon I will continue to manage my local ~/.config/distrobox/distrobox.conf file.

Please note that I raised this issue because @castrojo made it quite clear over the many videos he has published (thank you again for those) that he put that config together to enable his own personal preferences. And it occurred to me that as this project matures as a part of Universal Blue that this should be rethought.

I am sure - especially, since your target audience is 'Chromebook' users, that things like this can become a cause for issues raised by less skilled, or skilled users who are new to Linux.

Please take your time to get this right. There is no hurry.

[castrojo]

I agree that we should just ship a stock config, let's do it at F42 so the change is documented in the release notes, that way we don't remove this midcycle.

[klmcwhirter]

Please note that the distrobox install script does not install a conf file by default.

One should be purposefully designed for Universal Blue's purposes. See Configure Distrobox for a list of options available.

Also, note that the install script defaults to PREFIX=~/.local if not run as root; PREFIX=/usr/local if run as root. Be careful if using it. But, that is how I installed it before I started using bluefin.