MerlinAU MerlinAU v1.1.2 - The Ultimate Firmware Auto-Updater (Now available in AMTM)

[ExtremeFiretop]

I am wondering what failsafes are in place if the router crashes during a automated update? I saw @RMerlin mentioned the dual partition failsafe, but are there any other concerns that may need to be addressed before users consider using this script?

The same risks and safeties are in play as a regular firmware update once the update has actually started.
Memory management is handled with the script itself. Incase it detects it's getting low on RAM pre-flash in the preparation steps, so it's unlikely to have any issues pre-flash.

Friendly reminder the flash is using the same process with the same safeguards you and I use when we flash through the WebUI.

If it somehow crashed through the flash, it would of been a fairly large failure of the firmware itself, not of the script.
Same recovery steps would apply in either case of either 1. Factory resetting or 2. Using the ASUS recovery tool to do a Rescue Mode restore.

Again, in my months of developing this, the worst that's ever happened to me is the flash didn't start at the WebUI stage and was rejected and refreshed the page or logged out.
But again, to be safe we always recommend setting up BACKUPMON beforehand.

 

[ExtremeFiretop]

Already asked this in my post as well...

What about updating AiMesh nodes from the router as one does now manually?

Correct it doesn't need to be in router mode.

Sorry guys I actually answered this one up above (I thought) Maybe it was hidden up in the other answer.
If I didn't let me know how I can clarify.

Thanks!

 

[SomeWhereOverTheRainBow]

Sorry guys I actually answered this one up above (I thought) Maybe it was hidden up in the other answer.
If I didn't let me know how I can clarify.

Thanks!

So, essentially there is no way to program your script to use the firmware update API to also update nodes when updates for those are available? Sorry, i am just asking so I have full perspective. Basically, will your script be able to upgrade all children nodes from the parent node, or do I need to install it on each node.

 

[visortgw]

Currently, one uses the router GUI to initiate pushing updates to AiMesh nodes. I was asking if AiMesh nodes will be able to be version checked and updated via one instance of MerlinAu on the router as opposed to installing MerlinAu and its dependencies on each and every node.

 

[ExtremeFiretop]

Ah! Understood!

Sorry for the confusion.

Currently with the current implementation you need MerlinAU on each node you want updated. It won't check or care about other nodes on the network other than it's own that it runs on.

 

[SomeWhereOverTheRainBow]

Ah! Understood!

Sorry for the confusion.

Currently with the current implementation you need MerlinAU on each node you want updated. It won't check or care about other notes on the network other than it's own that it runs on.

Thank you, that answers it for me. Would you be able to implement a feature at somepoint to update children nodes from the parent, if and only if they are on stock asus firmware at some point in time?

 

[visortgw]

Thank you, that answers it for me. Would you be able to implement a feature at somepoint to update children nodes from the parent, if and only if they are on stock asus firmware at some point in time?

Why would they need to be on stock firmware? You initiate a manual update of AiMesh nodes now from the parent.

 

[ExtremeFiretop]

Thank you, that answers it for me. Would you be able to implement a feature at somepoint to update children nodes from the parent, if and only if they are on stock asus firmware at some point in time?

I'm not well versed in the API and would need to investigate this API more.

What I can say for sure is as of right now there's no plans to implement a check for child nodes from the parent node.

And there's no plans to ever support official Asus firmware because they already have their own auto-update process.

So it's unlikely to ever update child stock Asus nodes. However there is a potential to at least check them maybe someday for versioning and advise. Will need to investigate this path.

Always open to contributions if you guys have ideas!

 

[nlurker]

I haven't studied your auto-update tool, but my immediate question is this:

Whenever I see there is a firmware update available, the most important first step is to read and understand the release notes / change log. I would never update the firmware without first checking for potential problems or recommended steps before or after the update, or whatever wisdom is contained therein. Does your tool enable or allow this important step before the update?

 

[ExtremeFiretop]

I haven't studied your auto-update tool, but my immediate question is this:

Whenever I see there is a firmware update available, the most important first step is to read and understand the release notes / change log. I would never update the firmware without first checking for potential problems or recommended steps before or after the update, or whatever wisdom is contained therein. Does your tool enable or allow this important step before the update?

So this is the question I was waiting for someone to ask, so you get 5 stars.

No, currently there is no pre-check for info in the changelog. So if your running this blindly, you may be caught off guard if a setting or feature changes without word or if there's a required factory reset for example.

This is the part where I don't get to take away all of the fun of visiting SNB If you care at all you'll still be checking the change logs yourself and be aware of upcoming updates, but you no longer need to stay up until 3AM yourself to do it.

That being said, in the previous thread I started we suggested potentially teaming up with @RMerlin so he could maybe do a handshake deal to follow a standard format in the changelog for me to scrap and check for keywords.

He has always expressed disinterest in this as this increases his workload and I understand.

So the alternative I thought of is I can just script a Killswitch myself for all instances of the script and handle it myself.

Basically what I mean is I'd script a method for me to block out any specific update from auto-updating. And I myself in the beta stages of the firmware and release stage would check the change logs and if I see any notes about factory resets or large feature changes to simply add the release to the block list to all devices.

The logic would essentially be to check the remote blacklist (likely on my GitHub) before any update to validate the version it's updating too is not there, and keep an updated list myself.

 

[nlurker]

So this is the question I was waiting for someone to ask, so you get 5 stars.

No, currently there is no pre-check for info in the changelog. So if your running this blindly, you may be caught off guard if a setting or feature changes without word or if there's a required factory reset for example.

This is the part where I don't get to take away all of the fun of visiting SNB If you care at all you'll still be checking the change logs yourself and be aware of upcoming updates, but you no longer need to stay up until 3AM yourself to do it.

