Elastic Defend fails on Linux Mint 22.3: Endpoint rejects stage 1 connection to Agent ("Unknown Distribution")

[unwind126]

Version

2.4.211

Installation Method

Security Onion ISO image

Description

configuration

Installation Type

Standalone

Location

on-prem with Internet access

Hardware Specs

Meets minimum requirements

CPU

4

RAM

32

Storage for /

150 GB

Storage for /nsm

77 GB

Network Traffic Collection

span port

Network Traffic Speeds

1Gbps to 10Gbps

Status

Yes, all services on all nodes are running OK

Salt Status

No, there are no failures

Logs

No, there are no additional clues

Detail

We're deploying Elastic Agent with Elastic Defend from our Security Onion manager to a Linux Mint 22.3 workstation. Our first attempt used the Linux installer from our Security Onion instance's Downloads page (so-elastic-agent_linux_amd64), and it failed. We cleaned up its leftovers and reinstalled using the Elastic Agent 9.0.8 DEB package instead. The DEB install enrolled successfully: Agent connects to Fleet, and the system and osquery integrations report healthy. Elastic Defend, however, has never come up. Endpoint installs and runs as a service, but it never completes its connection to Agent, so it never receives a policy.

We've worked through the usual causes (details below) and narrowed it to Endpoint rejecting the local handshake with Agent. Endpoint also reports the host as an "Unknown Distribution," and we suspect that's related, but we couldn't confirm it. We'd appreciate guidance on whether Mint is expected to work with Defend, and if so, what else to check.

Environment

• Security Onion 2.4.211, standalone
• Manager health: all SOC Grid services running OK. salt-call state.highstate completes with 0 failed states (1,667 run). Nothing relevant in /opt/so/log/: the only Fleet Server entries for this host are routine "applying new local metadata" messages.
• Endpoint enrolled in the default endpoints agent policy, using the Security Onion Logstash output
• Host OS: Linux Mint 22.3 (Zena), based on Ubuntu 24.04 (noble)
• Kernel: 7.0.0-38-generic (Ubuntu 24.04 HWE)
• Elastic Agent 9.0.8 and Elastic Endpoint 9.0.8, installed via DEB package after the Security Onion installer failed

Symptom

Agent status shows Fleet connected and healthy, but the Endpoint component fails with endpoint service missed 3 check-ins, and Fleet shows "No policy response available." Endpoint has never completed a check-in: the component's version_info in state.yaml is empty, and /opt/Elastic/Endpoint/elastic-endpoint.yaml was never created.

What the logs show

Every 5 seconds, Endpoint logs this sequence, all within microseconds:

AgentConnectionInfo.cpp:159 Failed to connect bootstrap socket
AgentConnectionInfo.cpp:193 Validated agent (AGENT_PID) is root/admin
AgentConnectionInfo.cpp:336 Failed to establish stage 1 connection to agent
AgentComms.cpp:1032 Unable to retrieve connection info from Agent (Not connected)

Agent's side logs the matching failure (1,000+ occurrences):

Creating connection info server for endpoint service, address: unix:///var/lib/elastic-agent/.eaci.sock
failed write conn info: failed to write startup information: write unix /var/lib/elastic-agent/.eaci.sock->/var/lib/elastic-agent/.eaci.sock.client: write: broken pipe

So Endpoint reaches Agent's socket and validates it, then closes the connection before Agent can send the connection info.

Endpoint also consistently reports:

MetadataThread.cpp:174 Operating System is: Unknown Distribution 22.3

Requesting diagnostics from Fleet times out on the Endpoint component (diagnostic action timed out, deadline is 1m0s), since Agent can't reach Endpoint over the broken connection.

Ruled out

• Network and firewall: the connection uses a local Unix socket. There are no AppArmor denials in the kernel log.
• Permissions: elastic-agent.sock is srwx------ root:root, and both processes run as root.
• Leftover installs: one version directory, no /opt/Elastic/Agent. Earlier installer leftovers were cleaned up.
• Missing files: endpoint-security, its resources zip, and its spec file are present in components/.
• Version mismatch: Agent and Endpoint are both 9.0.8.
• Stale state: restarted the Endpoint service several times, restarted Agent, and rebooted the host. No change.
• Other security software: no third-party AV/EDR or audit services running.

OS identification test (still in place)

To test whether the unrecognized OS causes the rejection, we changed /usr/lib/os-release (ID, NAME, VERSION_ID, VERSION, PRETTY_NAME) and replaced /etc/lsb-release with Mint's upstream Ubuntu 24.04 copy. Agent picked up the change: Fleet now shows the platform as ubuntu. Endpoint still reports "Unknown Distribution 22.3" after restarts and a reboot, so it apparently identifies the OS from another source. The originals are backed up as .mint-backup files.

Questions

1. Is Linux Mint expected to work with Elastic Defend, and does an "Unknown Distribution" result cause Endpoint to refuse the Agent connection?
2. If OS detection is the cause, where does Endpoint read its distribution info, and is there a supported workaround?
3. If it isn't, what else would make Endpoint drop the stage 1 connection right after validating the Agent?
4. Is a DEB-installed agent supported for Security Onion endpoints, or should we retry the Security Onion installer, and if so, how should we troubleshoot its failure?

Diagnostics bundles from both Endpoint (elastic-endpoint diagnostics) and Agent (Fleet) are available on request.

Guidelines

• I have read the discussion guidelines at Read before posting! #1720 and assert that I have followed the guidelines.

[reyesj2]

I don't see linux mint listed on the support matrix for elastic defend https://www.elastic.co/support/matrix#matrix_os&#elastic-defend

[unwind126]

Thank you, @reyesj2 I'll take a look.

[dougburks]

Also note that Security Onion 2.4 has reached End Of Life. Please upgrade to Security Onion 3.
https://docs.securityonion.net/en/3/main/eol/
https://blog.securityonion.net/2026/04/6-month-eol-notice-for-security-onion-24.html

[unwind126]

Thank you, @dougburks I'll check this out.