# 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](mailto: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:

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

Expected output:

```text
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

```bash
protect --version
```

Example output:

```text
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`](https://docs.edera.dev/reference/edera-check/) on the affected node and save the output:

```bash
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:

```bash
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

```bash
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:

```bash
# 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](mailto: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 2026-07-16