release: v0.3.1

VERSION 0.3.0 -> 0.3.1. Append CHANGELOG entry covering the eight fix
commits since v0.3.0 (dual-glibc, nft binary, NF_TABLES_IPV4 family,
NFT_NUMGEN expressions, modules.list parser, banner+motd, port 8080
hostfwd, and the release.yaml workflow rewrite).

End-to-end validated on Apple Silicon Mac under QEMU virt + HVF:
  - kubectl get nodes -> kubesolo-XXXXXX  Ready
  - kube-system/coredns                   1/1 Running
  - local-path-storage/local-path-prov    1/1 Running
  - default/nginx-test (user workload)    1/1 Running (pulled+started 11s)

Tagging this release is also the first real exercise of the rewritten
release.yaml workflow. If it works as designed, the v0.3.1 release page
should populate automatically with: x86 ISO + .img.xz, ARM64 .arm64.img.xz,
Go binaries (cloudinit + update, amd64 + arm64), and SHA256SUMS.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

CHANGELOG.md

@@ -5,6 +5,92 @@ All notable changes to KubeSolo OS are documented in this file.
 Format based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 versioning follows [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.3.1] - 2026-05-15
+
+First fully-functional generic ARM64 release. v0.3.0 shipped the build
+scaffold; v0.3.1 makes it actually boot a Kubernetes cluster end-to-end
+on QEMU virt under HVF acceleration. Validated by deploying CoreDNS,
+local-path-provisioner, and an `nginx:alpine` workload — all reach
+Running, `kubectl get nodes` reports `Ready`.
+
+### Fixed
+
+- **Dual-glibc loading on ARM64** — piCore64's `/lib/libc.so.6` and the
+  build host's `/lib/$LIB_ARCH/libc.so.6` could both be resolved into the
+  same process by the dynamic linker, triggering
+  `*** stack smashing detected ***` aborts when stack frames crossed
+  between functions linked against different libcs. Fix: bundle the full
+  glibc family (libc + libpthread + libdl + libm + libresolv + librt +
+  libanl + libgcc_s + ld.so), delete piCore's duplicates in `/lib/`,
+  and write `/etc/ld.so.conf` + `ldconfig -r` so the runtime linker has
+  a deterministic search order. (`76ed2ff`)
+- **`nft` binary not bundled** — KubeSolo v1.1.4+ runs `nft add table ip
+  kubesolo-masq` for pod-masquerade setup, but `inject-kubesolo.sh` only
+  bundled `xtables-nft-multi`. Without standalone `nft` in `$PATH`,
+  KubeSolo FATAL'd at startup. Fix: copy `/usr/sbin/nft` + its
+  non-shared libs (libnftables, libedit, libjansson, libgmp, libtinfo,
+  libbsd, libmd) into the rootfs. (`51c1f78`)
+- **nftables address-family handlers** — `nf_tables` core was loaded but
+  no address families were registered, so `nft add table ip ...`
+  returned `EOPNOTSUPP`. The bool Kconfigs `CONFIG_NF_TABLES_IPV4`,
+  `CONFIG_NF_TABLES_IPV6`, `CONFIG_NF_TABLES_INET`,
+  `CONFIG_NF_TABLES_NETDEV` are required and weren't in the
+  fragment. Fix: add to `kernel-container.fragment` as `=y`. (`7e46f8f`)
+- **kube-proxy nftables-backend expression modules** — Kubernetes 1.34's
+  kube-proxy nft backend uses `numgen`, `hash`, `limit`, `log`
+  expressions. The corresponding kernel modules (`CONFIG_NFT_NUMGEN`,
+  etc.) were missing from the fragment AND the runtime module list, so
+  even after a kernel rebuild stage 30 didn't load them and stage 85's
+  `kernel.modules_disabled=1` lockdown prevented on-demand loads. Fix:
+  add to both `kernel-container.fragment` (as `=m`) and
+  `modules.list` / `modules-arm64.list`. (`31eee77`, `3bcf2e1`)
+- **`modules.list` inline-comment parser bug** — the inject script's
+  comment-strip only matched lines starting with `#`, not lines with
+  inline `# comment` tails. So `nft_numgen     # foo` was passed
+  verbatim to modprobe, resolved to nothing, and the .ko never made it
+  into the initramfs. Fix: parse with `mod="${mod%%#*}"` to strip
+  inline tails. (`bc3300e`)
+- **Banner only printed on kubeconfig success** —
+  `90-kubesolo.sh` gated the host-access banner behind `if [ -f
+  $KUBECONFIG_PATH ]`. When KubeSolo crashed early (bug #2 above) or
+  the wait loop timed out, the user never saw the connection
+  instructions. Fix: write the banner to `/etc/motd` AND print it
+  unconditionally after the wait loop. (`51c1f78`)
+- **`dev-vm-arm64.sh` missing port-8080 hostfwd** — the in-VM HTTP
+  server that serves the kubeconfig listens on port 8080, but the
+  QEMU `-net user` line only forwarded 6443 and 2222, so
+  `curl http://localhost:8080` from the host machine connected to
+  nothing. Fix: add the third hostfwd. (`fbe2d0b`)
+
+### Fixed (CI)
+
+- **`release.yaml` workflow** rewritten so v0.3.1+ tag pushes
+  auto-publish a complete release page on Gitea: `actions/upload-artifact`
+  pinned to `@v3` for act_runner compatibility, the
+  `softprops/action-gh-release@v2` step replaced with a direct `curl`
+  against `/api/v1/repos/.../releases` (`softprops` hard-codes
+  `api.github.com` so it silently no-ops on Gitea), added a
+  `build-disk-arm64` job that builds on the `arm64-linux` runner.
+  v0.3.0's manual-upload-only release was the canary that exposed all
+  three bugs. (`f8c308d`)
+
+### Known issues carried forward to v0.3.2
+
+These don't block normal operation but are tracked:
+
+- `xt_comment` userspace extension load fails on the iptables-nft path,
+  causing kubelet's KUBE-FIREWALL rule install to skip. Reported as
+  `Couldn't load match 'comment'` in the boot log. kubelet continues
+  without the localhost-drop rule.
+- `containerd-shim-runc-v2 -info` probe reports `runc: executable file
+  not found in $PATH`. Cosmetic — containerd uses the absolute path
+  from its config when actually launching containers.
+- `kube-proxy conntrack cleanup` logs `Failed to list conntrack entries:
+  invalid argument` every cleanup cycle. Probably needs
+  `CONFIG_NF_CONNTRACK_PROCFS` or netlink-glue tweaks.
+- Several pods restart 1–2 times on first boot due to a PLEG /
+  runtime-probe race in the kubelet startup path. Pods stabilise.
+
 ## [0.3.0] - 2026-05-14
 
 The main themes: generic ARM64 (not just Raspberry Pi), an honest update

VERSION

@@ -1 +1 @@
-0.3.0
+0.3.1