docs(packaging): "signs with your own MOK" is measured, and says what happens without one (Refs #1280)

docs/install-any-distro.md

@@ -259,6 +259,20 @@ dkms packages are the other way round: dkms signs with *your* key (`/var/lib/shi
 Debian/Ubuntu, `/etc/dkms/` elsewhere), so a module built on your machine chains to the MOK you
 enrolled for it — on Fedora and Arch, dkms generates that key pair on first use.
 
+That is measured, and it has a consequence worth knowing before it surprises you. Same package, same
+kernel, only the machine differing (`ubuntu:26.04`, headers `7.0.0-43-generic`):
+
+| machine | what dkms did | what the module says |
+|---|---|---|
+| a MOK at `/var/lib/shim-signed/mok/{MOK.priv,MOK.der}` | `scripts/sign-file`, sha512 | `signer: <that certificate's CN>`, a `sig_key` fingerprint |
+| no MOK on the machine | `Binary update-secureboot-policy not found, modules won't be signed` | `signer:` empty, `sig_key:` empty |
+
+So **with Secure Boot on and no MOK of your own, the driver installs, builds, and then will not load** —
+`modprobe` refuses an unsigned module, and nothing in the package can help, because a key it shipped
+would not be trusted. Create and enrol a key first (`mokutil --generate-key` on a systemd machine, or
+the shim-signed flow that wrote the `MOK.priv`/`MOK.der` above), then `dkms autoinstall` rebuilds and
+re-signs. With Secure Boot off, the unsigned module loads and none of this matters.
+
 Verify (no model needed):
 
 ```bash
@@ -397,4 +411,5 @@ registry model, since this Lemonade version has no local-file registration):
 | the kernel the packages ship is the kernel this box runs | `linux-image-7.4.0-rc1-1bit_7.4.0~rc1-1_amd64.deb` payload vs `/boot/vmlinuz-7.4.0-rc1-1bit` | `sha256 6f3c6764…` in both, and `sbverify --cert MOK-Kernel.der` reports `Signature verification OK` |
 | the amdxdna floor is really 6.10 | clean `ubuntu:24.04` container, headers `6.8.0-149-generic`, this page's packages | `dkms build` refuses with the declared exclusive rule (`rc=77`, "should not be built"), and with the floor bypassed the driver does not compile: `amdxdna.h:32: macro "__assign_str" requires 2 arguments, but only 1 given` — the 6.10 trace-event API. `ec-su-axb35-dkms` builds on the same headers (`380 440 B`), so only the NPU driver has the floor |
 | a weekly release tag works in all three families, and upgrades | `scripts/mk-kernel-packages.sh <out> 2026.45.0 --skip-kernel`, each family's own tool, in `fedora:latest` / `ubuntu:26.04` / `archlinux:latest` | deb `0.18.0-1 < 0.18.0-2026.45.0` (dpkg), rpm `0.18.0-1 < 0.18.0-2026.45.0` (rpmdev-vercmp), arch `vercmp` `-1`; each installs over the previous package (`rc=0`) and reports `0.18.0-2026.45.0` afterwards, with one `/usr/src/amdxdna-1bit-0.18.0` left on deb — no stale duplicate source tree |
+| the dkms package signs with the machine's own MOK, and what happens without one | clean `ubuntu:26.04` container, headers `7.0.0-43-generic`, `amdxdna-1bit-dkms` 0.18.0-1, paired with and without a MOK at `/var/lib/shim-signed/mok` | with one: `scripts/sign-file`, sha512, `modinfo -F signer` = that certificate's CN and a `sig_key`; without: `modules won't be signed`, `signer` and `sig_key` empty. So the package chains to the user's key — and on a Secure Boot machine with no MOK of its own the module installs, builds, and refuses to load |
 | the shipped driver answers a known answer on the NPU | this box, `npu-hold`, `1bit serve --device npu` on Qwen3-0.6B, `/v1/completions` greedy, twice | load 2.2 s, `The capital of France is` → **` Paris. The capital of Italy is Rome. The capital of Spain is Madrid.`** identically on both runs (56.9 and 50.7 tok/s), 0 `amdxdna` lines in the two windows, and the loaded module is `srcversion EE1F36A2B9BA294CE11AD80` — the build this package's source produces. No install, no `modprobe`, no udev reload |