Users who need to use gokr-packer to migrate an existing setup to the
instance-centric config can use the following command to install the
last version before it was deleted:
go install github.com/gokrazy/tools/cmd/gokr-packer@703a8605028963d13a9d00815ccedfae13f0ce6d
fixes https://github.com/gokrazy/gokrazy/issues/301
Before this commit, the mere presence of files with certain names in local
package directories would make the build fail (see nonmodulefiles_test.go).
With this commit, we now record the buildinfo and buildid of all built Go
programs of this gokrazy instance.
related to https://github.com/gokrazy/gokrazy/issues/297
fixes https://github.com/gokrazy/gokrazy/issues/299
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
This is useful for mounting a tmpfs and installing busybox
(e.g. the version that comes with the serial-busybox package):
mount -t tmpfs tmpfs /bin
ln -s /tmp/serial-busybox/ash busybox
./busybox --install -s /bin
Afterwards, TRAMP (transparent remote access) in Emacs works:
emacs /ssh:scan2drive:/perm/keep/index.md
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.
Commit a59c9ad5f4 was not entirely correct:
It is desired to call getGokrazySystemPackages(), but we should also
keep looking at cfg.Packages (which the commit didn’t).
This fixes errors such as:
2024/09/11 08:41:50 Error: build directory
"/home/michael/gokrazy/router7/builddir/github.com/stapelberg/prober7/cmd/probe"
does not exist in
"/home/michael/gokrazy/router7/builddir/github.com/gokrazy/serial-busybox"
related to https://github.com/gokrazy/gokrazy/issues/264
Currently, both the gokrazy/firmware and the gokrazy/kernel.rpi repository
contain an overlays directory. The desired state is that only gokrazy/kernel.rpi
contains an overlays directory, as that is the repository from which the
overlays are built (whereas the are only copied into the firmware repository).
To prevent confusion between different versions, the packer now returns an error
instead of silently overwriting files on the boot partition when there are
multiple sources for a file.
Before this change, the packer created an empty directory unconditionally,
which resulted in surprising errors in programs like breakglass.
closes https://github.com/gokrazy/breakglass/issues/19
The /var directory is meant to hold data that changes (see hier(7)).
With the previous behavior, users had to bind-mount a writable
and persistent directory over /var, for example as documented in
https://gokrazy.org/packages/docker-containers/
With this commit, there is one fewer hurdle to get podman running.
The sumdb/dirhash package was built to work with extracted Go module zip files,
but we are working with directories on local disk (working copies).
So, to reflect what the Go tool would see as source code,
we now use the same code.
Specifically, the old approach failed with symbolic links to directories,
because it treated them as regular files (Go module zips do not contain
irregular files such as symlinks).
prior to this commit SBOMs would have inconsistency in their hashing on
the configuration file.
The representation of the config file in fact would differ at certain
stages of the gok commands lifecycle, where at packer running time,
an extra InternalCompatibilityFlag, Sudo, would be added in memory
(while that not being the case at `gok sbom` time),
resulting in a differing config and as such differing SBOM hashes, same
goes for the differing pointer addresses that were skew the hashing
results.
This is now fixed by using the SudoOrDefault() accessor,
as well as converting the config into a string before computing the hash,
to avoid differing pointer problems.
A bug was triggered when the file system contained two directories with the same
basename, because all directories were incorrectly associated with the root
directory.
fixes https://github.com/gokrazy/tools/issues/58
This can happen when adding a program called "hello",
when the default config already pulls in github.com/gokrazy/hello.
The previous error message was confusing and non-deterministic,
because it contained the name of whichever package happens to be
validated first.
