MerlinAU MerlinAU v1.3.12 - The Ultimate Firmware Auto-Updater (GNUTON SUPPORT!)

[visortgw]

All we would need to do is increment the version with each new PR, but that's generally not how we handle versioning

All of these PRs are in the dev branch and all these changes are still under the "version 1.4.0" until released.

I was not thinking incrementing version by PR , but rather recognizing "hot fixes" as some of the other add-ons do. I was just thinking that it might make debugging easier for you since more users would be on latest (or nearly latest) version within development branch. Possibly include latest PR number in release to key off?

 

[visortgw]

I was not thinking incrementing version by PR , but rather recognizing "hot fixes" as some of the other add-ons do. I was just thinking that it might make debugging easier for you since more users would be on latest (or nearly latest) version within development branch. Possibly include latest PR number in release to key off?

Or, "simply" executing forceupdate code (when cron job fires) if on develop branch and auto script update enabled.

 

[ExtremeFiretop]

I was not thinking incrementing version by PR , but rather recognizing "hot fixes" as some of the other add-ons do. I was just thinking that it might make debugging easier for you since more users would be on latest (or nearly latest) version within development branch. Possibly include latest PR number in release to key off?

Yeah that's why I mentioned it's not generally how we do the versioning, it would work with the current implementation, but it wouldn't be ideal.

Your mentioned ideas has sparked some thoughts. I'll discuss with Martinski, but generally the understanding is that dev is an active development branch and stuff can change quickly and without mention.

It's the fun apart of being on the development branch with us.

I realize you have an army of routers, but you only probably need to test the dev branch with one or two I would think, the rest could stay on the production branch?

 

[visortgw]

Yeah that's why I mentioned it's not generally how we do the versioning, it would work with the current implementation, but it wouldn't be ideal.

Your mentioned ideas has sparked some thoughts. I'll discuss with Martinski, but generally the understanding is that dev is an active development branch and stuff can change quickly and without mention.

It's the fun apart of being on the development branch with us.

I realize you have an army of routers, but you only probably need to test the dev branch with one or two I would think, the rest could stay on the production branch?

Correct, but it is initially tested when you post it to dev branch. I generally update nodes all together as development progresses, but that's just me...

 

[ExtremeFiretop]

Correct, but it is initially tested when you post it to dev branch. I generally update nodes all together as development progresses, but that's just me...

Fair point I'm not trying to change your workflow, just a comment on how we usually work in the branch. You are correct that all PRs are tested before going to dev, this was just a small oversight due to having to reformat last minute.

It brings up a thought which is if you happen to not update to the dev branch right now, and decide to remain on production (maybe due to not liking the dynamic nature of the dev branch), you would be missing some recent fixes we found while troubleshooting.

Maybe of value to consider backporting those fixes to production? Although I feel we are near the end of beta testing at this point, I would say I'm mostly waiting for a new firmware drop so people can report their successes or potential bugs they find.

 

[ExtremeFiretop]

MerlinAU 1.3.11 Released!

What's Changed/Fixed?:

As previously mentioned above, Martinski and I have decided that 3 fixes from beta version 1.4.0 should be back ported to production.

Backport 1.4.0 Fixes to 1.3.11 Production
This includes changes from the following PRs:

PR: [ #415] - Improvements & Enhancements

• Increased sleep time to 15 seconds after removing 3rd-party cron jobs to allow already started cron jobs to complete execution. Most cron jobs finish in a couple of seconds, but a few may require more time, especially those dealing with background SQL database operations (e.g. uiDivStats, connmon, spdmerlin, ntpmerlin, vnStats) so allowing more time can prevent corrupting the database/CSV files if the operation is abruptly interrupted.
• Added commands just before removing/unmounting the USB drives to make sure that any existing I/O blocks currently buffered/cached are flushed and written out safely to the USB drives.
• (Thanks @Martinski4GitHub @Martinski)
  
  
  
  

PR: [ #423] - Minor Fixes

• Fixed a rare and uncommon "post email upgrade" bug we found back in January.
• Added a check to validate the downloaded firmware version by MerlinAU is in fact the version found by the router's webs_update.sh script. (Essentially blocking accidential downgrades if a firmware is issued and recalled)
  
  
  

PR: [ #424] - Typo Correction

• Fixed a long standing bug with the firmware decompression validation step, which allowed the script to continue even if the firmware unzip process failed for some reason.
  
  
  

Thanks!

 

[ExtremeFiretop]

MerlinAU 1.3.12 Released!

What's Changed/Fixed?:

PR: [ #433] - More Fixes and Improvements.

• Fixed a bug where the version.txt file was being replaced prematurely.
• Fixed a bug where the wrong parameter value for URL was being returned.
• Some code improvements.
• (Thanks @Martinski4GitHub @Martinski)

Thanks!

 

[ExtremeFiretop]

I was not thinking incrementing version by PR , but rather recognizing "hot fixes" as some of the other add-ons do. I was just thinking that it might make debugging easier for you since more users would be on latest (or nearly latest) version within development branch. Possibly include latest PR number in release to key off?

Or, "simply" executing forceupdate code (when cron job fires) if on develop branch and auto script update enabled.

@visortgw

Martinski also implemented a way to do auto-updates in the dev branch in PR: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/432/files

The new timestamp in the version.txt file is really meant only for developments builds where the version string remains the same.
So that when users are testing the alpha/beta builds; they can get new updates automatically when we change the timestamp; but, if the timestamp remains the same, the updates are no longer automatic (they must do "force updates").

This allows us to exercise control when on we deem the current development branch to be "good enough" for external testing purposes.

 

[Martinski]

@visortgw

Martinski also implemented a way to do auto-updates in the dev branch in PR: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/432/files

The new timestamp in the version.txt file is really meant only for developments builds where the version string remains the same.
So that when users are testing the alpha/beta builds; they can get new updates automatically when we change the timestamp; but, if the timestamp remains the same, the updates are no longer automatic (they must do "force updates").

NOTE:
When updating to the latest dev 1.4.0 version (dated Mar-28th) from an older dev version (dated before Mar-26th), you may get a "bad number" error message because the older version knows nothing about the new build "timestamp" that leads to the error. Simply ignore this error and proceed to do a "forceupdate" call. Once the latest dev version has been installed, the "bad number" error will no longer appear.

 

[visortgw]

@visortgw

Martinski also implemented a way to do auto-updates in the dev branch in PR: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/432/files

The new timestamp in the version.txt file is really meant only for developments builds where the version string remains the same.
So that when users are testing the alpha/beta builds; they can get new updates automatically when we change the timestamp; but, if the timestamp remains the same, the updates are no longer automatic (they must do "force updates").

This allows us to exercise control when on we deem the current development branch to be "good enough" for external testing purposes.

Excellent implementation, @Martinski and @ExtremeFiretop!

 

[vlord]

WELL FOLKS!

We have been busy behind the scenes. Below are recent updates to the DEVELOP branch.

MerlinAU Version 1.4.0 is still unreleased at this time; and only available for beta testing.
If you are currently on the production version 1.3.10 or develop 1.4.0; you may update to test these changes below using the following commands:

- v1.3.10 (update with)

sh /jffs/scripts/MerlinAU.sh develop

- v1.4.0 (update with)

sh /jffs/scripts/MerlinAU.sh forceupdate

We request any 1.4.0 testers to try the new changes below and report back.
Thanks!

PR: [ #421] - Improved Symmetry

• I changed the location of the "Changelog Approval" setting value under the firmware status section.
• Every other setting in the setting section, is a setting the user controls and won't change without user control... While other values in the firmware status section is dynamic and can change without user action, aka, going from TBD to Blocked. And then from Approved back to TBD.

PR: [ #422] - Minor Cleanup

• Some minor changes to get "clean" code via the Linter tool.
• (Thanks @Martinski4GitHub @Martinski)

PR: [ #423] - Minor Fixes

• Fixed a rare and uncommon "post email upgrade" bug we found back in January.
• Added a check to validate the downloaded firmware version by MerlinAU is in fact the version found by the router's webs_update.sh script.
• (Essentially blocking accidential downgrades if a firmware is issued and recalled)
  
  View attachment 64544

PR: [ #424] - Typo Correction

• Fixed a long standing bug with the firmware decompression validation step, which allowed the script to continue even if the firmware unzip process failed for some reason.

PR: [ #425] - Test WebGUI Support in AP Mode.

• Martinski made a tweak to test/validate WebGUI support when router is in AP Mode. Reported by @vlord
• (Thanks @Martinski4GitHub @Martinski)

PR: [ #426] - Improvements to support APs

• (This was to address a concern of mine where an AP would show the AiMesh nodes menu and run in "Primary router" mode.)
• Martinski made changes so that we can handle specific functionality or features based on whether the router is operating in "Router Mode" (i.e. Primary router) or in "AP Mode."
• This allows us to determine whether the WebGUI should be mounted or whether the AiMesh nodes should be handled only by the Primary router.
• Added WebUI Tab URL info to the CLI "About" page.
• (Thanks @Martinski4GitHub @Martinski)
  
  View attachment 64540

PR: [ #427] - Cleanup Changelog Flow in WebUI

• I changed the visuals of the "Latest Changelog" button in the WebUI at the request of @vlord
• The process is more or less the same, but it will now open in an overlay instead of a new window, and won't display as though it's applying any setting.
  
  View attachment 64541
  View attachment 64542

PR: [ #428] - Change Layout For Single Save Button

• Change layout for a single save button:
  1. It's caused confusion for @maghuro from his mobile
  2. @dave14305 commented it doesn't follow the usual standards
  3. @vlord requested it as well
• Frankly; I don't care enough about the original design to explain forever; So be it, It only ended up the original way because it developed that way as I was playing and learning with the project.
  
  View attachment 64543

Like the new layout! Much cleaner. Can you add support for on the webUI for monthly updates? One other suggestion is if you could increment your beta releases and add auto updates.

 

[ExtremeFiretop]

Like the new layout! Much cleaner.

Happy to hear, like I mentioned I didn't care for the original that much, I just didn't want to risk breaking anything redoing it all, but it's been done after the few times it was brought up.

Can you add support for on the webUI for monthly updates? One other suggestion is if you could increment your beta releases and add auto updates.

Auto updates is already implemented both in the WebUI and in the shell script of the screenshots you shared.

Am I misunderstanding something?

 

[vlord]

Happy to hear, like I mentioned I didn't care for the original that much, I just didn't want to risk breaking anything redoing it all, but it's been done after the few times it was brought up.



Auto updates is already implemented both in the WebUI and in the shell script of the screenshots you shared.

Am I misunderstanding something?

Does this work for the beta releases? I might have misunderstood that it was only for stable release train. Also not in the screenshot I shared, the Saturday checkbox and text are disconnected. For the other item mentioned, in the webUI no indicator that it’s updating on a monthly basis.

 

[ExtremeFiretop]

Does this work for the beta releases? I might have misunderstood that it was only for stable release train.

Yes, it works with the dev branch as of the latest update.
Check the conversation right above yours; starting here: https://www.snbforums.com/threads/m...auto-updater-gnuton-support.91326/post-949618

Also not in the screenshot I shared, the Saturday checkbox and text are disconnected.

Looks fine to me here; not sure why it would be off for you, I can check the code later.

For the other item mentioned, in the webUI no indicator that it’s updating on a monthly basis.

That -what- is updating monthly? The script? or the firmware?
The script will always auto-update daily, theres no controlling that, if you mean the monthly cron schedule for firmware updates it shows it here in your screenshot:

 

[vlord]

Yes, it works with the dev branch as of the latest update.
Check the conversation right above yours; starting here: https://www.snbforums.com/threads/m...auto-updater-gnuton-support.91326/post-949618



Looks fine to me here; not sure why it would be off for you, I can check the code later.

View attachment 64688



That -what- is updating monthly? The script? or the firmware?
The script will always auto-update daily, theres no controlling that, if you mean the monthly cron schedule for firmware updates it shows it here in your screenshot:

View attachment 64689

I was referring to the section “schedule for F/W update checks” which has the correct hour but doesn’t have options for weeks or once a month. Maybe I’m misunderstanding the use of this section relative to the “enable automatic F/W update checks” section?

 

[ExtremeFiretop]

@vlord

Can you provide a screenshot of the F12 debug screen if possible? I also noticed in your screenshot that the approve changelog isn't grayed out, which unless you have a firmware update pending, it should be.

As for this:

I was referring to the section “schedule for F/W update checks” which has the correct hour but doesn’t have options for weeks or once a month. Maybe I’m misunderstanding the use of this section relative to the “enable automatic F/W update checks” section?

For the Implementation of the "Schedule for F/W Update Checks" user input on the WebGUI currently the design is meant to be simple and intuitive to allow users to set up the most common cron schedules with standard parameters that should satisfy the requirements of the vast majority of users (~95% perhaps?)
If a user wants to have a more complex cron schedule (e.g. with a specific list of days of month) then the recommendation would be to use the SSH CLI menus.

The goal was not to handle any and all possible cron schedule parameter combinations.
It was designed with simplicity and ease of use in mind so that regular users can set up the most common cron schedules that would satisfy their requirements. For anything more complex, users will need to use the SSH CLI menu options.

 

[ExtremeFiretop]

@vlord

@Martinski implemented a PR to attempt to solve the issue with Sat showing up on the new line by removing the extra spacing

I wasn't able to replicate on my screen, and apparently Martinski can't either; but if you could test this change and confirm or deny if it solved it for you?

I'm assuming you may have a smaller screen or a lower resolution.

Thanks!

 

[vlord]

@vlord

@Martinski implemented a PR to attempt to solve the issue with Sat showing up on the new line by removing the extra spacing

I wasn't able to replicate on my screen, and apparently Martinski can't either; but if you could test this change and confirm or deny if it solved it for you?

I'm assuming you may have a smaller screen or a lower resolution.

Thanks!

That worked. This is from my ipad pro 13”. Once I get back in front of a real computer I can send you details from inspector.

 

[ExtremeFiretop]

That worked. This is from my ipad pro 13”. Once I get back in front of a real computer I can send you details from inspector. View attachment 64703

Happy to hear that moving the elements just a little bit over was all we needed for you.

Thanks for testing!

EDIT: And yes, please send the F12 info since I can still see the Approve changelog button is not grayed out.
Also if you could send the contents of your configuration file, maybe just blank out the password.

Weird that your grayed out email field says "undefined".