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

[ExtremeFiretop]

You could also do like Skynet and if you see the script is not installed upon running, set the install argument within the script to force an install.

IPSet_ASUS/firewall.sh at b388084289a07e572a5f37d03d1a9f896148bf25 · Adamm00/IPSet_ASUS

Skynet - Advanced IP Blocking For ASUS Routers Using IPSet. - Adamm00/IPSet_ASUS

github.com

I like it, it's better than my workaround method now; I'll help myself to implementing something similar.
Thanks for the suggestion dave!

 

[ExtremeFiretop]

OK some feedback and some minor quibbles...
01 - OK

Happy to see I fixed that report for you

02 - Quibble. You cannot have 1.4.1 offering an update to .... 1.4.1; nor can it be "available" for download if you have it already running.

Ah; I see the bug, it's no longer downloading the version.txt when it used too. It may be related to PR: 433: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/433 or it may not; just a gut feeling.
I'll investigate, thanks for reporting!

03 - Request. After you set the Router PWD a flag that is has been done and is successful would be useful?

I'll keep it in mind for sure once we smooth out the update for everyone

04 - The 5. Toggle seems gramatically incorrect and does not behave in any case, Issue.

Unable to recreate this with a fresh install, did you happen to keep your configuration file when uninstalling?
If so, please delete it and re-test and advise, if not, please provide an example of the configuration file (remember to blank out the password/credentials)

05 - The 3. Toggle seems OK.

Okay - What about the previous toggle you reported? Is it fixed now? (The tailscale toggle)

How do I revert to the mainstream install btw?

This will get you back to the production 1.4.0:

sh /jffs/scripts/MerlinAU.sh stable

 

[jksmurf]

Happy to see I fixed that report for you

Sorry I forgot to say thank you . Getting a wee bit tired here,,,

Ah; I see the bug, it's no longer downloading the version.txt when it used too. It may be related to PR: 433: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/433 or it may not; just a gut feeling. I'll investigate, thanks for reporting!

Coolio.

I'll keep it in mind for sure once we smooth out the update for everyone

Coolio.

Unable to recreate this with a fresh install, did you happen to keep your configuration file when uninstalling?
If so, please delete it and re-test and advise, if not, please provide an example of the configuration file (remember to blank out the password/credentials)

First time I kept it, second time I uninstalled and deleted it, then reinstalled, Screencaps from run 2,.

Okay - What about the previous toggle you reported? Is it fixed now? (The tailscale toggle)

Lol, I was wondering what happened to 4, I thought you snuck in another number and shifted them all one to see if I was awake.... it's on page "ad... "
Apart from an odd initial question, I think it's working but the colours are inverted which is confusing me no end ,,,

This will get you back to the production 1.4.0:

sh /jffs/scripts/MerlinAU.sh forceupdate

Cheers

 

[ExtremeFiretop]

Lol, I was wondering what happened to 4, I thought you snuck in another number and shifted them all one to see if I was awake.... it's on page "ad... "
Apart from an odd initial question, I think it's working but the colours are inverted which is confusing me no end ,,,

Cheers

So basically your still having the bug with the changelog check? Is that correct? Could you provide me your configuration file? Just make sure to blank out the credentials please.
As for your question as to why disabled is green and enabled is red, is because green is the default choice for the script for that setting. By default people should have it disabled (green) unless absolutely required in which case the user selects "enabled (red)" which is not the default/ideal choice.

 

[jksmurf]

So basically your still having the bug with the changelog check? Is that correct?

Just testing it again, Seems to behave, apart from the first run question, if it is currently enabled, why is the first question "proceed to enable" and not "proceed to disable?"

Could you provide me your configuration file? Just make sure to blank out the credentials please.

Where do I find that file please?

As for your question as to why disabled is green and enabled is red, is because green is the default choice for the script for that setting. By default people should have it disabled (green) unless absolutely required in which case the user selects "enabled (red)" which is not the default/ideal choice.

OK I see. It is a wee bit counter to the other options so for me a "Default=Disabled" reminder here would go some way to clarifying that .

 

[ExtremeFiretop]

Just testing it again, Seems to behave, apart from the first run question, if it is currently enabled, why is the first question "proceed to enable" and not "proceed to disable?"

Thats a bug for sure; thats what I'm trying to figure out, with my version from the dev branch with a fresh install it works fine:

Where do I find that file please?

Use:

cat /jffs/addons/MerlinAU.d/custom_settings.txt

OK I see. It is a wee bit counter to the other options so for me a "Default=Disabled" reminder here would go some way to clarifying that .

I can add that to the list as well

 

[jksmurf]

Thats a bug for sure; thats what I'm trying to figure out, with my version from the dev branch with a fresh install it works fine:

View attachment 64841

Use:

cat /jffs/addons/MerlinAU.d/custom_settings.txt

I can add that to the list as well

FW_New_Update_Notification_Date TBD
FW_New_Update_Notification_Vers TBD
FW_New_Update_Postponement_Days=15
FW_New_Update_EMail_Notification DISABLED
FW_New_Update_EMail_FormatType="HTML"
FW_New_Update_Cron_Job_Schedule="20 0 * * *"
FW_New_Update_ZIP_Directory_Path="/home/root"
FW_New_Update_LOG_Directory_Path="/jffs/addons"
FW_Update_Check ENABLED
CheckChangeLog ENABLED
FW_New_Update_Changelog_Approval="TBD"

 

