Troubleshooting

Start with the splash screen, then verify from another machine with curl.

No Node URL Appears

Expected splash states:

State	Meaning
starting LapEE...	Network has not produced a primary interface yet.
network up; starting HyperBEAM...	DHCP succeeded and PermawebOS is starting.
Running at http://HOST:8734/	Use this URL from another machine.

If the screen appears stuck, probe the node anyway:

export NODE_URL=http://HOST:8734
curl -fsS -H 'accept: application/json' \
  "$NODE_URL/~measurement@1.0/info"
curl -fsS -H 'accept: text/plain' \
  "$NODE_URL/~meta@1.0/info/address"

If those return, the node is up.

WiFi File Rejected

wifi.conf must contain exactly two lines:

SSID
WPA2-PSK

Rules enforced at boot:

• SSID length: 1 to 32 bytes.
• SSID characters: letters, digits, underscore, space, dot, apostrophe, dash.
• PSK length: 8 to 63 bytes.
• PSK characters: printable ASCII only.
• PSK must not contain ", \, $, or backtick.
• No NUL bytes or extra lines.

Prefer Ethernet when possible.

Verifier Cannot Reach The Node

Use the exact URL from the splash:

curl -fsS -H 'accept: application/json' \
  -H 'accept-bundle: true' \
  "$NODE_URL/~measurement@1.0/boot"

If that fails, check local network routing, router client isolation, VPN state, and host firewall rules.

Secure Boot Fails

Check which trust path the release expects:

• release key enrolled;
• exact UKI hash admitted;
• or local operator key enrolled for a local build.

Adding config.json or wifi.conf changes the disk image hash, but it does not change EFI/Boot/BootX64.efi.

Memory-Encryption Halt

The default physical LapEE image expects Intel TME or AMD SME. Use the no-TME release image only when the target hardware cannot satisfy that gate and the release policy allows that posture.

The no-TME image is still measured. It records the posture in the measured kernel command line.

Profile Did Not Load

Check that the profile was staged as config.json beside the Makefile before running:

make operator-config-apply IMAGE=build/images/lapee-usb.img

The helper copies it into the image as EFI/boot/config.json. If you changed config.json after writing the USB, rerun:

make operator-config-apply IMAGE=build/images/lapee-usb.img
make write-image DEV=/dev/diskN IMAGE=build/images/lapee-usb.img

Then query the live node:

curl -fsS -H 'accept: text/plain' \
  "$NODE_URL/~meta@1.0/info/lapee-profile"
curl -fsS -H 'accept: text/plain' \
  "$NODE_URL/~meta@1.0/info/load-remote-devices"
curl -fsS \
  -H 'accept: application/json' \
  -H 'accept-bundle: true' \
  "$NODE_URL/~meta@1.0/info/trusted-device-signers" \
  | jq '[to_entries[] | select(.key | test("^[0-9]+$")) | .value]'

trusted-device-signers is an AO json@1.0 list. If you omit accept-bundle: true, a browser or plain curl may render HyperBuddy HTML or a linked AO message instead of the signer list.

If lapee-profile is missing, check JSON syntax and file size. Invalid config.json is replaced with {} at boot.

Measurement Fails

Use the node-side replay check first:

curl -fsS -H 'accept: application/json' \
  "$NODE_URL/~measurement@1.0/boot/~measurement@1.0/verify"

Common causes:

• quote signature failure;
• nonce or PCR digest mismatch;
• AK policy mismatch;
• PCR 15 replay failure;
• profile/config did not match the verifier policy;
• Secure Boot or memory-encryption posture differs from the accepted policy.

Use ~measurement@1.0/boot as the current boot evidence route. Older ~tpm@2.0a/boot-attestation references are stale.

Browser Shows HTML

Browser requests often prefer HyperBuddy or explorer output. For probes, use explicit accept headers:

curl -fsS -H 'accept: application/json' "$NODE_URL/~measurement@1.0/info"
curl -fsS -H 'accept: text/plain' "$NODE_URL/~meta@1.0/info/address"