starred/tacticalrmm

Fork 0

mirror of https://github.com/amidaware/tacticalrmm.git synced 2026-04-26 15:05:57 +03:00

[GH-ISSUE #1265] Agent fails to update due to invalid arch #2728

New issue

Closed

opened 2026-03-14 05:18:01 +03:00 by kerem · 4 comments

kerem commented

2026-03-14 05:18:01 +03:00

Owner

Originally created by @NiceGuyIT on GitHub (Aug 25, 2022).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1265

Server Info (please complete the following information):

OS: Ubuntu 20.04.4 LTS
Browser: Firefox 103.0.2 (64-bit)
RMM Version (as shown in top left of web UI): v0.14.5

Installation Method:

Standard
Docker

Agent Info (please complete the following information):

Agent version (as shown in the 'Summary' tab of the agent from web UI): Agent v1.8.0
Agent OS: [Windows 10 Pro, 64 bit v21H2 (build 19044.1889)

Describe the bug
Three agents are failing to update from v1.8.0. The logs show the following URL returns 404. This is because the arch is the PC name with a "-5" number appended.

xh --headers "https://agents.tacticalrmm.com/api/v2/agents?version=2.2.1&arch=PC-Files10-5&token=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee&plat=windows&api=api.smb.services"

As best I can tell, this is coming from the server. Checking the database confirms these 3 computers have the hostname in the goarch field.

tacticalrmm=# select id, version, hostname, plat, goarch
from agents_agent
where goarch != 'amd64' limit 10;
 id | version |    hostname    |  plat   |      goarch      
----+---------+----------------+---------+------------------
  6 | 1.8.0   | PC-Accounting2 | windows | PC-Accounting2-6
 15 | 1.8.0   | PC-Extra01     | windows | PC-Extra01-15
  5 | 1.8.0   | PC-Files10     | windows | PC-Files10-5
(3 rows)

To Reproduce
Steps to reproduce the behavior:

Unknown.

Expected behavior
I expect agents to be able to update regardless of how old they are.

Screenshots
N/A

Additional context
I did not see where this specific issue was logged or discussed. This bug report is mostly for visibility. Updating the database will cause the auto-update to work, but how many assets (people) have invalid information in the database? Was the root cause of this data corruption fixed?

Originally created by @NiceGuyIT on GitHub (Aug 25, 2022). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/1265 **Server Info (please complete the following information):** - OS: Ubuntu 20.04.4 LTS - Browser: Firefox 103.0.2 (64-bit) - RMM Version (as shown in top left of web UI): v0.14.5 **Installation Method:** - [x] Standard - [ ] Docker **Agent Info (please complete the following information):** - Agent version (as shown in the 'Summary' tab of the agent from web UI): Agent v1.8.0 - Agent OS: [Windows 10 Pro, 64 bit v21H2 (build 19044.1889) **Describe the bug** Three agents are failing to update from v1.8.0. The logs show the following URL returns 404. This is because the arch is the PC name with a "-5" number appended. ```bash xh --headers "https://agents.tacticalrmm.com/api/v2/agents?version=2.2.1&arch=PC-Files10-5&token=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee&plat=windows&api=api.smb.services" ``` As best I can tell, this is coming from the server. Checking the database confirms these 3 computers have the hostname in the goarch field. ```text tacticalrmm=# select id, version, hostname, plat, goarch from agents_agent where goarch != 'amd64' limit 10; id | version | hostname | plat | goarch ----+---------+----------------+---------+------------------ 6 | 1.8.0 | PC-Accounting2 | windows | PC-Accounting2-6 15 | 1.8.0 | PC-Extra01 | windows | PC-Extra01-15 5 | 1.8.0 | PC-Files10 | windows | PC-Files10-5 (3 rows) ``` **To Reproduce** Steps to reproduce the behavior: 1. Unknown. **Expected behavior** I expect agents to be able to update regardless of how old they are. **Screenshots** N/A **Additional context** I did not see where this specific issue was logged or discussed. This bug report is mostly for visibility. Updating the database will cause the auto-update to work, but how many assets (people) have invalid information in the database? Was the root cause of this data corruption fixed?

kerem closed this issue

2026-03-14 05:18:06 +03:00

kerem commented

2026-03-14 05:18:12 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Aug 25, 2022):

This will use the API to identify agents that have invalid data.

First, create a .env file with the API key and domain.

cat .env
# API
TRMM_API_KEY=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
TRMM_API_DOMAIN=api.smb.services

This requires HTTPie and jq to be installed. It will output the client, site, hostname and arch of any agent that is not amd64.

export $(grep -vE "^(#.*|\s*)$" .env)
agents=$(http "https://${TRMM_API_DOMAIN}/agents/?detail=false" "X-API-KEY:${TRMM_API_KEY}" | jq --raw-output '.[] | .agent_id')
for agent in $agents; do http "https://${TRMM_API_DOMAIN}/agents/${agent}/" "X-API-KEY:${TRMM_API_KEY}" | jq --raw-output '[ .client, .site_name, .version, .hostname, .goarch ] | @csv'; done | grep -v '"amd64"$'

@NiceGuyIT commented on GitHub (Aug 25, 2022): This will use the API to identify agents that have invalid data. First, create a `.env` file with the API key and domain. ```bash cat .env # API TRMM_API_KEY=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa TRMM_API_DOMAIN=api.smb.services ``` This requires HTTPie and jq to be installed. It will output the client, site, hostname and arch of any agent that is not `amd64`. ```bash export $(grep -vE "^(#.*|\s*)$" .env) agents=$(http "https://${TRMM_API_DOMAIN}/agents/?detail=false" "X-API-KEY:${TRMM_API_KEY}" | jq --raw-output '.[] | .agent_id') for agent in $agents; do http "https://${TRMM_API_DOMAIN}/agents/${agent}/" "X-API-KEY:${TRMM_API_KEY}" | jq --raw-output '[ .client, .site_name, .version, .hostname, .goarch ] | @csv'; done | grep -v '"amd64"$' ```

kerem commented

2026-03-14 05:18:17 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Aug 25, 2022):

Running the installer to update the agent fixed the corruption.

Recover the agent did not fix the corruption. Is there any way to force the refresh of the agent data? Clicking all the refresh buttons in the GUI doesn't update the goarch. Is there an agent command I can run to force the metadata update? I'm wondering if this is specific to the agent (metadata will update to the same invalid data) or the server (metadata will update with correct data).

@NiceGuyIT commented on GitHub (Aug 25, 2022): Running the installer to update the agent fixed the corruption. Recover the agent did not fix the corruption. Is there any way to force the refresh of the agent data? Clicking all the refresh buttons in the GUI doesn't update the goarch. Is there an agent command I can run to force the metadata update? I'm wondering if this is specific to the agent (metadata will update to the same invalid data) or the server (metadata will update with correct data).

kerem commented

2026-03-14 05:18:22 +03:00

Author

Owner

@wh1te909 commented on GitHub (Aug 25, 2022):

the arch to goarch transition was a breaking change, there was a database migration to handle this a while back but if the agents are still on 1.8.0 then that is waaay too old (released back in Jan) and you'll need to manually update them. Until trmm reaches 1.0 you should expect breaking changes and always make sure agents are on latest version before upgrading trmm otherwise stuff like this can happen.

@wh1te909 commented on GitHub (Aug 25, 2022): the `arch` to `goarch` transition was a breaking change, there was a database migration to handle this a while back but if the agents are still on 1.8.0 then that is waaay too old (released back in Jan) and you'll need to manually update them. Until trmm reaches 1.0 you should expect breaking changes and always make sure agents are on latest version before upgrading trmm otherwise stuff like this can happen.

kerem commented

2026-03-14 05:18:28 +03:00

Author

Owner

@NiceGuyIT commented on GitHub (Aug 25, 2022):

The oldest agent using the URL above is v2.1.0 and it fixes the data corruption when it updates.

@NiceGuyIT commented on GitHub (Aug 25, 2022): The oldest agent using the URL above is v2.1.0 and it fixes the data corruption when it updates.