[ExtremeFiretop]

FW_New_Update_Notification_Date TBD
FW_New_Update_Notification_Vers TBD
FW_New_Update_Postponement_Days=15
FW_New_Update_EMail_Notification DISABLED
FW_New_Update_EMail_FormatType="HTML"
FW_New_Update_Cron_Job_Schedule="20 0 * * *"
FW_New_Update_ZIP_Directory_Path="/home/root"
FW_New_Update_LOG_Directory_Path="/jffs/addons"
FW_Update_Check ENABLED
CheckChangeLog ENABLED
FW_New_Update_Changelog_Approval="TBD"

Your sure your testing with the version from the dev branch? Between uninstalling and reinstalling? And deleting the configuration file?
That configuration file is missing a lot of values.

curl --retry 3 "https://raw.githubusercontent.com/ExtremeFiretop/MerlinAutoUpdate-Router/refs/heads/dev/MerlinAU.sh" -o "/jffs/scripts/MerlinAU.sh" && chmod 755 "/jffs/scripts/MerlinAU.sh"

I made another change to implement @dave14305 's recommendation as well for handling the install parameter situation in PR 444 : https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/444

 

[jksmurf]

Your sure your testing with the version from the dev branch? Between uninstalling and reinstalling? And deleting the configuration file?

Yes. I uninstalled and said trash the config, I used the same curl dev install each run, it wouldn’t say 1.4.1 otherwise would it

That configuration file is missing a lot of values.

I know; but the issues with the other items shouldn’t be dependent on these being populated or ?

curl --retry 3 "https://raw.githubusercontent.com/ExtremeFiretop/MerlinAutoUpdate-Router/refs/heads/dev/MerlinAU.sh" -o "/jffs/scripts/MerlinAU.sh" && chmod 755 "/jffs/scripts/MerlinAU.sh"

I used the one you gave me in the post above. Seems the same?

I made another change to implement @dave14305 's recommendation as well for handling the install parameter situation in PR 444 : https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/444

Ok will try tomorrow it’s 1:15am … zzzzz thanks

 

[ExtremeFiretop]

Yes. I uninstalled and said trash the config, I used the same curl dev install each run, it wouldn’t say 1.4.1 otherwise would it

My question is whether or not your latest output is from 1.4.1; considering the configuration output doesn't say 1.4.1 and you didn't specify in the reply, I need to ask for clarity.
Considering your uninstalling and reinstalling, it's easy to keep the configuration file for another version of the script, or reinstall the wrong version by mistake when providing the output.

I know; but the issues with the other items shouldn’t be dependent on these being populated or ?

What issues with other items? As of this moment from my last PR, my only thing remaining is your changelog check.
My configuration file looked like your empty one before my very first PR, since my first PR, it's been fully populated on every clean install; which is why I ask for clarity above considering it wasn't provided.

I used the one you gave me in the post above. Seems the same?

Yes they are the same, I am re-providing it for you to test my latest changes, the URL will not change.

 

[visortgw]

OK some feedback and some minor quibbles...
01 - OK
02 - Quibble. You cannot have 1.4.1 offering an update to .... 1.4.1; nor can it be "available" for download if you have it already running.
03 - Request. After you set the Router PWD a flag that is has been done and is successful would be useful?
04 - The 5. Toggle seems gramatically incorrect and does not behave in any case, Issue.
05 - The 3. Toggle seems OK.

How do I revert to the mainstream install btw?

sh /jffs/scripts/MerlinAU stable

 

[ExtremeFiretop]

Ok will try tomorrow it’s 1:15am … zzzzz thanks

I'm taking a break myself now... I poked for a bit longer; but I can't replicate the issue with the configuration file anymore since my PRs, I'm getting a bit of headache so I'll step away for a bit and wait too see if Martinski has any more ideas or feedback.

To clarify my last reply above, the reason I continued poking if you are on 1.4.1 and deleted the configuration file between tests is simply because it's easy to miss, and as I mentioned in my reply; I did have the problem with the configuration file, and no longer have it on my side since my latest PRs.

Even when downgrading back to the current 1.4.0 I have the issue again. This to me quickly confirms I'm on the right track; but you seem to still have issue.

My only answer right now is the configuration file remained as a bug or user error, or I'm completely barking up the wrong tree and my results are just a red herring distracting from something else.

For example, the uninstall specifically requires a "Y" and then a "N" selection to delete the confirmation file... However if your expecting a "Yes" to confirm uninstalling and then a "Yes" to confirm "trashing" the configuration file you will be caught off guard when that's not how it functions.. it's "Yes" to uninstall and "No" to preserving the file which could be an easy miss for example. Another example is you mentioned you weren't sure where the file was which means a visual confirmation may not have been done that the file is indeed missing between tests (even if you may have selected to delete the file, it could have remained as a bug for example).

It's not to be annoying that I circle back to these points, it's only to verify the information collected is complete, and understood correctly on both sides.