When taking ownership of the runtime directory or the initialization
stamp file inside it, it was assumed that the user's GID and UID were
the same. However that might not always be the case.
Note that this commit doesn't use the GID passed from the host to the
toolbox container's entry point to configure the user inside the
container. That is actually more difficult than it sounds. The manual
for useradd(8) says that the group specified by the '--gid' flag must
actually exist.
https://github.com/containers/toolbox/issues/664
Since Fedora 33, `nano` is the default editor[0]. It needs to be
included in the fedora-toolbox image to have the standard Fedora
experience inside the container.
[0] https://fedoraproject.org/wiki/Changes/UseNanoByDefault
CoreOS recently made /boot read-only[0]. This caused an issue with
starting containers because /boot was mounted only with option rslave
but missed the ro option. This caused a permission issue.
This scenario is very similar to the one with /usr on Fedora Silverblue.
The solution for this is to check mount options of the path and check if
it uses the rw option or ro and then add it to the mount options in the
--volume option in 'podman create'.
Fixes: https://github.com/coreos/fedora-coreos-tracker/issues/734
[0] 1de21ffa98https://github.com/containers/toolbox/pull/712
On Fedora Silverblue 33 the output of 'findmnt --noheadings --output
OPTIONS /usr' is:
ro,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/root
(Fedora uses btrfs as it's default filesystem since version 33[0]). But
when you make the current deployment mutable using 'ostree admin unlock'
the output of the command changes to something like this:
ro,relatime,seclabel,ssd,space_cache,subvolid=257,subvol=/root
rw,relatime,seclabel,lowerdir=usr,upperdir=/var/tmp/ostree-unlock-ovl.JLXHQ0/upper,workdir=/var/tmp/ostree-unlock-ovl.JLXHQ0/work
This causes utils.GetMountOptions to error out preventing a successful
creation of a container with 'toolbox create' when the deployment is
unlocked.
For Toolbox the first line is the more relevant because even though /usr
is technically writeable, it will cease to be after reboot. This is the
current behaviour of the utils.GetMountOptions. Thanks to that I think
it's safe to remove the length check that prevents to create a container
when the current deployment is unlocked.
[0] https://fedoraproject.org/wiki/Changes/BtrfsByDefaulthttps://github.com/containers/toolbox/pull/554
Since commit b27795a03e, each section of the test suite starts
and ends with a clean Podman state. This includes removing all images
from the local containers storage. Therefore, the images get downloaded
multiple times during the course of the test suite.
This commit restores the earlier behaviour where the images would get
downloaded only once, by copying them to separate directories outside
the local containers storage and then restoring them when the tests
are run.
https://github.com/containers/toolbox/pull/517https://github.com/containers/toolbox/pull/704
The POSIX shell Toolbox has been replaced by the Go implementation
quite a long time ago. People on several ocassions created PRs that
still update it, or end up using it by mistake when building from
source.
It was not clear that the POSIX shell implementation has been
deprecated and is no longer maintained.
https://github.com/containers/toolbox/pull/698
A lot of issues are about toolbox containers not starting up. In such
cases the output of `podman start --attach` is required to see what is
going on. It would be easier if users provided this information right
when they are filling the issue.
https://github.com/containers/toolbox/pull/699
Without this I get an error:
```
$ meson -Dprofile_dir=/etc/profile.d builddir
The Meson build system
Version: 0.55.3
Source dir: /home/user/toolbox
Build dir: /home/user/toolbox/builddir
Build type: native build
Project name: toolbox
Project version: 0.0.97
meson.build:1:0: ERROR: Unknown compiler(s): ['cc', 'gcc', 'clang', 'pgcc', 'icc']
The follow exceptions were encountered:
Running "cc --version" gave "[Errno 2] No such file or directory: 'cc'"
Running "gcc --version" gave "[Errno 2] No such file or directory: 'gcc'"
Running "clang --version" gave "[Errno 2] No such file or directory: 'clang'"
Running "pgcc --version" gave "[Errno 2] No such file or directory: 'pgcc'"
Running "icc --version" gave "[Errno 2] No such file or directory: 'icc'"
A full log can be found at /home/user/toolbox/builddir/meson-logs/meson-log.txt
```
The bats-support[0] and bats-assert[1] libraries extend the
capabilities of bats[2]. Mainly, bats-assert is very useful for clean
checking of values/outputs/return codes.
Apart from updating the cases to use the libraries, the test cases have
been restructured in a way that they don't depend on each other anymore.
This required major changes in the helpers.bats file.
Overall, the tests are cleaner to read and easier to extend due to the
test cases being independent.
Some slight changes were made to the test cases themselves. Should not
alter their final behaviour.
There will be a follow up commit that will take care of downloading of
the tested images locally and caching them using Skopeo to speedup the
tests and try to resolve network problems when pulling the images that
we experienced in the past.
[0] https://github.com/bats-core/bats-support
[1] https://github.com/bats-core/bats-assert
[2] https://github.com/bats-core/bats-core
The Go implementation prefers a newer syntax for assigning a custom
name to a toolbox container. The --container option is still supported
for backwards compatibility, but the manuals should show the new
workflow.
https://github.com/containers/toolbox/pull/681
The Go implementation prefers a newer syntax for assigning a custom
name to a toolbox container. The --container option is still supported
for backwards compatibility, but the manuals should show the new
workflow.
https://github.com/containers/toolbox/pull/678
Ever since version 0.0.10, all newly created toolbox containers use a
reflexive entry point [1] and don't need a user-specific customized
image. Older containers that don't use a reflexive entry point were
deprecated in version 0.0.17 [2], and aren't even supported in the Go
implementation.
Therefore, it's time to finally update the manuals to document the
current way of doing things. Since the reflexive entry point is a key
feature of toolbox containers, some text was added to explain why it's
necessary and what it does.
[1] Commit 8b84b5e460https://github.com/containers/toolbox/pull/160
[2] Commit 9dc5281430https://github.com/containers/toolbox/pull/336https://github.com/containers/toolbox/pull/677
While Toolbox's test suite explicitly uses --shell=sh when running
shellcheck(1) on profile.d/toolbox.sh, external tools like Coverity
can't be expected to do the same. So they complain:
Line 1:
[ "$BASH_VERSION" != "" ] || [ "$ZSH_VERSION" != "" ] || return 0
^-- SC2148: Tips depend on target shell and yours is unknown. Add a
shebang or a 'shell' directive.
See: https://github.com/koalaman/shellcheck/wiki/SC2148https://github.com/containers/toolbox/pull/673
On Arch Linux and Ubuntu hosts, /etc/localtime is an absolute symbolic
link to /usr/share/zoneinfo/SomeTimeZone. So, inside the container,
/run/host/etc/localtime also has /usr/share/zoneinfo/SomeTimeZone as
its target.
https://github.com/containers/toolbox/issues/622
The Go implementation had deprecated the reset command, right from the
beginning, in favour of 'podman system reset'. It's time to finally
remove it.
https://github.com/containers/toolbox/pull/668
