bring your tools with you
License: Apache License 2.0
rhcos-toolbox is a small script, designed for RHEL CoreOS, that launches a podman container to let you bring in your favorite debugging or admin tools.
This project is deprecated and in maintenance mode.
We recommend that you use https://github.com/containers/toolbox instead.
... or you're going to get an error
CoreOS stable (607.0.0)
FATA[0000] Post http:///var/run/docker.sock/v1.17/images/create?fromImage=fedora%3Alatest: dial unix /var/run/docker.sock: permission denied
FATA[0000] Post http:///var/run/docker.sock/v1.17/containers/create?name=bob-fedora-latest: dial unix /var/run/docker.sock: permission denied. Are you trying to connect to a TLS-enabled daemon without TLS?
time="2015-03-18T20:47:32Z" level="fatal" msg="Get http:///var/run/docker.sock/v1.17/containers/bob-fedora-latest/export: dial unix /var/run/docker.sock: permission denied"
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
dial unix /var/run/docker.sock: permission denied. Are you trying to connect to a TLS-enabled daemon without TLS?
FATA[0000] Error: failed to remove one or more containers
touch: cannot touch '/var/lib/toolbox/bob-fedora-latest/etc/os-release': No such file or directory
Directory /var/lib/toolbox/bob-fedora-latest lacks the binary to execute or doesn't look like a binary tree. Refusing.
Issue by @MrAlias
Running toolbox --help or toolbox -h returns the systemd-nspawn help dialog, but only after running through the docker image download and setup stuff.
It would be helpful if toolbox could output some sort of relevant help dialog without running through the default docker pull and create routine. This could be as simple as the default systemd-nspawn usage info, or potentially include relevant toolbox help info.
Since connection to docker hub from China is very slow and unstable, is it possible to add --registry-mirror flag so we can start toolbox with the official Chinese registry mirror like minikube ssh toolbox --registry-mirror=https://registry.docker-cn.com ?
Windows 10 Professional
VirtualBox
Add --registry-mirror flag
minikube ssh toolbox keeps failing to pull the image with message: Error pulling image "docker://fedora:29": unable to pull docker://fedora:29: unable to pull image: Error writing blob: error storing blob to file "/var/tmp/storage282097889/1": unexpected EOF
I'm not a fan of 'mosh', however, mosh might fill a gap. cutting to the quick: The connection between my desktop(chromebook) and my development server (CoreOS running on GCE) is not reliable. Regardless of whether it's my network or because I'm moving between job sites. (have you ever seen those people who walk around with their laptops open as they go from one meeting to another?
I've logged into my CoreOS as a toolbox user. (a) only one toolbox connection at a time... probably need to launch an ssh server too (b) when I lose my connection I also lose the toolbox session. I strongly disagree with the security claims that the mosh team makes and while it's not worse than ssh it might help with the connection stuff. (unless toolbox was meant to be extremely transient)
When I launched my mosh session from my chromebook I got this:
Trying authentication type Password
Password:
Bad response when running mosh-server: 'systemd-nspawn: invalid option -- 'c'
toolbox fails to get updated image if HTTP/HTTPS Proxy is set
[root@worker-0 /]# uname -r
4.18.0-372.39.1.el8_6.x86_64
[root@worker-0 /]# rpm-ostree status
State: idle
Deployments:
* e647edffa40edfe4c3a43f88536cc969ba8810a5e32b498de0739797213da0e4
Version: 412.86.202212170457-0 (2022-12-17T05:00:56Z)
Initramfs: --omit-drivers cdrom
What hardware/cloud provider/hypervisor is being used to run toolbox?
To pull the new version of image:
There is a newer version of registry.redhat.io/rhel8/support-tools available. Would you like to pull it? [y/N]
Fails, Error parsing image name "docker://registry.redhat.io/rhel8/support-tools": pinging container registry registry.redhat.io: Get "https://registry.redhat.io/v2/": dial tcp: lookup registry.redhat.io on x.x.x.x : no such host
Steps to Reproduce:
The issue is due to proxy variables not used for skopeo but the same is used for podman.
Without patch:
# /bin/bash -x /usr/bin/toolbox
+ set -eo pipefail
+ trap cleanup EXIT
+ REGISTRY=registry.redhat.io
+ IMAGE=rhel8/support-tools
+ AUTHFILE=/var/lib/kubelet/config.json
++ whoami
+ TOOLBOX_NAME=toolbox-root
+ TOOLBOXRC=/root/.toolboxrc
+ main
+ setup
+ '[' -f /root/.toolboxrc ']'
+ TOOLBOX_IMAGE=registry.redhat.io/rhel8/support-tools
+ [[ '' =~ ^(--help|-h)$ ]]
+ run
+ image_exists
+ sudo podman image inspect registry.redhat.io/rhel8/support-tools
+ image_fresh
+ errecho 'Checking if there is a newer version of registry.redhat.io/rhel8/support-tools available...'
+ echo 'Checking if there is a newer version of registry.redhat.io/rhel8/support-tools available...'
Checking if there is a newer version of registry.redhat.io/rhel8/support-tools available...
++ sudo podman image inspect registry.redhat.io/rhel8/support-tools --format '{{.Created}}'
+ local_date='2021-03-31 13:45:06.249427 +0000 UTC'
++ sudo skopeo inspect --authfile /var/lib/kubelet/config.json docker://registry.redhat.io/rhel8/support-tools --format '{{.Created}}'
FATA[0000] Error parsing image name "docker://registry.redhat.io/rhel8/support-tools": pinging container registry registry.redhat.io: Get "https://registry.redhat.io/v2/": dial tcp: lookup registry.redhat.io on x.x.x.x:53: no such host
+ remote_date=
+ errecho 'Error inspecting registry.redhat.io/rhel8/support-tools via skopeo'
+ echo 'Error inspecting registry.redhat.io/rhel8/support-tools via skopeo'
Error inspecting registry.redhat.io/rhel8/support-tools via skopeo
+ return
++ image_runlabel
++ sudo podman image inspect registry.redhat.io/rhel8/support-tools --format '{{- if index .Labels "run" -}}{{.Labels.run}}{{- end -}}'
+ local 'runlabel=podman run -it --name NAME --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=NAME -e IMAGE=IMAGE -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host IMAGE'
+ container_exists
+ sudo podman container inspect toolbox-root
+ errecho 'Container '\''toolbox-root'\'' already exists. Trying to start...'
+ echo 'Container '\''toolbox-root'\'' already exists. Trying to start...'
Container 'toolbox-root' already exists. Trying to start...
+ errecho '(To remove the container and start with a fresh toolbox, run: sudo podman rm '\''toolbox-root'\'')'
+ echo '(To remove the container and start with a fresh toolbox, run: sudo podman rm '\''toolbox-root'\'')'
(To remove the container and start with a fresh toolbox, run: sudo podman rm 'toolbox-root')
++ container_state
++ sudo podman container inspect toolbox-root --format '{{.State.Status}}'
+ local state=exited
+ [[ exited == configured ]]
+ [[ exited == created ]]
+ [[ exited == exited ]]
+ container_start
+ sudo podman start toolbox-root
toolbox-root
+ [[ 0 -eq 0 ]]
+ errecho 'Container started successfully. To exit, type '\''exit'\''.'
+ echo 'Container started successfully. To exit, type '\''exit'\''.'
Container started successfully. To exit, type 'exit'.
+ container_exec
+ [[ 0 -eq 0 ]]
+ sudo podman attach toolbox-root
With patch --preserve-env for skopeo:
# /bin/bash -x /tmp/toolbox
+ set -eo pipefail
+ trap cleanup EXIT
+ REGISTRY=registry.redhat.io
+ IMAGE=rhel8/support-tools
+ AUTHFILE=/var/lib/kubelet/config.json
++ whoami
+ TOOLBOX_NAME=toolbox-root
+ TOOLBOXRC=/root/.toolboxrc
+ main
+ setup
+ '[' -f /root/.toolboxrc ']'
+ TOOLBOX_IMAGE=registry.redhat.io/rhel8/support-tools
+ [[ '' =~ ^(--help|-h)$ ]]
+ run
+ image_exists
+ sudo podman image inspect registry.redhat.io/rhel8/support-tools
+ image_fresh
+ errecho 'Checking if there is a newer version of registry.redhat.io/rhel8/support-tools available...'
+ echo 'Checking if there is a newer version of registry.redhat.io/rhel8/support-tools available...'
Checking if there is a newer version of registry.redhat.io/rhel8/support-tools available...
++ sudo podman image inspect registry.redhat.io/rhel8/support-tools --format '{{.Created}}'
+ local_date='2021-03-31 13:45:06.249427 +0000 UTC'
++ sudo --preserve-env skopeo inspect --authfile /var/lib/kubelet/config.json docker://registry.redhat.io/rhel8/support-tools --format '{{.Created}}'
+ remote_date='2023-01-06 17:07:04.286354791 +0000 UTC'
+ [[ 2023-01-06 17:07:04.286354791 +0000 UTC > 2021-03-31 13:45:06.249427 +0000 UTC ]]
+ read -r -p 'There is a newer version of registry.redhat.io/rhel8/support-tools available. Would you like to pull it? [y/N] '
There is a newer version of registry.redhat.io/rhel8/support-tools available. Would you like to pull it? [y/N] y
+ [[ y =~ ^([Yy][Ee][Ss]|[Yy])+$ ]]
+ image_pull
+ sudo --preserve-env podman pull --authfile /var/lib/kubelet/config.json registry.redhat.io/rhel8/support-tools
Trying to pull registry.redhat.io/rhel8/support-tools:latest...
Getting image source signatures
Checking if image destination supports signatures
Copying blob 0161491eccce done
Copying blob 649e5534d134 done
Copying config b2d8baad64 done
Writing manifest to image destination
Storing signatures
b2d8baad64dd2c1ce60642f48ea6812a3b23a30d8c130049dc799c8f1dd81e83
+ container_exists
+ sudo podman container inspect toolbox-root
+ sudo podman rm toolbox-root
1c085c2cb080d646090a5dd61464be92bbd35460546a660018003f8657f1760b
++ image_runlabel
++ sudo podman image inspect registry.redhat.io/rhel8/support-tools --format '{{- if index .Labels "run" -}}{{.Labels.run}}{{- end -}}'
+ local 'runlabel=podman run -it --name NAME --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=NAME -e IMAGE=IMAGE -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host IMAGE'
+ container_exists
+ sudo podman container inspect toolbox-root
+ errecho 'Spawning a container '\''toolbox-root'\'' with image '\''registry.redhat.io/rhel8/support-tools'\'''
+ echo 'Spawning a container '\''toolbox-root'\'' with image '\''registry.redhat.io/rhel8/support-tools'\'''
Spawning a container 'toolbox-root' with image 'registry.redhat.io/rhel8/support-tools'
+ [[ -z podman run -it --name NAME --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=NAME -e IMAGE=IMAGE -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host IMAGE ]]
+ [[ podman run -it --name NAME --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=NAME -e IMAGE=IMAGE -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host IMAGE == \<\n\o\ \v\a\l\u\e\> ]]
+ errecho 'Detected RUN label in the container image. Using that as the default...'
+ echo 'Detected RUN label in the container image. Using that as the default...'
Detected RUN label in the container image. Using that as the default...
+ container_create_runlabel
+ local pod
++ echo 'podman run -it --name NAME --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=NAME -e IMAGE=IMAGE -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host IMAGE'
++ sed 's/--name NAME/--name ${TOOLBOX_NAME}/'
++ sed 's/NAME=NAME/NAME=${TOOLBOX_NAME}/'
++ sed 's/podman run/sudo podman create/'
++ sed 's/host IMAGE/host ${TOOLBOX_IMAGE}/'
++ sed 's/IMAGE=IMAGE/IMAGE=${TOOLBOX_IMAGE}/'
+ pod='sudo podman create -it --name ${TOOLBOX_NAME} --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=${TOOLBOX_NAME} -e IMAGE=${TOOLBOX_IMAGE} -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host ${TOOLBOX_IMAGE}'
+ eval 'sudo podman create -it --name ${TOOLBOX_NAME} --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=${TOOLBOX_NAME} -e IMAGE=${TOOLBOX_IMAGE} -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host ${TOOLBOX_IMAGE}'
++ sudo podman create -it --name toolbox-root --privileged --ipc=host --net=host --pid=host -e HOST=/host -e NAME=toolbox-root -e IMAGE=registry.redhat.io/rhel8/support-tools -v /run:/run -v /var/log:/var/log -v /etc/machine-id:/etc/machine-id -v /etc/localtime:/etc/localtime -v /:/host registry.redhat.io/rhel8/support-tools
27c88f2a6b0c4d6828f0dec7cbcefa3fbc5777e6d02b7f7c40304eb853dd21b9
++ container_state
++ sudo podman container inspect toolbox-root --format '{{.State.Status}}'
+ local state=created
+ [[ created == configured ]]
+ [[ created == created ]]
+ container_start
+ sudo podman start toolbox-root
toolbox-root
+ [[ 0 -eq 0 ]]
+ errecho 'Container started successfully. To exit, type '\''exit'\''.'
+ echo 'Container started successfully. To exit, type '\''exit'\''.'
Container started successfully. To exit, type 'exit'.
+ container_exec
+ [[ 0 -eq 0 ]]
+ sudo podman attach toolbox-root
Have been a long time CoreOS user and generally I'm very happy with the ecosystem and tools, however recently we've been working to troubleshoot network performance issues that have led us to tools like Systemtap to better understand some behaviors that are occurring on the kernel level.
The toolbox being a fedora is a blocker here, since we need an exact match of all the related kernel debug/devel/build data that CoreOS is running but we can only install from fedora repos inside toolbox which doesn't match the running kernel.
We would like to be able to run low-level probing/tracing tools such as Systemtap on CoreOS, whether native or from toolbox.
I suppose, if kernel debuginfo package (and others) with the matching build config and version were available for installation in toolbox this should provide what is necessary
for these tools to work.
There doesn't seem to be a writeable TTY device inside toolbox (using an Alpine image)?
Expected behavior:
$ echo 'test' > /dev/tty
test
Actual behavior:
$ echo 'test' > /dev/tty
-bash: /dev/tty: No such device or address
Works fine on fedora, but I can't think of a reason why it wouldn't work on a custom image?
Issue by @philips
Today toolbox uses systemd-nspawn to actual execute the machine. The downside of systemd-nspawn is that there is no propagation. So, you can't say mount something inside of toolbox or unmount something that is seen in the root mount namespace.
Lets do that. Here is a prototype: https://gist.github.com/philips/acc5d812041f7a5baa2d582626cddb2a
xref rkt mount propagation rkt/rkt#1149
I have tried a number of ways to use fleetctl within toolbox.
In the parent env as the core user, fleetctl list-units works as expected via:
ETCDCTL_PEERS=http://10.0.0.12:4001,http://10.0.0.83:4001,http://10.0.0.141:4001
FLEETCTL_ENDPOINT="unix:///var/run/fleet.sock"
So I try to run this in toolbox with:
ETCDCTL_PEERS=http://10.0.0.12:4001,http://10.0.0.83:4001,http://10.0.0.141:4001 FLEETCTL_ENDPOINT="unix:///media/root/var/run/fleet.sock" /media/root/usr/bin/fleetctl list-units
And get:
Unable to initialize client: unable to use endpoint scheme unix, http/https only
What? It's happy with a unix socket in the parent but not in the toolbox container?
Am I misunderstanding how toolbox is intended to be used?
fleetctl version: 0.9.0
Coreos 1967.6.0
bare metal
Able to run smartctl commands
localhost$ toolbox --bind=/dev:/dev smartctl --all /dev/sdc
Spawning container core-fedora-latest on /var/lib/toolbox/core-fedora-latest.
Press ^] three times within 1s to kill container.
smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.14.96-coreos-r1] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
Smartctl open device: /dev/sdc failed: Operation not permitted
Container core-fedora-latest failed with error code 2.
If you create an ubuntu docker container with --privileged mode, and install run smartctl in that container, it works. It seems to be a capabilities issue of some sort.
Issue by @Signull
toolbox doesn't seem to like my insecure registry:
core@core-01 ~ $ toolbox
fetch: Get https://mysite.com/v2/: x509: certificate signed by unknown authority
core@core-01 ~ $ docker pull mysite.com/devops/toolbox:latest
latest: Pulling from ohcm_devops/toolbox
9e4b184d5239: Pull complete
e64bdf31016a: Pull complete
9c57749dc47a: Pull complete
f253a83be7e7: Pull complete
5e5d0caa74dd: Pull complete
d217d9f538e1: Pull complete
2c42d60692ff: Pull complete
734df15bff9b: Pull complete
12c576bbaea7: Pull complete
7f9ca1ad0dc7: Pull complete
adf449943f67: Pull complete
c603e9e81ab4: Pull complete
e8ee22bdfa19: Pull complete
d6feb452e43d: Pull complete
c90e9b3acf94: Pull complete
Digest: sha256:409388012ed5b1c764f5c19b4dd80ea3d6dd3f98d219a72bba9d3190fe24e446
Status: Downloaded newer image for mysite.com/devops/toolbox:latest
core@core-01 ~ $ toolbox
fetch: Get https://dockertr.es.ad.adp.com/v2/: x509: certificate signed by unknown authority
core@core-01 ~ $ which toolbox
/usr/bin/toolbox
core@core-01 ~ $ vim /usr/bin/toolbox
core@core-01 ~ $ docker run -ti mysite.com/devops/toolbox:latest bash
[root@2bf95876189b /]# exit
exit
core@core-01 ~ $ cat .toolboxrc
TOOLBOX_DOCKER_IMAGE=mysite.com/devops/toolbox
TOOLBOX_DOCKER_TAG=latest
core@core-01 ~ $
$ cat /etc/os-release
core@core-01 ~ $ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1298.1.0
VERSION_ID=1298.1.0
BUILD_ID=2017-01-20-0552
PRETTY_NAME="Container Linux by CoreOS 1298.1.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"
core@core-01 ~ $
CoreOS on AWS and Vagrant
toolbox container would startup
$ toolbox
fetch: Get https://dockertr.es.ad.adp.com/v2/: x509: certificate signed by unknown authority
Try to have your .toolboxrc file use an image from an insecure repo
I have docker set to use an insecure registry:
core@core-01 ~ $ cat /etc/systemd/system/docker.service.d/10-insecure-registry.conf
[Service]
Environment="DOCKER_OPTS=--insecure-registry mysite.com"
core@core-01 ~ $
vagrant and aws
the tool would just work.
This works
core@core-01 ~ $ sudo rkt --insecure-options=image fetch "docker://mysite.com/devops/toolbox:latest"
fetch: Get https://mysite.com/v2/: x509: certificate signed by unknown authority
core@core-01 ~ $ sudo rkt --insecure-options=all fetch "docker://mysite.com/devops/toolbox:latest"
Downloading sha256:a3ed95caeb0 [=============================] 32 B / 32 B
Downloading sha256:c90e9b3acf9 [= ] 4.08 MB / 93.5 MB
Downloading sha256:e8ee22bdfa1 [=============================] 7.72 KB / 7.72 KB
Downloading sha256:a3ed95caeb0 [=============================] 32 B / 32 B
Downloading sha256:c603e9e81ab [=============================] 307 B / 307 B
Downloading sha256:adf449943f6 [=============================] 290 B / 290 B
Downloading sha256:12c576bbaea [=============================] 196 B / 196 B
Downloading sha256:5e5d0caa74d [=============================] 214 B / 214 B
Downloading sha256:a3ed95caeb0 [=============================] 32 B / 32 B
Downloading sha256:9c57749dc47 [=============================] 387 B / 387 B
Downloading sha256:e64bdf31016 [=============================] 269 B / 269 B
Downloading sha256:7f9ca1ad0dc [=============================] 215 B / 215 B
Downloading sha256:a3ed95caeb0 [=============================] 32 B / 32 B
Downloading sha256:f253a83be7e [=============================] 256 B / 256 B
Downloading sha256:2c42d60692f [=============================] 222 B / 222 B
Downloading sha256:a3ed95caeb0 [=============================] 32 B / 32 B
Downloading sha256:d6feb452e43 [=============================] 5.56 MB / 5.56 MB
Downloading sha256:734df15bff9 [=============================] 196 B / 196 B
Downloading sha256:d217d9f538e [=============================] 285 B / 285 B
Downloading sha256:9e4b184d523 [= ] 4.2 MB / 72.1 MB
Issue by @aughr
Bare metal, SuperMicro.
I'd like to be able to easily push a new custom toolbox image and then let my teammates update to the latest on any given machine they're working on, without having to update /etc/default/toolbox on each machine. I can provide documentation that says "wipe out /var/lib/toolbox", but I'd prefer to be able to say something like "set the TOOLBOX_REINSTALL env var".
If this is something you'd be interested in supporting, I'm happy to send a PR your way.
Unable to run xdg-open from inside a clean toolbox
Fedora 30 Silverblue
It should open the url on the host's default browser
$ xdg-open "https://www.duckduckgo.com"
Failed to call portal: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Portal operation not allowed: Unable to open /proc/10377/root
toolbox create c- test && toolbox enter -c testxdg-open url for some urlThis also fails when trying to run a .pdf file.
This is also reported at: fedora-silverblue/issue-tracker#15
After the useradd command 'bob' will not have access to run sudoers with the default ruleset. A rule for bob needs to be created in /etc/sudoers.d/
echo "bob ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/bob
We'd like to converge efforts to https://github.com/containers/toolbox
Please comment on e.g. containers/toolbox#302 if you're a maintainer of this project and would like to continue to contribute.
Further, also a good opportunity to ensure you're following the repo, etc.
I'm not sure what this is... since this project was created the toolbox has been deployed in the CoreOS image, however, the README suggests that the user should expect a particular user prompt PS1. In fact the default PS1, for me, is: -bash-4.3#.
One thing I noticed is hat the welcome message is pretty old.
Another is that the README is missing some critical explanation as to which container mounted which host volume. The fact that the example created a user bob seemed to overly confuse. While I could reverse engineer the code and create doc it's my frosted/lazy-side that hopes you'd document it for me since this is a cool piece of code.
cat ~/.toolboxrc
TOOLBOX_DOCKER_IMAGE=busybox
TOOLBOX_DOCKER_TAG=ubuntu-14.04
toolbox --bind=/home/core
Directory /var/lib/toolbox/core-busybox-ubuntu-14.04 lacks the binary to execute or doesn't look like a binary tree. Refusing.
The current toolbox provides neither an access to the docker socket nor the docker binary preventing to use the toolbox as a universal management tool. It would be nice if toolbox exposed those into the container either by default or with an option.
Currently as a workaround I have a custom copy of the toolbox script with --bind=/run/docker.sock --bind-ro=/usr/bin/docker added to the systemd-nspawn arguments, but that works by an accident. docker executable is not fully statically linked and there is no guarantee that the fedora image provides the shared libraries the executable depends on.
I suppose a better option would be to turn in the toolbox container /usr/bin/docker into a script that runs the executable from /media/root/usr with the LD_LIBRARY_PATH set to /media/root/usr/lib64/
lease do not use --share-system anymore, use $SYSTEMD_NSPAWN_SHARE_* instead. Spawning container rxxxxxk-gcr.io_google-containers_toolbox-20XXXXX3-00 on /var/lib/toolbox/rxxxxxxk-gcr.io_ google-containers_toolbox-20190523-00. Press ^] three times within 1s to kill container. Failed to allocate scope: Unit rigonblick-gcr.io_google-containers_toolbox-20190523-00.scope already exists. Unable to get into toolbox can assitance want to get into it.
Failed to allocate scope: Unit rXXXXXk-gcr.io_google-containers_toolbox-20190523-00.scope already exists.
Parent died too early
We should use registry.redhat.io/rhel9/support-tools by default now that we're on RHEL 9.
The 9.1 based support tools image however comes with sos 4.3 which does not have sosreport/sos@95912b2f from sosreport/sos#2914 which leads to issues when launched directly with:
$ oc debug node/... --image=registry.redhat.io/rhel9/support-tools
$ sos report
...
Could not initialize 'report': local variable '_host_sysroot' referenced before assignment
...
This is repdocucible outside of a cluster with:
$ podman run --rm -ti registry.redhat.io/rhel9/support-tools
[root@a0eaf1e45896 /]# sos report
Could not initialize 'report': local variable '_host_sysroot' referenced before assignment
[root@a0eaf1e45896 /]# rpm -qi sos
Name : sos
Version : 4.3
Release : 5.el9_1
...
This is in the context of containers/toolbox#114
I saw that coreos/toolbox always calls podman stop once the podman exec session terminates. I suppose the idea is that the stop will continue to fail until there are other exec sessions around, and the final stop will actually terminate the container.
But, does it actually work this way in practice?
I was playing with this a bit recently. It seems that regardless of whether there are exec sessions around or not, stop always sends a signal to the container's entry point.
For example, if you have:
$ podman run --rm -it registry.fedoraproject.org/fedora:34 /bin/bash
... then a podman stop ... will quit the shell.
Sometimes, when there are actual exec sessions around, I do get this error from podman stop:
"container %s has active exec sessions, refusing to clean up"
... but it doesn't seem consistent. Sometimes the exec sessions also end up getting terminated.
Any thoughts? :)
Is this the expected behaviour? Did Podman change behaviour in some way? Or am I missing something obvious?
For consistency sake, please use - not _
Line 17 in bc6a8c4
Toolbox hang for a long time and can't input any command, including ctrl+c & ctrl+z, and terminal window is dead.
RHEL-8.3
Red Hat Enterprise Linux release 8.3 Beta (Ootpa)
What hardware/cloud provider/hypervisor is being used to run toolbox?
fix it
[root@ibm-x3650m4-01-vm-14 toolbox]# ./rhcos-toolbox
Error: error getting authfile /var/lib/kubelet/config.json: stat /var/lib/kubelet/config.json: no such file or directory
Would you like to manually authenticate to registry: 'registry.redhat.io' and try again? [y/N] y
Authenticating with existing credentials...
Existing credentials are valid. Already logged in to registry.redhat.io
Trying to pull registry.redhat.io/rhel8/support-tools...
Getting image source signatures
Copying blob ec1681b6a383 done
Copying blob 6b1688d3542f done
Copying blob c4d668e229cd done
Copying config 50b63c2aff done
Writing manifest to image destination
Storing signatures
50b63c2aff8c13f9f8594c9eaf5fc961f39c74df6d9c6ddde8ca705f78f3c14d
NOTE: hang forever in here, and can't input anything, the terminal window is dead.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.