There is a dependency loop when systemd is build with cryptsetup
like systemd -> cryptsetup -> lvm2 -> baselayout -> systemd. Since
CoreOS always installs a good baselayout, it makes sense drop the
lvm2 dependency and turn it into a conflict with bad versions. It
also has a runtime dependency loop on systemd, so make that into a
build dependency.
This also stabilizes the version that was being used by arm64,
updating amd64, to bring the architectures into alignment.
Changes include:
* Add cros_workon bits
* Define and use the symlink-usr flag
* Drop SELinux policy and udev init scripts dependencies
* Drop all patches since the source is from Git
* Switch /etc/resolv.conf to the old one
* Drop the D-Bus policy path to keep the default
* Use CoreOS NTP servers
* Install PAM files into /usr
* Set the timesyncd epoch
* Don't use default DNS servers
* Use legacy cgroups (https://github.com/docker/docker/issues/28109)
* Rewrite basically the entire install step
* Drop the systemd-bus-proxy user since the program is long gone
The actual nscd binary has been installed since sssd was added,
but none of the systemd configuration files were included. This
resulted in a binary that would not start due to a missing /run
directory.
The upstream nscd.conf is installed in /usr and linked into /etc.
This changes the bug URL from GitHub to a subdomain under coreos.com.
This will allow us in the future to move to another bug tracker. As it
exists today, this new subdomain just redirects to GitHub so there
should be no change in behavior.
When flannel-docker-opts didn't require flanneld, flanneld could
fail and flannel-docker-opts would start immediately after. This
effectively broke the intended ordering, so now both services
require each other.
This also simplifies the ordering declarations of the two services
by making flannel-docker-opts have both After= and Requires= as is
most commonly configured.
Prior to this, "${P}" would match upstream gentoo's distfile cache of
containerd, and that tarball would be used regardless of our SRC_URI
changing as we bumped the commit hash.
That resulted in us having an incorrect version of containerd installed
(and lying about the commit hash in --version to boot. Yikes!)
This fixes it by ensuring our package name actually uniquely identifies
the containerd package.
The choice to use the number of commits since the version as the patch
number is fairly arbitrary, but seemed like a sane and comparable number
to choose.
Due to containerd's somewhat fragile versioning, this number is not
technically unique (since there the v0.2.3 bump is commit to multiple
branches), but we can deal with issues if they happen.
Alternative fixes, such as FETCH_RESTRICT or other means of fooling the
cache logic, are more error prone and less faithful to portage's intent
that ${P} does uniquely identify an upstream source.
A different fix would be to use a CROS_WORKON style process for
containerd. There's no particular reason that approach is being avoided
other than the need to hack on containerd has so far been fairly small.
We can be more sloppy with versioning if/when we switch containerd over
to that process.
The choice to rename to 0.2.3 is because that commit (see
containerd/version.go) chooses to call itself 0.2.3, though it's newer
than the v0.2.5 tag. Docker 1.12 actually used a commit that contained
the 0.2.5 tag.
This is only an issue when the glibc versions differ between the
SDK and the sysroot. The M4 library detection functions in gettext
do bad things on their own, so bypass them.
The Ignition units are only used in the initramfs and are intertwined
with several other units in bootengine. Move them into bootengine for
simplicity.
