Currently, toolbox(1) offers a --verbose option that only shows debug
information from toolbox(1) itself and the error stream of internal
commands. There's no way to further increase the log level of the
internal commands. It's sometimes very useful to be able to get more
detailed logs from Podman.
This adds a new --very-verbose or -vv option that makes this possible.
This should have been implemented as '--verbose --verbose', which
could be conveniently shortened to '-vv'. This is what flatpak(1)
does. However, due to the lack of built-in command line parsing
facilities in POSIX shell, there's no support for multiple short
options expressed as one single argument. eg., '-vy' doesn't expand to
'-v -y'.
Therefore, a separate --very-verbose or -vv option was added to make
things convenient for the user. It's expected that most people will
refer to this as -vv.
If this option is used, every Podman command in the code is run with
'--log-level debug'. Use wisely, Podman can be 'very verbose'.
https://github.com/containers/toolbox/pull/289
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
A new help command has been added which either shows the toolbox(1)
manual or a manual page for a specific command. The '--help' flag is
now identical to the help command and can be placed after the COMMAND
segment in the list of command line arguments.
Due to a bizarre quirk in less(1) [1], the default pager used to render
manuals on most systems, the man(1) invocations need the standard error
stream to point to the controlling terminal, if any, to work. This
interferes with the global redirection of standard error to /dev/null
in the absence of the '--verbose' flag, and is worked around by
redirecting to standard output instead.
[1] It turns out that less(1) tries to open the controlling terminal
device /dev/tty to get to the keyboard for accepting input.
However, it doesn't have a controlling terminal when invoked via
D-Bus to render a manual on the host. It then strangely falls back
to using the standard error stream to get to the keyboard.
https://github.com/debarshiray/toolbox/pull/200
This works by configuring the toolbox container after it has been
created, instead of before. The toolbox script itself is mentioned as
the entry point of the container, which does 'exec sleep +Inf' once the
initialization is done.
A new command 'init-container' was added to perform the initialization.
It is primarily meant to be used as the entry point for all toolbox
containers, and must be run inside the container that's to be
initialized. It is not expected to be directly invoked by humans, and
cannot be used on the host.
As a result, the default name for the toolbox containers is now
fedora-toolbox-<version-id>, not fedora-toolbox-<user>-<version-id>.
For backwards compatibility, 'toolbox enter' and 'toolbox run' will
continue to work with containers using the old naming scheme.
https://github.com/debarshiray/toolbox/pull/160
Currently, there's no easy way to get the size of the impending
download. Skopeo doesn't offer the size of the OCI image [1] and it's
debatable whether another 23 MB binary ought to be pulled in as a
dependency just for this.
Given that the default fedora-toolbox images are the only base images
available via a public repository, the size of the download is hard
coded to reflect the approximate size of the fedora-toolbox images.
These images are between 451 MB and 483 MB, so 500 MB should be a
reasonably suggestive approximate that shouldn't negatively surprise
users.
[1] https://github.com/containers/skopeo/issues/641https://github.com/debarshiray/toolbox/issues/134
