Understanding SEPM Linux Package Behavior and LinuxInstaller Stub Version Discrepancies

Products

• Endpoint Protection

Issue/Introduction

This article addresses whether the apparent "downgrade" of the LinuxInstaller stub from v1.1.29 to v1.1.28 was an intentional architectural change, and whether utilizing existing v1.1.29 stubs against a v1.1.28 repository poses any operational or compatibility risks.

Environment

SEP Agent 143 RU9 +

Resolution

1. SEPM Package Deletion Behavior

By design, SEPM does not allow the deletion of the latest available package for a specific operating system platform. For the newest available Linux package in the console, the option to remove it is restricted. Older packages (such as 14.3.9557.9100) can be removed as needed once a newer build is present in the environment.

2. The LinuxInstaller Stub Version Discrepancy (v1.1.29 vs v1.1.28)

Intent behind the version shift: The rollback to version 1.1.28 was not intentional. It occurred as an unintended side effect of the automated packaging pipeline during a recent RHEL 10 / OEL 10 platform enablement release. During the update, the pipeline's republication routine mistakenly fetched a cached, pre-built binary artifact at version 1.1.28. The core source code on the active SAL 1.4 branch remains at version 1.1.29. The engineering team is currently correcting the automated republication process to restore version 1.1.29 across all delivery channels.

Compatibility and Operational Risk: There are zero compatibility risks. Administrators can safely continue using existing v1.1.29 installer stubs. Architecturally, the LinuxInstaller file serves exclusively as a self-extracting stub wrapper.

The version string displayed via the ./LinuxInstaller --version flag is a compile-time constant used solely for cosmetic and identification purposes. It plays no role in repository communication, package resolution, or endpoint enrollment. Because the underlying core scripts, repositories, and payloads are identical, executing either version 1.1.28 or 1.1.29 will result in the exact same deployment outcome.