Change:
<ins> # Developing Kubernetes Docs in this directory relate to developing Kubernetes. * **On Collaborative Development** ([collab.md](collab.md)): info on pull requests and code reviews. * **Development Guide** ([development.md](development.md)): Setting up your environment; tests. * **Hunting flaky tests** ([flaky-tests.md](flaky-tests.md)): We have a goal of 99.9% flake free tests. Here's how to run your tests many times. * **GitHub Issues** ([issues.md](issues.md)): How incoming issues are reviewed and prioritized. * **Logging Conventions** ([logging.md](logging.md)]: Glog levels. * **Pull Request Process** ([pull-requests.md](pull-requests.md)): When and why pull requests are closed. * **Releasing Kubernetes** ([releasing.md](releasing.md)): How to create a Kubernetes release (as in version) and how the version information gets embedded into the built binaries. </ins>

Discussion:
master-blocking build-master ci-kubernetes-build.Overall ! 2023-02-07 22:06:39 +0000 UTC https://k8s- Link to failing run: make: [Makefile:374: release] Error 1 level=fatal msg="failed to run: running make release: command /usr/bin/make release did not succeed: line 604: ifconfig: command not foundn!!! [0207 23:28:23] Call tree:n!!! [0207 23:28:23] 1: hack/make- kube::golang::buildbinaries(...)nmake[1]: [Makefile:92: all] Error 1nmake: [Makefile:487: cross] Error 1n!!! [0207 23:28:25] Call tree:n!!! [0207 23:28:25] 1: kube::build::runbuildcommandex(...)n!!! [0207 23:28:25] 2: kube::build::runbuildcommand(...)nmake: [Makefile:374: release] Error 1n" Looks like the binary is not present in the test environment. No response /sig testing cc
/priority critical-urgent
/sig release /remove-sig testing looks like needs patching
/cc
I'm about to go offline for the night, probably just needs to add iproute2 package to the apt-get install. I would guess this is because during go1.20 upgrade it also went from buster to bullseye (Didn't confirm, but same issue going from buster to bullseye elsewhere, seems likely go1.20 included a newer debian base)
Thanks Ben!
/assign /triage accepted
/priority critical-urgent
contains only the utility. package has . Long term, we should investigate if we can eliminate using entirely as is touted as its replacement.
you can , do you have a link to the code so I can see if I can PR or suggest how to fix it?
/reopen till the current build passes
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository.

</details
-- references to are across the repositories: The reference to in current context is in There's a check in which should switch to if that is present.
yeah, so that should work if doesn't exist
Yes, that's because even isn't installed.
The build failed again. Investigating:
On a first pass, this looks similar to
I tried building/cross-compiling the server test binaries (which is where the build errored) on an Ubuntu linux/amd64 machine. This seems to be working. Wondering if there's a build environment specific issue.
I tried on latest debian with a cross compile toolchain and golang 1.20 and was successful as well. Do we want to try some workaround like:
I am also thinking to do that. Digging into our toolchain right now.
PTAL at
that looks good. let's try that.
It's green now!
Hm, looks like magically fixed the relocation problem. Ugh, that's odd and it feels that the issue can occur depending on how we change the source code. :roll_eyes: I can still reproduce the issue with , so the test results are correct. !
yeah, that reminds me of where seemingly meaningless code changes fixed a compiler issue do we have a smaller reproducer to give to help with investigation?
Unfortunately not, but I a patch to focus on the failing test build target.
hoisting from do we have the full expanded invocation (including all the goflags / gogcflags / goasmflags / goldflags / tags) that was breaking?

that would help in giving the go team a reproducer
I'm unable to reproduce locally with the following are we sure this is a go issue, or is it an issue with the ARM cross-compiler (), since the cross-compile env changed versions around the same time as the go bump according to
Inside of the kube-build image it's reproducible with: It's reproducible with and
Reproducer with a Dockerfile, on k/k : It breaks with go 1.20 but works with go 1.19.5 on debian:latest (bullseye-, arm-linux-gnueabihf-gcc 10.2.1) It breaks with go 1.20 but works with go 1.19.5 on debian:testing (testing-, arm-linux-gnueabihf-gcc 12.2.0)
xref Seems to be happening again: