Before this commit, we held onto *cobra.Command objects,
but that is not actually supported: after the first Execute(),
commands like updateCmd are stuck on the first-ever provided ctx.
Instead, turn command initialization into functions.
I only noticed this when trying to do two 'gok update'
from within the same test, where the fake build timestamp
is injected via the context (the timestamp was always the same).
it updates the arm64 UEFI firmware to a version newer than 2023.11,
as running on qemu >= 9.0 can trigger a bug in the older versions of the EDK2 guest firmware,
causing Synchronous Exception and potential bootloops.
While doing so it updates the amd64 OVMF firmware, which now has removed
support for the 2M firmware and only supports the 4M one.
The 4M OVMF firmware comes with split CODE and VARS images, which need
to be loaded as pflash drives in the qemu vm, rather than via the -bios
flag.
For more details on the migration see: https://salsa.debian.org/qemu-team/edk2/-/blob/debian/latest/debian/howto-2M-to-4M-migration.md
Fixes https://github.com/gokrazy/tools/issues/80
For gok vm run, this means an explicit -arch=amd64 or -arch=arm64
might become necessary. In general, I recommend configuring
GOOS and GOARCH in config.json explicitly:
{
"Hostname": "repro",
"Environment": [
"GOOS=linux",
"GOARCH=amd64"
],
[…]
related to https://github.com/gokrazy/gokrazy/issues/191
Whether edk2 is available on operating systems varies,
so the best choice is to embed the amd64/arm64 EFI files.
We need these files to boot amd64 images in EFI mode,
and also for arm64 images to boot at all.
