The key server currently doesn't work. Since the key is not used
currently but the key we have hosted on our web server, we can remove
this failing step to restore GitHub Actions.
Enable Kernel config for PSI (Pressure Stall Information), which might
help system administrators to detect bottleneck in cpu, memory and io
in an easy way.
```
$ zgrep -i _psi /proc/config.gz
CONFIG_PSI=y
$ ls -l /proc/pressure/
-r--r--r--. 1 root root 0 Oct 7 11:56 cpu
-r--r--r--. 1 root root 0 Oct 7 11:56 io
-r--r--r--. 1 root root 0 Oct 7 11:56 memory
$ cat /proc/pressure/cpu
some avg10=0.13 avg60=0.68 avg300=0.28 total=1195993
$ cat /proc/pressure/io
some avg10=0.00 avg60=1.11 avg300=0.68 total=2828208
full avg10=0.00 avg60=0.91 avg300=0.56 total=2334731
$ cat /proc/pressure/memory
some avg10=0.00 avg60=0.00 avg300=0.00 total=0
full avg10=0.00 avg60=0.00 avg300=0.00 total=0
```
See also https://www.kernel.org/doc/html/latest/accounting/psi.html ,
https://facebookmicrosites.github.io/psi/docs/overview
Fixes https://github.com/flatcar-linux/Flatcar/issues/162
Use host tool when building cross.
Bump revision to -r1.
Adjust the patch on top of dbus-glib 0.110.
Original-by: Geoff Levand <geoff@infradead.org>
6d7756b77b10 ("dev-libs/dbus-glib: Fix cross compile build error")
We have these patches in v245 too. I have missed them when doing the
update to v246, because apparently I have assumed that our flatcar
branches are more or less some upstream branch/tag + our patches on
top. That assumption was wrong and it surfaced when I rebased the
v245-flatcar branch to the v245.8 tag.
Our current cros-workon setup was awkward to use when a new patch
release happened on upstream. In this case we would go to our
`v<VERSION>-flatcar` branch and merge/cherry-pick the commits from
upstream that appeared between the release we have been using so far
and the new release. In such case, our non-upstreamed patches were
hidden somewhere in history. To fix that, I proposed having a branch
for each patch release, so the branch would always be based on an
upstream tag and have our patches on top of that. An alternative
proposition was to just use the Gentoo workflow for patches, and this
is what we are doing here.
This also slightly minimizes the difference between the Gentoo recipe
and ours.
To be able to update `dev-util/gdbus-codegen` to 2.64.5, we need to
specify a single target python3.6 for gdbus-codegen.
Without it, it is not possible to emerge gdbus-codegen, because
it thinks there are multiple python single targets for the package.
Now that Go 1.10 has been removed, we can remove `dev-lang/go:1.10`
from the SDK dependencies list.
Instead add `dev-lang/go:1.15` to the SDK dependencies list.
So far Flatcar has kept a third-party patch to add a blank kernel
module `nf-conntrack-ipv4.ko` to avoid regression around Kubernetes.
The issue was that kube-proxy with ipvs started using `nf-conntrack.ko`,
which does not exist in Kernel < 4.19. The patch was originally added by
a24dbb6cb6.
However, Kubernetes 1.13 or newer already deals with the issue. It
automatically loads a different Kernel module according to Kernel
versions: `nf-conntrack-ipv4` for Kernel < 4.19, and `nf-conntrack`
for Kernel >= 4.19.
See 4b90559369 .
We can simply remove the Kernel module, as since then all production
systems have updated Kubernetes to the newer versions than 1.13.
The diffutils package provides the "cmp" and "diff" tools which are
essential commands in shell scripts. They used to be pulled in by
audit but the update in
https://github.com/flatcar-linux/coreos-overlay/pull/537
caused them to be dropped.
Add them to the explicit list of base packages to ensure they are
installed.
Because the --root option restricts systemd-tmpfiles to the passwd
database file in the package chroot it can't resolve the core user
and fails to set up the home folder from the baselayout-home.conf
directives.
Create the folder manually because creating a /etc/passwd file in
the package chroot would at installation overwrite the SDK user.
This reverts commit c414b38c7c56dafb05a86040443c634763527f05.
The real DNS server IP addresses should be in /etc/resolve.conf and not
just 127.0.0.53 because all cases that bind-mount /etc/resolve.conf
into a new network namespace can't reach the loopback interface that
resolved is listening on.
systemd-tmpfiles in systemd v246 requires the user/group databases in
the custom root if it gets passed with --root flag. This requires a
new version of baselayout to be pulled, so do so.
DTC (Device Tree Compiler) source tree in Flatcar Kernel modules
unnecessarily takes too much space, especially the `include-prefixes`
directory.
```
$ sudo du -a /usr/lib64/modules/$(uname -r)/source/ | sort -n -r | head -n5
130100 /usr/lib64/modules/5.8.11-flatcar/source/
69180 /usr/lib64/modules/5.8.11-flatcar/source/include
56324 /usr/lib64/modules/5.8.11-flatcar/source/scripts
51384 /usr/lib64/modules/5.8.11-flatcar/source/scripts/dtc
50728 /usr/lib64/modules/5.8.11-flatcar/source/scripts/dtc/include-prefixes
$ sudo ls /usr/lib64/modules/$(uname -r)/source/scripts/dtc/include-prefixes/
arc arm arm64 c6x dt-bindings h8300 microblaze mips nios2 openrisc powerpc sh xtensa
```
Most of them are for architectures that are not supported by Flatcar, so
we can remove them from the production image.
OTOH, as `dt-bindings` looks more like an architecture-independent one,
for now we keep it.
Before:
```
$ du -s /usr/lib64/modules/$(uname -r)/source/scripts/dtc/
51384 /usr/lib64/modules/5.8.11-flatcar/source/scripts/dtc/
$ du -s /usr/lib64/modules/
250308 /usr/lib64/modules/
$ df /usr
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/usr 1007760 934152 21592 98% /usr
```
After:
```
$ du -s /usr/lib64/modules/$(uname -r)/source/scripts/dtc/
6632 /usr/lib64/modules/5.8.11-flatcar/source/scripts/dtc/
$ du -s /usr/lib64/modules/
205144 /usr/lib64/modules/
$ df /usr
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/mapper/usr 1007760 907628 48116 95% /usr
```
