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.

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.