MerlinAU MerlinAU v1.2.6 - The Ultimate Firmware Auto-Updater (**Thread closed due to age**)

[ExtremeFiretop]

I did look at that but you are right, I misread it, my apologies!

Yep.

Got it; all good. Was sort of thinking by extension from Beta to Release, if it went one way it would also do Alpha to Beta, but Q16 rules that out as you rightly point out. No worries.

No worries, the goal is to try and communicate as clearly as possible, but understand I am no technical writer, also French is my first language.
So if you know of any improvements feel free to suggest!

Really this part I think answers your question best:

"Ensuring that only stable firmware versions that have completed beta testing are automatically flashed onto your router.
This design choice prevents the automatic update to beta firmware, ensuring that your router maintains a stable and secure operation.
Users seeking to experiment with beta firmware must manually download and install these versions."

Now on the point of question 7, it really is all about priority and nothing else
We wanted people to understand that just because your on version 388.7 beta1, that the script knows you aren't already on "388.7" release version, and do nothing about it. 388.7 = 388.7?

The script has to prioritize, the official releases over the betas and alphas.
Hope that explains better in detail.

Thanks!

 

[jksmurf]

Hope that explains better in detail.

Actually I think this was probably more a case of me skim-reading the FAQ, rather than any explanation being missing or being unclear. Merci beaucoup .

I was just so excited about testing this out (on my local system) and I have another reason for that; your Web Server idea is a fantastic option for those of us silly enough to contemplate doing FW updates on remote devices, because it essentially changes it from a remote update, to a local one.

To date I have been using a VPN to update the firmware on a remote system 9000km away via the WebGUI (yup, totally silly), holding my breath and hoping it does not go TU. Your script and local Web Server / FW Backup gives me more confidence that this can be done essentially "locally", using the local USB drive etc. Hopefully I have not misunderstood this .

 

[ExtremeFiretop]

Actually I think this was probably more a case of me skim-reading the FAQ, rather than any explanation being missing or being unclear. Merci beaucoup .

I was just so excited about testing this out (on my local system) and I have another reason for that; your Web Server idea is a fantastic option for those of us silly enough to contemplate doing FW updates on remote devices, because it essentially changes it from a remote update, to a local one.

To date I have been using a VPN to update firmware remote system 9000km away via the WebGUI (yup, totally silly), holding my breath and hoping it does not go TU. Your script and local Web Server / FW Backup gives me more confidence that this can be done essentially "locally", using the local USB drive etc. Hopefully I have not misunderstood this

Totally fine!

I personally use this script to manage my families routers remotely as well as my "side gigs" router.
I know exactly the feeling your describing, as I too would start it remotely over RDP and just hold my breath once the network went down that it would come back up and everything went according to plan.

This is one of the many reasons, I believe this tool to be useful. It's a fantastic use-case as I know my co-developer Martinski would agree. (IIRC he also uses it to manage friends and family remotely.)
This tool not only takes the burden off your shoulders, but does it safely and reliably

We've always put a priority on safety when developing this, and on all the routers and all the firmware's we've put to the test at no point as this been an issue to date.
The idea is all you gotta do once this is installed is review the changelogs once in a while for new releases, and you can go to sleep and trust it will do its job overnight safety and correctly.

 

[maghuro]

 

[ExtremeFiretop]

Thanks for reporting. For now you can disable the changelog check.
My assumption is it's an issue with PR 164, since that was the last PR we touched it, will review and provide an update shortly.
Edit: identified the issue is with the log file itself.

We also are already aware of a bug with the node email notifications, which also stops the update as a cron, but it continues to work interactively.
The fix for this is currently a pending PR.

 

[maghuro]

Thanks for reporting. For now you can disable the changelog check.
My assumption is it's an issue with PR 164, will review and provide an update shortly.

We also are already aware of a bug with the node email notifications, which is currently a pending PR.

The situation only happens on the node.
On main router, it updated flawlessly

 

[ExtremeFiretop]

The situation only happens on the node.
On main router, it updated flawlessly

Okay, I see an issue but I'm not sure it's the same one you identified.
For some reason the older AC models firmware shipped out with the Changelog-NG.txt changelog file: https://www.asuswrt-merlin.net/changelog

Instead of the Changelog-386.txt changelog file: https://www.asuswrt-merlin.net/node/10 as expected from previous releases.

Maybe for now simply disable the changelog check. It's why we made it optional
I'd bring this up to @RMerlin to see if this was intentional or just an oversight.

 

[ExtremeFiretop]

The situation only happens on the node.
On main router, it updated flawlessly

Do you have the changelog check enabled on the primary router?

 

[maghuro]

Do you have the changelog check enabled on the primary router?

Yes, I do

 

[Diablo99]

I have the script enabled, it shows an update to 388.7.0 .
How to update within the script?
* I read the wiki, I must be blind

Edited: It worked, great script!

 

[ExtremeFiretop]

I have the script enabled, it shows an update to 388.7.0 .
How to update within the script?
* I read the wiki, I must be blind

Edited: It worked, great script!

Happy to hear it worked for you!

I plan to pump out a quick update today for people impacted by the mentioned bug.
The newer code for the "nodes" needed a little more bake time, but should be all ironed out by today

Thanks again!

 

[ExtremeFiretop]

Yes, I do

Hey maghuro,

Just to keep you updated I was able replicate your issue:

Investigating now. Can you provide the output of:

nvram get buildno

?

Also as a side note:
@RMerlin has resolved the issue with the changelogs: https://www.snbforums.com/threads/a...now-available-for-ac-models.89583/post-904431

(Thank you!)

 

[maghuro]

Hey maghuro,

Just to keep you updated I was able replicate your issue:

View attachment 58222

Investigating now. Can you provide the output of:

nvram get buildno

?

Also as a side note:
@RMerlin has resolved the issue with the changelogs: https://www.snbforums.com/threads/a...now-available-for-ac-models.89583/post-904431

(Thank you!)

I'm sorry I didn't answer you on time, but glad the issue has been detected and solved!

Thank you so much

 

[ExtremeFiretop]

I'm sorry I didn't answer you on time, but glad the issue has been detected and solved!

Thank you so much

No problem, I'm happy we are on track as well. The changelog in the archive answers that part of the behavior.

How it used to work was based on the buildno it would determine which changelog to use.
If your build number contained 386 then it was looking for the changelog-386.txt which was missing in your case/screenshots.

Naturally the primary router had no issues since it was a AX router and the changelog-NG was available in the zip file.
I still made a change to simplify the logic at that area, but I do think this answers the question as to why you saw that issue.

 

[ExtremeFiretop]

MerlinAU Version 1.1.2 released.

What's Changed/Fixed?:

PR: #197
Bug Fix for Node Email Notifications...

1. Even though the node has a name, the email says TBD
2. Able to trigger the email every time I go to the nodes menu
3. Additionally, the new code for email notifications for nodes could also potentially pause the cron job when sending an email notification.

PR: #198
Even though the changelog-NG.txt for AX models contained high-risk phrases, it did not notify some people.
The selection process of the changelog contents to scan was problematic and needed to be refined.

Tightening up some code & general code improvements.

Martinski has been away with work and family (i totally understand other priorities come up)
As this was me a special, I tested and validated as much as I could over the last 24+ hours, but I'm not perfect so if you notice anything please report it.

As already mentioned RMerlin has resolved the issues with the changelogs in the archives themselves.

Significant screenshots:
GUI and feature-set remains the same, only behind the scene bug fixes and improvements.

 

[aex.perez]

Got impatient with the last firmware release and short changed MerlinAU, was determined to let it run it's course with this release, and glad I did.

Goodnews:
The upgrade from 388.7_beta1 to 388.7.0 process with MerlinAU, and the call out to BACKUPMON, as well as the succes notification email, went flawlessly on the router, and one of the nodes.

Badnews:
Had to manually launch the process using oprtion "1." and answering "yes" when prompted to upgrade on the router and then separetly one node. The script didn't launch on any device, based on the cron schedule I am using (0 0 * * 0), guessing I must've missed something somewhere.

(I half expected the Nodes to fail because the router would be updating at the same time, on this schedule, and the node(s) would not be able to download the code, generating the failure email. Since I had to launch this manually on two devices (router then 1 node other and see it through), it wasn't an issue, also didn't get an email that the schedule was missed. Note: "Half expected it to fail" because the firmware download happens very quickly and maybe the nodes may have been able to download the code to begin execute the upgrade within that small window, then again maybe not )

Left the other node without updating, so I can modify/fix the schedule, and try again.

(Note: all other scheduled jobs on the router and both nodes, including the one that I left on the beta to test the process, are running fine and on schedule)

Any hints?
Not sure what I missed

 

[ExtremeFiretop]

Got impatient with the last firmware release and short changed MerlinAU, was determined to let it run it's course with this release, and glad I did.

Goodnews:
The upgrade from 388.7_beta1 to 388.7.0 process with MerlinAU, and the call out to BACKUPMON, as well as the succes notification email, went flawlessly on the router, and one of the nodes.

Badnews:
Had to manually launch the process using oprtion "1." and answering "yes" when prompted to upgrade on the router and then separetly one node. The script didn't launch on any device, based on the cron schedule I am using (0 0 * * 0), guessing I must've missed something somewhere.

(I half expected the Nodes to fail because the router would be updating at the same time, on this schedule, and the node(s) would not be able to download the code, generating the failure email. Since I had to launch this manually on two devices (router then 1 node other and see it through), it wasn't an issue, also didn't get an email that the schedule was missed. Note: "Half expected it to fail" because the firmware download happens very quickly and maybe the nodes may have been able to download the code to begin execute the upgrade within that small window, then again maybe not )

Left the other node without updating, so I can modify/fix the schedule, and try again.

(Note: all other scheduled jobs on the router and both nodes, including the one that I left on the beta to test the process, are running fine and on schedule)

View attachment 58289View attachment 58290View attachment 58291

Any hints?
Not sure what I missed

Hi @aex.perez did you update to MerlinAU 1.1.2 before they attempted to update via cron? Or after?
Can I see a copy of the logs file please so I can see when the cron job stopped? Or are you saying there is no log file because it didn't run at all?
That would indicate a different issue all together.

Thanks for reporting

 

[aex.perez]

Hi @aex.perez did you update to MerlinAU 1.1.2 before they attempted to update via cron? Or after?
Can I see a copy of the logs file please so I can see when the cron job stopped? Or are you saying there is no log file because it didn't run at all?
That would indicate a different issue all together.

Thanks for reporting

Yes, updated to 1.1.2 before the scheduled update.

On the one node that did NOT update, it didn't run, so suspect no log file.
On the Router and node where it did not run according to the schedule I set, and I launched manually, it did run so I have logs on those. Both nodes are identical from a configuration standpoint.
I did look in the directory that is set for the log files (AD 2), just found the one file containing a list of .log files, didn't dig too deep to see where each log file is written to.
Where should I look?

Corrected:

Did I miscalculate counting days? Was thinking it was going to run last night at midnight, maybe I screwed up...

 

[ExtremeFiretop]

Yes, updated to 1.1.2 before the scheduled update.

On the one node that did NOT update, it didn't run, so suspect no log file.
On the Router and node where it did not run according to the schedule I set, and I launched manually, it did run so I have logs on those. Both nodes are identical from a configuration standpoint.
I did look in the directory that is set for the log files (AD 2), just found the one file containing a list of .log files, didn't dig too deep to see where each log file is written to.
Where should I look?

Corrected:
View attachment 58294

Did I miscalculate counting days? Was thinking it was going to run last night at midnight, maybe I screwed up...

So based on that log file, MerlinAU ran on Sunday the 28th at midnight, so the 8:27PM of that Sunday had not passed yet.
It still had about more hours to go until the postpone period was over.

I can tell this because the time frame shows 00:00:01 after 00:00:00 without changing the day, so for it to pass the postpone period, it would of needed to be scheduled the night of the Sunday/Monday, but instead it ran that morning of the Saturday/Sunday.
I hope that makes sense, now that your cron is scheduled to only run on Sundays, it will wait until next Sunday to try again. (This coming weekend of the 5th)

If you want it to run nightly, you should set the cron to

0 0 * * *

 

[aex.perez]

So based on that log file, MerlinAU ran on Sunday the 28th at midnight, so the 8:27PM of that Sunday had not passed yet.
It still had about more hours to go until the postpone period was over.

I can tell this because the time frame shows 00:00:01 after 00:00:00 without changing the day, so for it to pass the postpone period, it would of needed to be scheduled the night of the Sunday/Monday, but instead it ran that morning of the Saturday/Sunday.
I hope that makes sense, now that your cron is scheduled to only run on Sundays, it will wait until next Sunday to try again. (This coming weekend of the 5th)

If you want it to run nightly, you should set the cron to

0 0 * * *

Yes, now it does
I read it wrong back when I installed and enabled it on everything.
So router on "0 0 * * *" nodes on "30 0 * * *" to avoid conflict to download the Firmware update to the nodes.

As I was updating the schedule, got this....

Though I do occsionally get this on the router and on either node, when launching the script even though automatic checks are enabled on all of them.
In this case it was the other node, (the one I manually updated, didn't get this message last night as I launched the script to manually launch the update) before answering "No", checked cron and the schedule was set. Then answered "No" and renabled it then updated the schedule.

Before schedule modification (on node)

After (on node)

Minor, and random, not consistent, but thought I should share...
Doesn't seem to interrupt process because the scheduled cron job is still there...

Thanks,
Other than my scheduling snafu it ran perfectly!