That being said, in the previous thread I started we suggested potentially teaming up with @RMerlin so he could maybe do a handshake deal to follow a standard format in the changelog for me to scrap and check for keywords.

He has always expressed disinterest in this as this increases his workload and I understand.

So the alternative I thought of is I can just script a Killswitch myself for all instances of the script and handle it myself.

Basically what I mean is I'd script a method for me to block out any specific update from auto-updating. And I myself in the beta stages of the firmware and release stage would check the change logs and if I see any notes about factory resets or large feature changes to simply add the release to the block list to all devices.

The logic would essentially be to check the remote blacklist (likely on my GitHub) before any update to validate the version it's updating too is not there, and keep an updated list myself.

Thank you for your thoughtful response. I don't think it has to be that complicated. Simpler would be an option to display the changelog when there is an update available. Also an option to require the user to APPROVE an update before the auto-update can occur.

 

[ExtremeFiretop]

Thank you for your thoughtful response. I don't think it has to be that complicated. Simpler would be an option to display the changelog when there is an update available. Also an option to require the user to APPROVE an update before the auto-update can occur.

I'm currently thinking of a hybrid of the two.
The blacklist isn't really a Killswitch as much as a warning list.

If I add the firmware to the list, it would force you to read the change log and hit I accept before flashing.

 

[Ranger802004]

Correct to a point, for example below:
We are currently on 388.6 as the production release. Therefore if I go to beta of 388.6 it will detect a newer release but not be satisfied enough with the version difference to actually try to update as seen below:

View attachment 55862

However, if I go all the way back to 388.5 beta 1. Then not only does it detect a different firmware available but it satisfies the difference in version required to update and therefore will allow it to update.

View attachment 55863

Basically this means that if your on a beta, your safe until the next major release. If somehow your still on beta1 388.5 by the time the major release of 388.6 comes around, then it will force update you to the next major release.


Correct it doesn't need to be in router mode.



Happy you found it!



As you'll notice from the screenshot above, it was a double test, 2 birds with 1 stone, I get to demo to you what happens when I configure it exactly like you did.
In the screenshot above on beta1 of 388.5. You'll see I configured every Friday at midnight and a 1 day delay.

When I try and run the script manually the delay is invoked. However the next time it will run would be at the end of the week, at which point the 1 day delay is obviously passed and the update will go through.
That's why we selected the wording we did around the cron job here:

View attachment 55865

The cron schedule isn't just how often the script checks, it's how often the script runs at all, if you make it run only once a week it will wait a week before checking again, if you wanted it to happen exactly on that Friday at that 5:15AM, you would need a zero delay, else it would actually be the next Friday at 5:15AM.
Hope that explains in detail.

You have to build in logic for how you detect update versions to say -beta in the version name is older than the same firmware version if they are numerically the same.

 

[nlurker]

I'm currently thinking of a hybrid of the two.
The blacklist isn't really a Killswitch as much as a warning list.

If I add the firmware to the list, it would force you to read the change log and hit I accept before flashing.

That sounds like a good idea too. But remember that any design that requires manual intervention by you for every release is not sustainable. You may be unavailable or lose interest.

 

[ExtremeFiretop]

You have to build in logic for how you detect update versions to say -beta in the version name is older than the same firmware version if they are numerically the same.

Correct, this was a design choice at the time since if you flashed a beta your likely handling the updates manually for the version for some reason, due to testing, etc.

It gives you the entire beta and release cycle of that version to stay on the beta before it forces an update to the next release cycle.

 

[Ranger802004]

Correct, this was a design choice at the time since if you flashed a beta your likely handling the updates manually for the version for some reason, due to test, etc.

It gives you the entire beta and release cycle of that version to stay on the beta before it forces an update to the next release cycle.

That's flawed logic though, what if the production release has something resolved from the beta cycle? You're basically saying because they were part of the same release cycle they're the same firmware so let's not update which is not true.

 

[ExtremeFiretop]

That sounds like a good idea too. But remember that any design that requires manual intervention by you for every release is not sustainable. You may be unavailable or lose interest.

The only other alternative is just build an option to approve every release or ideally get RMerlin to agree to standardized wording for specific changes for me to find with the script.

I could also wing it with a collection of words that are considered high risk and ask for approval. But with that there's no guarantee it catches it if RMerlin decides to spice it up and talk with an accent in his writing one day.

 

[ExtremeFiretop]

That's flawed logic though, what if the production release has something resolved from the beta cycle? You're basically saying because they were part of the same release cycle they're the same firmware so let's not update which is not true.

I understand your point and I'm not disagreeing I'm just saying that's how it currently works and it was an initial design choice done by us.

There is value to updating to a stable release of the same cycle and I'm not arguing that point.

My only thought was if you handled any manual flash for that cycle, that we would stay out of it for that cycle until it returned to a production release. Else it waits a full cycle if you fall too far behind.

I'll discuss this point with Martinski and see we can make this maybe a configuration option if it detects a beta release installed instead.

 

[Ranger802004]

I understand your point and I'm not disagreeing I'm just saying that's how it currently works and it was an initial design choice done by us.

There is value to updating to a stable release of the same cycle and I'm not arguing that point.

My only thought was if you handled any manual flash for that cycle, that we would stay out of it for that cycle until it returned to a production release. Else it waits a full cycle if you fall too far behind.

I'll discuss this point with Martinski and see we can make this maybe a configuration option if it detects a beta release installed instead.

A configuration option probably would be a good idea with a default state as disabled. A user then can elect for those update cycles.

 

[ExtremeFiretop]

A configuration option probably would be a good idea with a default state as disabled. A user then can elect for those update cycles.

I give out 5 stars to this point as well.

Thanks again, I'll update the thread once we have updates to provide on the choice relating beta to production flashes of the same cycle, and also relating to the change logs.