ZLinux (s390x) - BigFix Inventory "Invalid Archiver" error / Software Scan Failing with Path Mismatch

1

Hi everyone,

We are running into a persistent "Invalid Archiver" error across a large environment of RedHat 7 ZLinux (s390x architecture) servers running the BigFix Client. We recently attempted an upgrade to BigFix Inventory (BFI) 11.0.6.0 to resolve it, but the software scans are still failing.

After digging into the client logs, we noticed a strange behavior where the action script appears to evaluate Windows-specific parameters and backslashes on a Linux endpoint.

I would appreciate any insights, tips, or configuration tweaks from anyone who has managed BFI on s390x hardware! Here are the details of what we are seeing:

Environment Info

  • Target OS: RedHat Enterprise Linux 7 (s390x architecture)

  • BigFix Client Version: 11.0.3.82

  • BigFix Inventory Version: Upgrade targeted to 11.0.6.0

  • Site / Fixlet: Initiate Software Scan (11.0.6.0)

Key Error Points

  1. Path Syntax Evaluation Mismatch: The primary error points to the client attempting to process a path meant for a Windows machine. The log indicates that the parameter bfs_exe is being populated with backslashes (\) and a .exe extension, causing the binary execution on Linux to fail instantly.

  2. Action Script Termination: Because the agent fails to properly resolve or execute the pathing configuration, the action drops with a script failure.

  3. Downstream Archiver Failure: Because the core scanner binary never launches or completes successfully, the downstream archiver tool has nothing to bundle up, throwing the generic "Invalid Archiver" status back to the console.

Relevant Log Snippets (Sanitized)

Here is what the besclient log captures at the exact moment the scan action executes:

Plaintext

Current Date: June 11, 2026
Client version 11.0.3.82 built for RedHat 7 s390x running on Linux release:4.18.0-... arch:s390x

ActionLogMessage: (action:579150277) Action signature verified for Execution
ActionLogMessage: (action:579150277) starting action
actionsite (...)
Command succeeded parameter "sourceReleaseDate" = "2024-09-30" (action:579150277)
Command succeeded parameter "citset" = "available" (action:579150277)
Command succeeded parameter "citscanprovider" = "provider_cache2" (action:579150277)
Command succeeded parameter "cit_version" = "11.0.41.0" (action:579150277)
Command succeeded parameter "clientroot" = "/var/opt/BESClient" (action:579150277)

[!! CRITICAL PATH MISMATCH HERE !!]
Command succeeded parameter "bfs_exe" = "/var/opt/BESClient\tools\scanner\bin\bf-scanner.exe" (action:579150277)

Command succeeded setting "CIT_Empty_Cache_After_Scan"="true" ... (action:579150277)
Command succeeded setting "CIT_Scan_Provider"="provider_cache2" ... (action:579150277)
Command succeeded parameter "newScanMode" = "provider_cache2" (action:579150277)

[!! ACTION FAILS HERE !!]
Command failed (parameter add exists) parameter "clientroot" = "/var/opt/BESClient" (action:579150277)
ActionLogMessage: (action:579150277) ending action

What We Have Tried So Far:

  • Cleared the Global Downloads Cache and the BFI Site Downloads Cache via script.

  • Confirmed we are targeting the out-of-the-box, unmodified Initiate Software Scan (11.0.6.0) Fixlet (Source Release Date: 2025-12-16).

Despite using the clean out-of-the-box Fixlet, the endpoint seems to keep pulling down or evaluating parameters that look like they belong on a Windows architecture, or it's throwing a parameter add exists on the standard relevance paths.

Has anyone seen this behavior specifically on zLinux / s390x systems? Any guidance on why the agent might parse or hang onto these incorrect path separators would be a lifesaver.

Thanks in advance!