The current CROS_WORKON_COMMIT of etcd-2.2.4 does not build from
arm64. Add a temporary conditional to set CROS_WORKON_COMMIT to
a known good revision for arm64.
Signed-off-by: Geoff Levand <geoff@infradead.org>
exec docker "$@" ${USE_SELINUX} will override DOCKER_OPTS if it contains
--selinux-enabled=false, and puts double --selinux-enabled in args which
is confusing too.
docker daemon --host=fd:// --selinux-enabled=false --selinux-enabled
metadata
* Add IUSE and description rkt_stage1_fly
ebuild
* Bump version to 0.15.0
* Add IUSE rkt_stage1_fly and enable by default
* Rewrite rkt ebuild to support multiple stage1 flavors
Two errors here: shred_keys was not updated when the keys were moved
from the top level directory to the certs directory and shred_keys was
getting called after `rm -r certs`, leaving nothing to shred.
Now the ebuild will fail if shred fails.
Since moving call to dracut into the coreos-kernel package in
pkg_setup step the pkg_setup function provided by linux-info hasn't been
called, breaking tc-arch-kernel which depends on the detected kernel
version to know if it should return "x86" or "x86_64".
Instead of calling `linux-info_pkg_setup` we now call `get_version`
directly which only looks up the version in the source, the old behavior
allowed for falling back to `get_running_version` which is not useful.
This check was broken in when the source symlinks were moved from `${S}`
to `${S}/source`. Also, since it is a environment sanity check running
the check as early as possible in `pkg_pretend` is appropriate.
When bootstrapping glibc installs headers but is not built. However a
native tool, cross-rpcgen, must be built in order to generate rpcsvc
header files. By skipping directly to `make headers-install` the tool
winds up getting built during src_install, building as root instead of
the portage user and so on. Although uncommon this may lead to
permission issues with ccache.
The SDK chroot has no control over /dev/pts since it is bind-mounted
from the host system. As far as I can tell there isn't any significant
issue caused by the `tty` group having a different gid on the host
system from the SDK anyway.
If a user opens a file r/w on overlayfs, and if the underlying inode is
currently still on the lower fs, right now we're verifying whether selinux
policy permits writes to the selinux context on the underlying inode. This
is suboptimal, since we don't want confined processes to be able to write to
these files if they're able to escape from a container and so don't want to
permit this in policy. Have overlayfs pass down an additional flag when
verifying the permission on lower inodes, and mask off the write bits in
the selinux permissions check if that flag is set.
