What's new

amtm amtm 6.5 - the Asuswrt-Merlin Terminal Menu, March 29, 2026

We seem to all naturally expect "u" is only used to check for updates (as I explained previously above).

Many people seem to have missed that step, I'm not trying to single you out in anyway, but without doing it twice, then the amtmUpdateScripts file does not get generated as expected.

You’re correct, while it’s documented by TLC, it does not feel intuitive to do it twice.

I’d almost say just let amtm do the check internally on the first u or have a periodic check every time you enter amtm or use a different check code for scripts that support auto update in amtm e.g. “cfstsauiamtm” (just kidding).

btw… if amtm does the auto updates, what does the in-script (in MerlinAU e.g.) actually do, just run independently anyway on a cron (duplicate amtm au?) i.e. is it redundant, additive or you put so much work into it’s hard for you to say goodbye to it ?
 
btw… if amtm does the auto updates, what does the in-script (in MerlinAU e.g.) actually do, just run independently anyway on a cron (duplicate amtm au?) i.e. is it redundant, additive or you put so much work into it’s hard for you to say goodbye to it ?

I've already brought this up to thelonelycoder.
That some of us devs have already put time into developing our own "auto update" functionality. Including himself with diversion.

For now though, AMTM is not a true auto update. It's simply a method for AMTM to offer to update add-ons from the "u" screen.
Now when updates are available in the future, instead of only advising you, and having to go into each add-on to update, AMTM can instead offer to update the add-ons for you, without you having to load each add-on and run their own update function.

This is a quality of life feature that will greatly improve situations when multiple add-ons have updates.
The user can simply select "u" from AMTM, it will find updates and offer to install them for you.

If it ever gets its own cron job then it will become a true auto-update feature.
And at that point I'll have to reflect and consider what to do with MerlinAU. For now though they don't clash and are 2 separate features.
 
Last edited:
I've already brought this up to thelonelycoder. That some of us devs have already put time into developing our own "auto update" functionality. Including himself with diversion.

For now though, AMTM is not a true auto update. It's simply a method for AMTM to offer to update add-ons from the "u" screen.

Now when updates are available in the future, instead of only advising you, and having to go into each add-on to update, AMTM can Instead offer to update the add-ons for you, without you having to load each add-on and run their own update function.

This is a quality of life feature that will greatly improve situations when multiple add-ons have updates. The user can simply select "u" from AMTM, it will find updates and offer to install them for you.

If it ever gets its own cron job then it will become a true auto-update feature. And at that point I'll have to reflect and consider what to do with MerlinAU. For now though they don't clash and are 2 separate features.
Coolio, appreciate the explanation. Just a query, does the in-script au have to be enabled for the amtm au to work or are they independent? Asking as I disabled it on 6 routers…
 
Coolio, appreciate the explanation. Just a query, does the in-script au have to be enabled for the amtm au to work or are they independent? Asking as I disabled it on 6 routers…

If the in-script AU is enabled, AMTM updates will be disabled. If you disable the in-script AU, then AMTM updates becomes available.
Whenever you change the in-script option, you must again run "u" from AMTM so the "au" screen reflects those changes. (For now)
 
Last edited:
If the in-script AU is enabled, AMTM updates will be disabled. If you disable the in-script AU, then AMTM updates becomes available.

Whenever you change the in-script option, you must again run "u" from AMTM so the "au" screen reflects that changes. (For now)
Aha ! So they are related… now my convoluted steps all makes sense… I just arrived at it by dumb luck … too much poking around enabling and disabling stuff. What a eureka moment. Cheers.👍, thanks.
 
Last edited:
Aha ! So they are related… now my convoluted steps all makes sense… I just arrived at it by dumb luck … too much poking around enablung and disabling stuff. What a eureka moment. Cheers.👍, thanks.

They are related for sure, but separate features in functionality, I could of been more clear about that.
One is fully auto-updates from within MerlinAU, and the other is "streamlined" manual updates from AMTM.

