Escalate to Edera support

2 min read

If you hit a problem you can’t resolve, this page walks you through collecting the right diagnostic information before reaching out to support@edera.dev. The more context you include, the faster we can help.

Step 1: Check that Edera services are running

On the affected node, verify all Edera daemons are active:

systemctl list-units --type=service | grep protect

Expected output:

protect-cri.service        loaded active running Edera Protect CRI
protect-daemon.service     loaded active running Edera Protect Daemon
protect-gpu-scrub.service  loaded active running Edera GPU scrubber
protect-meminfo.service    loaded active exited  Protect meminfo remount
protect-monitor.service    loaded active running Edera Protect Monitor Daemon
protect-network.service    loaded active running Edera Protect Networking Daemon
protect-preinit.service    loaded active exited  Edera Protect Pre-Initialization
protect-storage.service    loaded active running Edera Protect Storage Daemon

If any service is failed or missing, note it. That’s useful context for support.

Step 2: Get your version string 

protect --version

Example output:

edera-protect-ctl 1.10.8+sha.444f4d2

Include the full version string in your support request.

Step 3: Run edera-check

Run edera-check postinstall on the affected node and save the output:

docker run --pull always --pid host --privileged \
  ghcr.io/edera-dev/edera-check:stable postinstall 2>&1 | tee edera-check.txt

Step 4: Run the debug report

The Edera debug report collects hardware, kernel, network, and Edera-specific diagnostic data into a ZIP file. Run it as root on the affected node:

sudo /var/lib/edera/protect/support/edera-debug-report

This produces a file named edera-debug-report-YYYYMMDD-HHMMSS.zip in the current directory. It makes no network connections and does not send data anywhere automatically.

ℹ️
Review before sending. The ZIP may include hardware details, kernel logs, network configuration, and Edera zone logs. Open it with any ZIP tool and check the contents before sharing. If you need to exclude specific data, see the optional flags below.

Optional: exclude sensitive data 

sudo /var/lib/edera/protect/support/edera-debug-report --no-journal --no-network

Available flags:

  • --no-acpi: Skip ACPI tables
  • --no-dmi: Skip DMI/SMBIOS data
  • --no-journal: Skip full systemd journal
  • --no-network: Skip network configuration
  • --no-protect-zone-logs: Skip zone list and per-zone logs
  • --no-systemd-units: Skip systemd unit state
  • --no-unit-journal: Skip Edera-specific systemd journal logs

Step 5: Collect Kubernetes context (if applicable)

If you’re running Edera on Kubernetes, include the following:

# Node status
kubectl get nodes -o wide

# All pods in the affected namespace
kubectl get pods -n <namespace> -o wide

# Describe the affected pod
kubectl describe pod <pod-name> -n <namespace>

# Edera runtime class
kubectl get runtimeclass edera

Send to support

Email support@edera.dev with:

  1. A description of what you were doing and what went wrong
  2. Your version string from Step 2
  3. The edera-check.txt output from Step 3
  4. The debug report ZIP from Step 4
  5. The Kubernetes output from Step 5 (if applicable)
Last updated on