So far all sed expressions have used correct regular expressions around
semantic versions, around `.`. As a result, they matched strings even
without correct dots in place.
We need to escape the dot correctly.
Since Kernel 5.10, Github Actions simply stopped working.
What happens is that `KV_MAIN` gets passed as environmental variable to
the inline script, but not as string but float, because it contains `.`.
Apparently the last digit of the misinterpreted float number is
afterwards simply dropped by YAML parsing library used by GA.
As a result, `KV_MAIN` becomes `5.1` instead of `5.10`, `versionMain`
becomes simply `5.10`, not `5.10.6`. Then in the next steps,
both `VERSION_NEW` and `VERSION_OLD` become `5.10`, and the script
thinks it is already the latest version, so simply does not create a new
pull request.
It was not an issue when Kernel version is <= 5.9, because no digit
got dropped from the variable. Now the hidden issue was uncovered.
Simply set `KV_MAIN` or others explicitly as strings, by adding quotes,
to avoid such issues.
The upstream socket is under /run/containerd/containerd.sock which many
tools like crictl will use by default and diverging causes users to
always have to configure a non-default location.
Switch to the upstream default while still keeping a symlink so that
users are not forced to update their configurations they had to do for
the non-default location. This also keeps Docker using the old socket
location as an assertion that the symlink works. The state directory
is also switch to the default location.
Using only 127.0.0.53 for /etc/resolv.conf causes problems for
Kubernetes which is not systemd-resolved aware yet (the kubelet passes
on /etc/resolv.conf contents to containers).
Switch back for now to merging all DNS servers into /etc/resolv.conf
which breaks split DNS and we need to document how to make split DNS
work for those that want it.
When the metadata server is unavailable for some time the service did
not retry. Also, the service was triggered possibly multiple times
each time another service pulled it in which can cause problems if,
e.g., the service experiences a failure and corrupts the existing file
which could have been kept because rerunning wasn't needed.
Fixes https://github.com/kinvolk/Flatcar/issues/311
The patches were not taking effect because they did not set
net.ipv4.conf.default.rp_filter for new interfaces. Also, they got
overwritten by the baselayout configuration which takes precedence
and is the place for Flatcar-specific sysctl settings.
The desired configuration was enfored there:
https://github.com/kinvolk/baselayout/pull/13
The [repo v2.10](https://groups.google.com/g/repo-discuss/c/rpSfMCl83Sk)
was released dropping python2 support. As a result, every `repo init`
failed to run. To unblock CI builds, we released mantle
[v0.15.2](https://github.com/kinvolk/mantle/releases/tag/v0.15.2),
including a workaround to set the target branch to
[`maint`](https://gerrit.googlesource.com/git-repo/+/refs/heads/maint),
which still supports python2. Now with cork v0.15.2, `cork create` or
`cork update` will work well for now.
However, the current state is quite fragile. It will get broken again
when the upstream `maint` branch changes. We should update
`dev-vcs/repo` in coreos-overlay to 2.x with python3, and get it
included in Flatcar SDK, so we could later set the target branch in
mantle back to `stable`.
At the moment, none of the source repos has the tarball for repo 2.10,
neither GCS nor Gentoo distfiles. So for now we update it to 2.8.
It will be linked to python 3.6 in Flatcar SDK.
Also note that we do not have to keep `files/repo-1.25` script in the
coreos-overlay repo, because the script is simply identical to the
upstream `repo` script. I am not sure why the third-party script was
there in the first place. So simply remove the script.
We are getting rid of the virtual/pam package. The package provided a
dependency on one of pam or openpam. It looks like Gentoo dropped
openpam, making virtual/pam unnecessary. Also, existence of
virtual/pam causes some circular dependencies to manifest during
emerging.
We are getting rid of the virtual/pam package. The package provided a
dependency on one of pam or openpam. It looks like Gentoo dropped
openpam, making virtual/pam unnecessary. Also, existence of
virtual/pam causes some circular dependencies to manifest during
emerging.
We are getting rid of the virtual/pam package. The package provided a
dependency on one of pam or openpam. It looks like Gentoo dropped
openpam, making virtual/pam unnecessary. Also, existence of
virtual/pam causes some circular dependencies to manifest during
emerging. This package does not depend on virtual/pam outright, but
let's avoid having an out-of-date comment.
The version now matches what is in Gentoo, despite being almost, but
not quite, entirely unlike upstream recipe. The rename is needed,
because some packages may depend on a newer pambase after they are
updated.
This is to avoid importing fcaps eclass which adds a dependency on
sys-libs/libcap, which in turn depends on sys-libs/pam. To get out of
this conundrum, we could specify a "-filecaps" use flag for
sys-libs/pam. Problem with this solution would be no capability
override for the binary making it unable to read /etc/shadow. Thus we
make the binary suid. This is strictly less secure than overriding its
capabilities, but I have no idea how to solve it in a less hacky way.
