mkuimage: advise GOAMD64=v1 for GOARCH=amd64 #40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the user builds an initrd for amd64, and their golang toolchain is configured for an amd64 ABI version greater than 1, then issue a warning.
Binaries built for GOAMD64=v2+ may crash with an #UD exception on old CPUs, or exit immediately (gracefully) with an error message like "This program can only be run on AMD64 processors with v2 microarchitecture support" [1]. Such a dysfunctional "init" (gobusybox) binary renders a u-root initrd effectively unbootable. qemu-system-x86_64 with no particular "-cpu" option is affected by this, for example.
GOAMD64 defaults to v1 [2], but it may be overridden in at least three places (in increasing order of importance):
the system-wide "go.env" file, such as "/usr/lib/golang/go.env",
the user's "go.env" file, such as "$HOME/.config/go/env",
the env var GOAMD64.
For example, RHEL9 and its derivative distros set GOAMD64 to v2 in "/usr/lib/golang/go.env".
It seems like the canonical way for deducing GOAMD64 programmatically is to invoke "go env GOAMD64" [3].
[1] golang/go@8c8baad927b2
[2] https://go.dev/wiki/MinimumRequirements#amd64
[3] golang/go#72791