Toolbox containers using runc as their runtime don't work on host
operating systems using cgroups v2. They need to be migrated to crun.
'podman start' throws a specific error for such containers:
ERRO[0000]: oci runtime "runc" does not support CGroups V2: use
system migrate to mitigate
Error: unable to start container "fedora-toolbox-30": this version
of runc doesn't work on cgroups v2: OCI runtime error
This error is identified by the phrase "use system migrate to mitigate"
to avoid encoding any assumptions about updating from cgroups v1 to v2
or downgrading in the other direction.
If the migration fails, 'toolbox reset' is suggested as the last hope.
https://github.com/containers/toolbox/pull/309
A subsequent commit will leverage this to detect 'podman start'
failures caused by attempting to run runc-based toolbox containers on
cgroups v2 sytems, and try to migrate them if possible.
https://github.com/containers/toolbox/pull/309
Asking for the Podman version is one of the most common support
questions. So it can't hurt to have it in the debug output, especially
when the version is already being read to decide if migration is
necessary or not.
https://github.com/containers/toolbox/pull/309
It was possible to have 'podman exec' invoked against a toolbox
container before the entry point had finished initializing it. This
could lead to situations where '$USER' didn't yet exist inside the
container when 'podman exec' attempted running a binary as that user,
which would end up failing 'toolbox enter'.
There are a number of corner cases that need to be kept in mind while
implementing any kind of synchronization.
First, older containers don't use 'toolbox init-container' as their
entry point. This might mean that their start-up can't be synchronized
but they should still be kept working in their current state.
Second, once a container has been started, subsequent 'podman start'
invocations are NOPs. They won't lead to newer instances of the entry
point process being launched.
Third, the entry point process can crash or get killed due to an
out-of-band 'podman stop'. In such cases, 'toolbox enter' should not
get confused or deadlocked. It should give a meaningful error message
to the user.
Fourth, it would be nice to not have to touch the 'create' command so
that toolbox containers created with Toolbox 0.0.10 onwards can have
their start-up synchronized. This means that the host can't add any
new environment variable or bind mount to the container to agree upon
a path that's keyed by the container's identity and shared with the
host.
Given all these considerations, a timed busy loop that looks for the
presence of a stamp file, keyed by the entry point's PID, is the most
robust solution that can be verified as correct. Anything involving
file locks becomes increasingly complicated and hard to verify.
Under normal circumstances, the loop isn't expected to last more than
a few iterations. In case the entry point dies, the loop will time out
after approximately 25 seconds, the same interval as the default for
D-Bus method calls.
Some changes by Debarshi Ray based on an idea from Jan Hlaváč.
https://github.com/containers/toolbox/pull/305
POSIX only supports single digit file descriptors. Therefore, there's
value in being frugal about how we allocate them throughout the code.
The 'reset' command is very standalone and isolated from the other
code paths, because it's meant to be a last-ditch attempt to unbreak a
broken Podman installation. This can be exploited to re-use one of the
file descriptors that's used elsewhere in the code. In this case, file
descriptor number 4 is also used to control the spinner.
https://github.com/containers/toolbox/pull/305
The 'reset' command is meant to factory reset the local Podman and
Toolbox installations. Every now and then early adopters and testers of
Toolbox have to do this when their local Podman state has gotten
irrecoverably broken due to some Podman bug.
It's useful to have a command that encapsulates all the steps to do a
factory reset, as opposed to having to spell them out separately. It's
easier to document, helps with user support, and can enable less opaque
error messages that suggest a way forward when nothing is working.
Since this command is meant to be used when the Podman installation is
completely broken, it must avoid using any Podman commands at all
costs. This is why it cannot use 'podman stop' to stop any running
containers, nor can it use 'podman unshare' to delete
~/.local/share/containers when running rootless. Instead, it relies on
the user rebooting the machine for the former, and uses newgidmap(1),
newuidmap(1) and unshare(1) to reimplement 'podman unshare' for the
latter.
Note that when running as root, some care has been taken to avoid
removing directories that might be owned by the operating system. eg.,
on Fedora /var/lib/containers/sigstore is owned by the
containers-common RPM.
https://github.com/containers/toolbox/pull/295
Toolbox is being increasingly used outside the Fedora universe. Endless
OS already uses it, and there's some interest in using it on Arch
Linux, Red Hat Enterprise Linux and Ubuntu. Therefore, it's a good
idea to clearly document what's necessary for a smooth Toolbox user
experience on a given operating system distribution.
Note that this might not match the current reality of the code, which
is predominantly developed, tested and used on Fedora. This is a step
towards formally specifying what an OS distributor is expected to
provide. The code can then be iteratively improved to match the
specification.
https://github.com/containers/toolbox/pull/300
There's no reason to fail the toolbox container's entry point, if the
container doesn't have its own copies of configuration files that are
ultimately going to be replaced with symbolic links to their host
counterparts.
https://github.com/containers/toolbox/pull/294
Toolbox is being used with Endless OS, which is an OSTree based
operating system built out of Debian packages, not RPMs; and in the
Fedora universe, CoreOS is being increasingly treated as a primary
use-case for Toolbox alongside Silverblue.
https://github.com/containers/toolbox/pull/299
The older com.github.debarshiray.toolbox label is still used in most
places as an alias for the new name for the sake of simplicity and
compatibility; except in 'create', where the new label is explicitly
specified in addition to the older one to help popularize it via newly
created toolbox containers.
The older com.github.debarshiray.toolbox label should eventually be
dropped, but before that, the even older use of com.redhat.component
for tagging needs to be phased out. The com.github.debarshiray.toolbox
label was introduced in commit 0ab6eb7401, as part of Toolbox
0.0.8, right before the release of Fedora 30 [1]. Therefore,
com.redhat.component needs to stay at least until Fedora 29 is
supported.
[1] https://fedoraproject.org/wiki/Releases/30/Schedulehttps://github.com/containers/toolbox/pull/293
Using the shorter variant of an option was breaking the state machine.
It would stop suggesting accompanying arguments, commands and other
options.
https://github.com/containers/toolbox/pull/292
This fixes an old remnant of the past. Even though the '--verbose'
option may not do anything for the command, it is compatible with all
of them.
https://github.com/containers/toolbox/pull/292
A year ago, when rootless Podman was in its infancy, it was often
necessary to run rootful to test and shake out bugs in Podman. Things
are lot more mature now and this hasn't been necessary in the past few
months. Therefore, it's time to sunset this option.
Removing the --sudo option doesn't break backwards compatibility
because it was neither documented nor advertised to the user in any
way. It was a hidden option only meant to be used by those hacking on
Toolbox itself.
Note that this is different from running 'sudo toolbox ...', which is a
different use-case and uses separate code paths. This is about running
the rest of toolbox(1) as non-root and only invoking the container
tools like Podman as root.
This reverts commit 66ab4da724.
https://github.com/debarshiray/toolbox/pull/285
It seems cleaner to limit the use of colour to only marking running
containers. It's redundant to mention that the containers and images
were created by Toolbox because they are being shown by 'toolbox list'
anyway; and there's a second uncoloured heading in a different case,
that differentiates containers from images.
https://github.com/debarshiray/toolbox/pull/284
This should make it more obvious which part of the two-step process of
copying /etc/profile.d/toolbox.sh into a container the strings are
coming from.
https://github.com/debarshiray/toolbox/pull/279
It's common for people to run the toolbox script straight out of the
source tree without installing it system-wide. In such cases, it's
likely that /etc/profile.d/toolbox.sh would be absent on the host, and
as a result also absent from the toolbox container.
The welcome messages and the primary shell prompt (or PS1) are set
through /etc/profile.d/toolbox.sh, so not having it does degrade the
user experience, but it's probably not severe enough to fail the 'run'
command.
This should have been part of commit 0db54946b4 which split the
copying of /etc/profile.d/toolbox.sh into a container into two steps to
avoid using 'podman cp'. It already tried to handle the missing file
in the first step, but not in the second step.
It's also nice to at least make the user aware of the situation by
printing an error message.
https://github.com/debarshiray/toolbox/pull/278
Podman defaults to bind-mounting locations as read-write when neither
'rw' nor 'ro' is explicitly specified.
On Silverblue /usr is mounted read-only on the host. Therefore, it's
not possible to bind-mount it as read-write inside the toolbox
container.
It turns out that Podman doesn't downgrade the default mount flag to
read-only when the source location is such, and this breaks creating
new toolbox containers on Silverblue. See:
https://github.com/containers/libpod/issues/4061
Fallout from d63b0a9c0fhttps://github.com/debarshiray/toolbox/pull/276
Toolbox might be used as root or rootless. Including the real user ID
in the debug output can help understand bugs or oddities caused by
differences in root versus rootless scenarios.
https://github.com/debarshiray/toolbox/issues/267
In practice, the OSC 777 escape sequence is only supported in Fedora's
fork of VTE. It's completely useless on other distributions.
Moreover, the user experience of tracking and preserving the user's
current toolbox container in GNOME Terminal was designed specifically
for Fedora Silverblue and Workstation, and it still has some rough
edges. eg., not being able to request a shell running on the host from
inside the toolbox, which can make the user feel trapped. While those
kinks get worked out, it's better to not expose users of other Fedora
variants, like CoreOS, to this.
https://github.com/debarshiray/toolbox/pull/272
The '--dns=none --no-hosts' options were added to 'podman create' in
Podman 1.2.0, which is within the current minimum required Podman
version of 1.4.0.
https://github.com/debarshiray/toolbox/pull/270
This is meant to alleviate some of the pain of not being able to modify
the list of bind mounts once a toolbox container has been created. For
some cases, especially where read-only access is enough, one can get
by with setting up symbolic links inside the toolbox container.
Based on an idea from Colin Walters.
https://github.com/debarshiray/toolbox/pull/264
Since Podman supports '--ulimit host' only from version 1.5.0, which
is newer than the minimum required version of 1.4.0, this only works
if a new enough Podman is available.
https://github.com/debarshiray/toolbox/issues/213
When listing only images, 'exit' was picking up the non-zero exit code
from the following (failing) statement meant for containers. An
explicit 'if' branch prevents the exit code of the condition from
leaking out.
Fallout from 5e4e63a11bhttps://github.com/debarshiray/toolbox/pull/258
This is helpful when running a development build of GNOME Shell from
within a toolbox container. It enables populating the application grid
with Flatpak applications installed system-wide on the host.
https://github.com/debarshiray/toolbox/pull/256
See: https://github.com/containers/libpod/issues/3946
COLUMNS and LINES may not be set in the user's environment. Hence the
existing mechanism for preserving environment variables don't work.
Note that for things to keep working when invoked via D-Bus from
inside a toolbox container, the terminal size needs to be queried using
the standard input stream, instead of explicitly mentioning the
controlling terminal device /dev/tty. This is because stty(1) doesn't
have the notion of a controlling terminal when invoked via D-Bus, but
flatpak-spawn(1) ensures that the standard input stream still points
to the user's interactive terminal.
https://github.com/debarshiray/toolbox/issues/242
