Add Arch Linux toolbox image #520
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Build failed.
|
|
Regarding |
|
Thank you for making this. I hope it can get fixed up and merged soon! A few pointers:
|
Thanks, I'll update it.
I was thinking that might be the case. Is
Great idea, but I'm totally new to Docker and containers in general, so if you know how to implement this or have any other ideas, I'd welcome patches or a pull request :) |
Users, who prefer shells other than Bash, tend to get confused when Toolbox presents a Bash prompt to them. It would be better to be more upfront about what the problem is, so that users can self-support themselves. #18
Podman doesn't mount a tmpfs at /tmp by default - it needs to be separately requested. However, doing it as part of 'podman create ...' won't add a tmpfs at /tmp for existing toolbox containers. Therefore, it's best done as part of the entry point. The mount options are the same as used by systemd (see tmp.mount) to provide a tmpfs at the host's /tmp. For what it's worth, the mount flags do differ slightly from the host. The host has: $ findmnt --output OPTIONS,PROPAGATION /tmp OPTIONS PROPAGATION rw,nosuid,nodev,seclabel shared The container has: $ findmnt --output OPTIONS,PROPAGATION /tmp OPTIONS PROPAGATION rw,nosuid,nodev,seclabel,uid=100000,gid=100000 private The uid and gid options don't show up on the host because both are 0, and hence skipped by the tools. #513
Bug reporters most of the time don't know what and how much info they should share with us. I heavily based the bug report template on Podman's[0]. [0] https://github.com/containers/podman/blob/master/.github/ISSUE_TEMPLATE.md #459
Having some contributing guidelines is good! I wrote of this mostly from top of my head (but I took inspiration from projects like Podman or Atom). Maybe some parts are not very clear.
Installing the tests will let downstream distributors like Fedora run them as part of their build and CI systems. #511
The 'removeContainer' function should go into 'pkg/podman' because it wraps around Podman's command. Because it no longer has access to the commands - 'toolbox rm' - parameters it has a new forceDelete parameter. #519
The 'removeImage' function should go into 'pkg/podman' because it wraps around Podman's command. Because it no longer has access to the commands - toolbox rmi - parameters it has a new forceDelete parameter. #519
The /usr/bin/toolbox binary is not only used to interact with toolbox
containers and images from the host. It's also used as the entry point
of the containers by bind mounting the binary from the host into the
container. This means that the /usr/bin/toolbox binary on the host must
also work inside the container, even if they have different operating
systems.
In the past, this worked perfectly well with the POSIX shell
implementation because it got intepreted by whichever /bin/sh was
available.
The Go implementation also mostly worked so far because it's largely
statically linked, with the notable exception of the standard C
library. However, recently glibc-2.32, which is used by Fedora 33
onwards, added a new version of the pthread_sigmask symbol [1] as part
of the libpthread removal project:
$ objdump -T /usr/bin/toolbox | grep GLIBC_2.32
0000000000000000 DO *UND* 0000000000000000 GLIBC_2.32
pthread_sigmask
This means that /usr/bin/toolbox binaries built against glibc-2.32 on
newer Fedoras pick up the latest version of the symbol and fail to run
against older glibcs in older Fedoras.
One way to fix this is to disable the use of any C code from Go by
using the CGO_ENABLED environment variable [2]. However, this can
negatively impact packages like "os/user" [3] and "net" [4], where the
more featureful glibc APIs will be replaced by more limited
equivalents written only in Go.
Instead, since glibc uses symbol versioning, it's better to tell the
Go toolchain to avoid linking against any symbols from glibc-2.32.
This was accomplished by a few linker tricks:
* The GNU ld linker's --wrap flag was used when building the Go code
to divert pthread_sigmask invocations from Go to another function
called __wrap_pthread_sigmask.
* A static library was added to provide this __wrap_pthread_sigmask
function, which forwards calls to the actual pthread_sigmask API in
glibc. This library itself was not linked with --wrap, and
specifies the latest permissible version of the pthread_sigmask
symbol from glibc for each architecture. Currently, the list of
architectures covers the ones that Fedora builds for.
* The Go cmd/link linker was switched to external mode [5]. This
ensures that the final object file containing all the Go code gets
linked to the standard C library and the wrapper static library by
the GNU ld linker for the --wrap flag to kick in.
Based on ideas from Ondřej Míchal.
[1] glibc commit c6663fee4340291c
https://sourceware.org/git/?p=glibc.git;a=commit;h=c6663fee4340291c
[2] https://golang.org/cmd/cgo/
[3] https://golang.org/pkg/os/user/
[4] https://golang.org/pkg/net/
[5] https://golang.org/src/cmd/cgo/doc.go
#529
It turns out that this doesn't work out-of-the-box on openSUSE and needs to be explicitly configured. #452
This is based on the output of 'gcc -dM -E - </dev/null' on a ppc64le system. For what it's worth, the _CALL_ELF macro is defined as 1 on the big endian variants of the architecture. The original intention in commit 6ad9c63 was to support the architectures that Fedora builds for, and it doesn't care about PowerPC variants that aren't ppc64le [1]. [1] https://fedoraproject.org/wiki/Architectures/PowerPC #536
Otherwise https://www.shellcheck.net/ would complain: Line 729: if $podman_command image exists localhost/$base_toolbox_image >/dev/null 2>&3; then ^-----------------^ SC2086: Double quote to prevent globbing and word splitting. See: https://github.com/koalaman/shellcheck/wiki/SC2086 #537
|
Build failed.
|
Oh, yeah. You should be able to skip the |
This commit combines updating pacman repositories and installing packages and removes the linux, linux-firmware and sudo packages, as they are not needed.
|
@Limero Done. Can you please take care of installing yay? |
|
Build failed.
|
Let's add that later once this base is merged. |
|
Oh, my bad. I though you meant we'll add it after I merge the pacman changes. Do you maybe know why the build fails/how to fix it? |
Sorry, I don't know. The toolbox maintainers might be able to help solve it. |
Currently toolbox containers can get misconfigured if some configuration files on the host are absolute symbolic links to some other location. For example, when systemd-resolved is used to manage /etc/resolv.conf on the host, and if the file is an absolute link to /run/systemd/resolve/stub-resolv.conf, then /etc/resolv.conf ends up being invalid inside the container. This happens because the container's /etc/resolv.conf points to /run/host/etc/resolv.conf, which in turn points to /run/systemd/resolve/stub-resolv.conf, but that's absent from the container. This is, of course, not a problem with relative symbolic links. If the host had a relative link to ../run/systemd/resolve/stub-resolv.conf, then it would continue to work inside the container. One solution would have been to use flatpak-session-helper to maintain a copy of the host's /etc/resolv.conf in $XDG_RUNTIME_DIR/.flatpak-helper/monitor. However, that doesn't work when toolbox(1) is run as root. The other option is to prepend the destination of the absolute symbolic link with /run/host to make it resolve inside the container. It might not work with funky links, but it's enough for the common case where a an administrator changed the host's /etc/resolv.conf into a sane, but absolute, symbolic link. Properly configured hosts should anyway use relative symbolic links, because they don't need to be adjusted in such scenarios. That's also what Fedora and Ubuntu do, by default. Thanks to Tudor Roman for raising a concern about relative symbolic links. Based on Martin Pitt's work on the POSIX shell implementation: #380 #187
It tries to loosely mimic ncurses to look up a terminfo entry for the current terminal, as mentioned in the terminfo(5) manual. Unlike ncurses, it doesn't handle TERMINFO_DIRS, though, to avoid parsing an array of directories for the sake of simplicity. Every line of code in this file is part of the interactive shell's start-up sequence, which makes it a trade-off between correctness and speed. Therefore, the purpose of this warning is not to exhaustively catch all possible corner cases, but to serve as a convenience in the majority of cases. Ultimately, if someone is using an exotic terminal set-up, then a missing warning is a minor price to pay in order to not slow things down for the vast majority of users who don't. Based on code written by Mert Alp Taytak: #515 #505
... and other hybrid set-ups where the host and container OSes aren't the same. The entry point of a toolbox container already runs as root:root. Therefore, there's no need to run it with an additional group. Interactive shells spawned by 'sudo su -' both inside the container and on the host don't run with such an additional group either. They run just as root:root. This prevented toolbox containers from starting up on Fedora CoreOS hosts, because CoreOS has both the 'sudo' and 'wheel' groups but the fedora-toolbox images only have the 'wheel' group. Therefore, it ended up calling 'podman create --group-add sudo ...', and since the 'sudo' group was missing from the image, the container failed to start. The --group-add flag was added in commit 4bda42d when the entry point ran as $USER as specified in the user-specific customized image. The additional group was specified to retain consistency with interactive shells run as $USER. Since then, things have changed. There's no longer any user-specific customized image and commit f74400f made the entry point run as root:root. The --group-add flag should have been removed as part of those changes. #423
This will make the subsequent commit easier to read. #523
Since Podman 2.0.5, containers that were created with
'podman create --userns=keep-id ...' automatically get the user added
to /etc/passwd [1]. However, this user isn't as fully configured as it
needs to be. The home directory is specified as '/' and the shell is
/bin/sh.
Note that Podman doesn't add the user's login group to /etc/group [2].
This leads to the following error message when entering the container:
/usr/bin/id: cannot find name for group ID 1000
It's expected that this will be fixed in Podman itself.
Therefore, the entry point needs to call usermod(8) to update the user,
instead of using useradd(8) to create it.
[1] Podman commit 6c6670f12a3e6b91
containers/podman#6829
[2] containers/podman#7389
#523
Fedora 30 reached End of Life on 26th May: https://fedoraproject.org/wiki/End_of_life #546
|
Build failed.
|
|
@HarryMichal Sorry for tagging you randomly like this, but you're the person who responded when I submitted the last version of the pull request. I've successfully built the image (although it's 1.23 GB for some reason), but when trying to run it with |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is a continuation of #328.
Tested with
podman build --tag archlinux:latest ./Dockerfile, but with a few problems:podman run --name arch-test --rm localhost/archlinux(even though it is listed when runningpodman images)The following packages were installed when building the image:
I also don't know what to do about man-pages, are they required, should they be removed?