We disable those streamlined amtm updates only if MerlinAU is handling it's own updates with it's built-in cron job / AU feature.
 
Last edited:
Separate Topic: Shell History in amtm

On my RPi4 the shell history seems to be just that, a history of commands I either type or paste into the command shell.

On the router, I cannot for the life of me work out what it’s remembering. I scroll back using the up/down arrow keys on my iPad (iTerminal) and stuff I could have sworn I copy pasted recently just doesn’t come up; yet there are reams of lines of commands that I swore I never typed, that actually do come up.

I looked at amtm, shell history, manage to see if there were any options like “just remember what I typed or pasted” but there isn’t. I looked at the history file too.

Is there something I’m doing wrong here or is it actually doing something I should expect but don’t know about ?

[EDIT] It seems within a SSH session it remembers the history better than if you exit SSH and go back in again ?
 
Last edited:
btw… if amtm does the auto updates, what does the in-script (in MerlinAU e.g.) actually do, just run independently anyway on a cron (duplicate amtm au?) i.e. is it redundant, additive or you put so much work into it’s hard for you to say goodbye to it ?

Keep in mind that MerlinAU has to handle and manage 2 types of automatic updates:
1) Automatic F/W Updates
2) Automatic Script Updates


This means that the built-in "Automatic Script Updates" in MerlinAU is a bit more nuanced than the usual script update because we also have the "Automatic F/W Updates" to consider, and therefore, we must be very careful not to run both updates too close together to avoid "stepping on each other's toes."

So, to remove any possible scheduling conflicts between the two Automatic Updates, MerlinAU clearly and explicitly prevents users from setting up a separate cron job schedule for the "Automatic Script Updates." Instead, it takes the existing cron job schedule already configured for the "Automatic F/W Updates" and automatically schedules the "Script Updates" to happen 15 minutes *before*. This way, we avoid cron scheduling conflicts and any possible runtime issues between the two Automatic Updates by removing human errors from the equation.

Now, in the event that AMTM includes the option to set up its own cron job schedule to perform fully automated script updates, there is a possible scenario where a user may inadvertently schedule the AMTM script updates to happen either at the same time or very close to when the MerlinAU "Automatic F/W Updates" are scheduled to occur.

If that happens, there is a chance that the Automatic F/W Update and the eventual reboot of the router may leave some script update(s) in a *corrupted* state because the process was interrupted as "the rug was pulled out from under their feet."

The above scenario might be rare and unusual, but the chances are not ZERO, so to prevent it from happening, I've already implemented in MerlinAU a mutually exclusive, non-blocking FLOCK mechanism so that at some point, AMTM can check if the Lock is already taken *before* proceeding to start its automatic script updates. And, in the reverse scenario, MerlinAU also checks the Lock *before* starting the F/W Updates.

In short, the goal is to keep one update process from interrupting the other.
 
In short, the goal is to keep one update process from interrupting the other.
Thank you for taking the time to elaborate on the various update checks, there’s certainly a lot going on under the hood.

I did wonder about there being two auto update options within MerlinAU, for the two processes you highlighted, the FW and the script and what happens when amtm au takes over the script one.

You’ve clarified this nicely. I do recall the previous discussion about various crons not stepping on each other’s toes. Thanks once again 🙏.
 
Last edited:
Hey there!

Available amtm script updates:
- amtm 6.4 ->

Very truly yours,
Your GT-AX6000 router (Model type GT-AX6000)

Got this email about 8 hours ago, never had this error of a "ghost update" notification?

How amtm is looking:

CleanShot 2026-03-27 at 13.07.43@2x.png
 
amtm 6.5 is now available
  • Rewrote logic and wording in au Automatic scripts update feature due to the confusing nature of how it interacts with third-party scripts. Opening au now also refreshes the supported scripts.
  • Adds support for us Unbound Stats for Asuswrt-Merlin by juched78. Finally, this hidden Unbound addon has been made amtm compatible. Thanks to @Martinski for the extra effort!
  • Again, this update is only available for the firmware built in version of amtm.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top