Kai Lüke

We also have https://github.com/flatcar-linux/Flatcar/issues/685 still open as regression from an earlier release

Merging these sections with any manually defined `/etc/(coreos|flatcar)/update.conf` content would be great to prevent settings getting lost.

I think we still wanted to generate the OEM images with the firmware, or?

> Hi @pothos, I have stumbled across your PR [coreos/ignition#1319](https://github.com/coreos/ignition/pull/1319) which is not merged yet and is planned for coreos/ignition release [2.14.0](https://github.com/coreos/ignition/pull/1354). I was wondering if this could be related....

Systemd has tooling for TPM 2.0 things, but we don't ship any other userspace tooling on the OS (you would need to use a container for that at the moment)

Have started a rebuild of the latest Alpha: http://192.168.42.7:8080/job/os/job/manifest/5823/cldsv/ with [0001-dev-lang-python-oem-use-python-from-python-build-sta.patch](https://github.com/flatcar-linux/Flatcar/files/8870841/0001-dev-lang-python-oem-use-python-from-python-build-sta.patch.txt)

Thanks, maybe this is already reported upstream in one of https://github.com/systemd/systemd/issues?q=is%3Aissue+is%3Aopen+resolved or even closed?

I do not recommend to disable the whole service due to the integration with networkd but just remove `resolve [!UNAVAIL=return]` from `/etc/nsswitch.conf`: ``` # make a copy to edit the...

Thanks. Does that mean the error even happens when responding a cached entry after a successful resolution?

Can you create a new upstream issue for this? It could be some internal logic not involving syscalls but if it is, it's worth capturing a syscall trace. Either with...