We need to make emerge-gitclone check out its exact remote branch
name, like `refs/remotes/origin/x`, in case of the branch name being
specified as a revision.
See also https://github.com/flatcar-linux/dev-util/pull/2
On DigitalOcean eth0 is still used, so we can just continue
to match for it. Maybe 'e*0' would be possible, too.
There is a problem when IPv6 is activated currently, thus,
just revert the patch.
See also https://github.com/flatcar-linux/bootengine/pull/9
The torcx profile docker-17.03 start not to work since it started
pulling in docker-runc 1.0-rc10, with an error message 'flag provided
but not defined: -console'. That's because Docker 17.03 is incompatible
with runc 1.0-rc4 or newer. [1] So the docker-17.03 profile needs to
pull in docker-runc 1.0-rc2 like before. Bring back docker-runc 1.0-rc2
and its related patches that were removed.
[1] 244c9fc426
In the initramfs persistent ifnames were disabled.
This caused problems because when the renaming was
done after the initramfs, a race made it fail, as
originally reported in
https://github.com/coreos/bugs/issues/1767
Reverts the booteninge commit
"systemd: add module to disable network device renaming"
and widens the networkd match rule for DigitalOcean.
Since sudo 1.8.28, every sudo started printing out a warning like
`/etc/environment: No such file or directory`, when `/etc/environment`
does not exist.
Also sudo <= 1.8.30 is affected by a pwfeedback vulnerability,
CVE-2019-18634. https://seclists.org/oss-sec/2020/q1/48
Update sudo to 1.8.31 from upstream Gentoo, to resolve the issues.
See also https://bugs.gentoo.org/698946.
When /etc/flatcar/docker-1.12 contains "no"
the profile for 18.06 was searched for instead
of 19.03. Keep docker-1.12-no.json in sync
with the latest version in app-torcx/docker/files/.
The host's /etc/nsswitch.conf is a symlink to
/usr/share/google-oslogin/nsswitch.conf
but that is not present in the rkt container.
Do not only bind-mount /etc but also the target
of the symlink. With a broken nsswitch.conf
any entries in /etc/hosts are not considered
which makes problems when a custom DNS server
is used.
When a custom DNS server is used
coreos-metadata-sshkeys@core.service
fails to resolve metadata.google.internal
because only "metadata" is specified in /etc/hosts.
