Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mkuimage: advise GOAMD64=v1 for GOARCH=amd64 #40

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

lersek
Copy link

@lersek lersek commented Mar 12, 2025

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

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

Signed-off-by: Laszlo Ersek <[email protected]>
@lersek
Copy link
Author

lersek commented Mar 12, 2025

@MDr164 @ChriMarMe @leongross @rminnich @hugelgupf can you please review? Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant