Bug 1926567
| Summary: | Can't enter a container based on an Alpine image | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Alex Jia <ajia> |
| Component: | toolbox | Assignee: | Debarshi Ray <debarshir> |
| Status: | CLOSED WONTFIX | QA Contact: | Alex Jia <ajia> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8.4 | CC: | debarshir, harrymichal |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | 8.4 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-04-16 20:15:49 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Alex Jia
2021-02-09 04:24:24 UTC
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. |