1. Automox
  2. Configuring Automox
  3. Agent Installation & Setup

Agent Install Failure on SUSE Linux

Avatar
Jordan
Updated:

Automox agent installations on SUSE fail in a few distinct ways, and the right fix depends on which error you are seeing. Identify your error below and follow that section.

Signature verification failed / package payload is not signed

Error messaging

Package payload is not signed!
amagent-x.x.xx-1.x86_64 (Plain RPM files cache): Signature verification failed [6-File is unsigned]

This is the most frequently reported SUSE installation failure.

Cause

SUSE requires RPM packages to be signed by default. When the installation is run using the piped command from the console, the package is downloaded into a temporary location and presented to zypper as a plain RPM file, which is rejected by that signature requirement.

Resolution

Install using the package downloaded directly from the console rather than the piped command:

  1. In the console, go to Devices and select Add Devices.
  2. Select Manual Installation.
  3. Choose the 64-bit SUSE package and download it to the device.
  4. Install the downloaded package on the device.

Refreshing the repositories with zypper refresh does not resolve this error, so there is no need to work through repository configuration first. For the full manual download process, see Downloading the Package for a Linux Installation with Automox.

Nothing provides 'initscripts'

Error messaging

Problem: nothing provides 'initscripts' needed by the to be installed amagent-x.x.xx-1.x86_64
 Solution 1: do not install amagent-x.x.xx-1.x86_64
 Solution 2: break amagent-x.x.xx-1.x86_64 by ignoring some of its dependencies

Cause and resolution

This dependency error affects older agent and SUSE combinations. On current SUSE Linux Enterprise 15 releases the initscripts package is not available at all, because those releases use systemd. Attempting to install it returns a message that initscripts is not found in package names and that no provider exists, so this is a dead end on modern SUSE.

If you encounter this error:

  1. Confirm you are installing a current agent version rather than an older package that was saved locally.
  2. Refresh the repositories with sudo zypper refresh.
  3. Install using the manually downloaded package from Add Devices > Manual Installation, as described in the previous section.

Do not use the option to install while ignoring dependencies.

Installation completes but the agent service does not stay running

Error messaging

IO error: While lock file: /var/lib/amagent/osquery.db/LOCK: Resource temporarily unavailable

In this case the package installs successfully and the failure happens at runtime. Checking the service shows it inactive, or active with these errors repeating in the journal.

Cause

The osquery component the agent relies on cannot open its database because another process is holding the lock, or a previous instance exited and left a stale lock file behind.

Resolution

On a fresh installation, clear the lingering processes and local database, then start the service again.

  1. Stop any lingering agent or osquery processes. It is expected that some of these report no process found.

    sudo killall -9 amagent
sudo killall -9 osqueryi
sudo killall -9 osqueryd

  2. Remove the local agent database files. Only do this on a fresh installation, where there is no local data to preserve.

    sudo rm -rf /var/lib/amagent/osquery.db
sudo rm -rf /var/lib/amagent/amagent.db
sudo rm -rf /var/lib/amagent/amagent-bbolt.db

  3. Confirm the access key is set, replacing ACCESS_KEY with your key.

    sudo /opt/amagent/amagent --setkey ACCESS_KEY

  4. Enable and start the service, then confirm it stays running.

    sudo systemctl enable amagent
sudo systemctl start amagent
sudo systemctl status amagent

If the lock errors return

If these errors reappear after cleanup, something on the device is repeatedly starting osquery processes. Check for a separate system-native osquery installation, which can conflict with the copy the agent manages:

systemctl status osqueryd

Then confirm what currently holds the lock and whether a scheduled task is involved:

sudo ps aux | egrep 'amagent|osquery' | grep -v egrep
sudo lsof /var/lib/amagent/osquery.db/LOCK
sudo systemctl list-timers --all | grep -E 'amagent|osquery'

Multiple osqueryd or osqueryi processes, or more than one amagent, indicate the source of the conflict. Custom system images with preinstalled software are worth checking here, since a bundled osquery is a common contributor.

Notes

  • The message target sqlite DB not found. Skipping migration in the installation output is normal on a fresh installation and can be ignored. It indicates there was no existing database to upgrade.
  • For the supported SUSE releases and Linux prerequisites, see Linux: Recommendations, Requirements, and FAQs.

Related articles

Articles in this section

See more
Was this article helpful?
0 out of 0 found this helpful