I think the alpine image might not be suitable for creating a Toolbox container.

Could you please paste the logs from:
$ podman start --attach alpine

I believe I know what's causing the issue. Toolbox uses as the entry-point of toolboxes (container) itself (as in the binary /usr/bin/toolbox). This binary is a Go binary that requires to be dynamically linked to libc (this is due to the way Go works). The most common implementation of libc is glibc. But instead of glibc, Alpine uses musl.

I just tried manually to run Podman with settings in Toolbox with Alpine and when running ldd on Toolbox (I had it mounted inside of the container just like Toolbox does it), I got this:

/ # ldd /usr/bin/toolbox
	/lib64/ld-linux-x86-64.so.2 (0x7efe598be000)
	libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7efe598be000)
	libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7efe598be000)
Error relocating /usr/bin/toolbox: __vfprintf_chk: symbol not found
Error relocating /usr/bin/toolbox: __fprintf_chk: symbol not found

I'm not proficient with libc but basically musl is not compatible with Toolbox.

This is expected behaviour because unlike Podman, that aims to work with all OCI containers (reps. images), Toolbox aims to work only with supported images. Keep in mind that Toolbox is not meant to be used on servers or in cloud but on the desktop (in general, manully by human beings). Of course, there may be a lucky coincidence when an image works with Toolbox but those cases are not most likely tested and there is no guarantee of that case always working.

I assume that all of the RHEL images are supported, it still has several small issues:

1. rhel7 images
[root@ibm-x3650m4-01-vm-02 ~]# toolbox create --image registry.access.redhat.com/rhel7
Image required to create toolbox container.
Download registry.access.redhat.com/rhel7 (500MB)? [y/N]: y                                <----  '500MB' is a hard code in here I think
Created container: rhel7
Enter with: toolbox enter rhel7
[root@ibm-x3650m4-01-vm-02 ~]# toolbox list
CONTAINER ID  CONTAINER NAME    CREATED        STATUS      IMAGE NAME
997fc0b78a98  rhel7             8 seconds ago  configured  registry.access.redhat.com/rhel7

[root@ibm-x3650m4-01-vm-02 ~]# toolbox enter rhel7
bash: /usr/lib/os-release: No such file or directory                                       <---- /usr/lib/os-release doesn't exist on rhel7 images
⬢[root@toolbox ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.9 (Maipo)

2. ubi8 images
[root@ibm-x3650m4-01-vm-02 ~]# toolbox create --image registry.access.redhat.com/ubi8/ubi:8.3
Image required to create toolbox container.
Download registry.access.redhat.com/ubi8/ubi:8.3 (500MB)? [y/N]: y
Created container: rhel-toolbox-8.3
Enter with: toolbox enter --release 8.3                                                    <---- '--release 8.3' is inconsistent w/ above created container name
[root@ibm-x3650m4-01-vm-02 ~]# toolbox list
CONTAINER ID  CONTAINER NAME    CREATED         STATUS      IMAGE NAME
0068fed1e220  rhel-toolbox-8.3  11 seconds ago  configured  registry.access.redhat.com/ubi8/ubi:8.3

NOTE: although I can enter container by '--release 8.3', it seems we have different rule, 
it's okay for me if it's a design on purpose.

3. the command option for toolbox list
[root@ibm-x3650m4-01-vm-02 ~]# toolbox list --images                                       <---- nothing is listed in here
[root@ibm-x3650m4-01-vm-02 ~]# toolbox list --containers
CONTAINER ID  CONTAINER NAME    CREATED       STATUS   IMAGE NAME
0068fed1e220  rhel-toolbox-8.3  13 hours ago  running  registry.access.redhat.com/ubi8/ubi:8.3
997fc0b78a98  rhel7             13 hours ago  running  registry.access.redhat.com/rhel7

[root@ibm-x3650m4-01-vm-02 ~]# podman images
REPOSITORY                              TAG     IMAGE ID      CREATED      SIZE
registry.access.redhat.com/ubi8/ubi     8.3     4199acc83c6a  13 days ago  213 MB
registry.access.redhat.com/rhel7        latest  bff1b259e2a6  2 weeks ago  216 MB

[root@ibm-x3650m4-01-vm-02 ~]# podman ps
CONTAINER ID  IMAGE                                    COMMAND               CREATED       STATUS           PORTS   NAMES
0068fed1e220  registry.access.redhat.com/ubi8/ubi:8.3  toolbox --verbose...  13 hours ago  Up 13 hours ago          rhel-toolbox-8.3
997fc0b78a98  registry.access.redhat.com/rhel7         toolbox --verbose...  13 hours ago  Up 13 hours ago          rhel7

[root@ibm-x3650m4-01-vm-02 ~]# toolbox list -h|grep "toolbox images"
       List only toolbox images, not containers.
   List existing toolbox images only


NOTE: what's the 'toolbox images' in help documentation? thanks!

Yes, the "500MB" string is hard coded. It's a historical relic from back when Toolbox was implemented in POSIX shell and there was no easy way to query the size of an image on a registry using command line tools. Now that we use Go, this should be fixable.

I am curious about the second point. Why do you think "--release 8.3" is inconsistent? I think that what's happening here is that Toolbox sees that you have a RHEL 8.3 host, and even though you explicitly specified the image, it realized that there's a more concise way to enter the container that doesn't require remembering the name of the container or the image.

Good question about "toolbox images". The idea was that not every OCI image out there is fit for creating Toolbox containers. The Alpine image you tried is a good example. Also, the entry point of Toolbox containers expect certain command line tools to be present without which it will error out and the container would be unusable.

That's why in Fedora we have an explicit fedora-toolbox OCI image with the com.github.containers.toolbox="true" label. The label is intended to mark it as "toolbox image" and is a way for the image maintainer to declare that this image is fit to be used to create Toolbox containers. Except, we don't consistently check for this label for all commands. If we did, we wouldn't be able to create Toolbox containers out of UBI, for example. In other words, this concept isn't fully baked.

Right now, commands like 'list', 'rm' and 'rmi' only interact with images with the com.github.containers.toolbox="true" label, but 'create' and 'enter' don't check for it. This leads to the inconsistency that you pointed out.

I am tempted to close this bug.

The original issue about an Alpine image not working is addressed by comment 2. In short, different standard C library implementations on the host and the container will prevent the container from starting, and is a known problem. However, we don't quite plan to support any implementation other than the GNU C Library at the moment.

If we really want to have a bug to not hard-code the size of the image, then we can open a new one.

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.