MerlinAU MerlinAU v1.5.1 - The Ultimate Firmware Auto-Updater (WEBUI + GNUTON SUPPORT!)

[scootertramp]

Question on why F/W Update Postponement Days was not honored after the MerlinAU update to 1.5.1.
All my routers either updated or tried to update to 3004.388.9.2-gnuton2 from 3004.388.9.2-gnuton1.
I currently have all routers set to 30 days.

4. Set F/W Update Postponement Days
[Current Days: 30]

Also the last notification date didn't get updated.

3. Toggle Automatic F/W Update Checks
[Currently ENABLED ]
[Last Notification Date: 2025-Jun-25 12:20 AM]

That date is from when 3004.388.9.2-gnuton1 became available.

 

[ExtremeFiretop]

or tried to update to 3004.388.9.2-gnuton2 from 3004.388.9.2-gnuton1.

What does this mean? They will always "try" to update... Everyday (or however often you setup the cron schedule)
But will be blocked by the postpone until it's been passed. Can you provide logs of the update attempt from the "Log Options" menu please? What about router models or screenshots?

I just tested this report on my Gnuton router and got the expected behavior both interactively and non-interactively and was unable to replicate:

Also the last notification date didn't get updated.

3. Toggle Automatic F/W Update Checks
[Currently ENABLED ]
[Last Notification Date: 2025-Jun-25 12:20 AM]

That date is from when 3004.388.9.2-gnuton1 became available.

Again unable to recreate this. Please provide logs, models, and any screenshots of the issue.
Thanks!

 

[ExtremeFiretop]

Also the last notification date didn't get updated.

3. Toggle Automatic F/W Update Checks
[Currently ENABLED ]
[Last Notification Date: 2025-Jun-25 12:20 AM]

That date is from when 3004.388.9.2-gnuton1 became available.

Also to be clear in your case, I believe the issue is actually only that the last notification date didn't get updated,
Not that the postpone was not honored. In-fact in your case the postpone appears was perfectly honored. 30 days away from your last notification date would be July 25, so the 30 days are long past by that point and the postpone has nothing to block.

But the notification date should of updated from gnuton1 to gnuton2 and reset the postpone period, which in this case it doesn't look like it did for some reason. What is your cron schedule set as?

I'm assuming because up until 1.5.1 both MerlinAU and the built-in Webs_update script was were unable to determine that Gnuton2 is newer than Gnuton1.
MerlinAU is manually working around that issue until @GNUton merges in PR: https://github.com/gnuton/asuswrt-merlin.ng/pull/813

 

[scootertramp]

What does this mean? They will always "try" to update... Everyday (or however often you setup the cron schedule)
But will be blocked by the postpone until it's been passed. Can you provide logs of the update attempt from the "Log Options" menu please? What about router models or screenshots?

I just tested this report on my Gnuton router and got the expected behavior both interactively and non-interactively and was unable to replicate:

View attachment 67161View attachment 67162



Again unable to recreate this. Please provide logs, models, and any screenshots of the issue.
Thanks!

I have one ax92u that tried to update FW but was unable due to memory available. I updated this one after a reboot using the GUI.
Also there are three xt8's that updated from MelrinAU. Here is the update log from one of these units.

 

[scootertramp]

Also to be clear in your case, I believe the issue is actually only that the last notification date didn't get updated,
Not that the postpone was not honored. In-fact in your case the postpone appears was perfectly honored. 30 days away from your last notification date would be July 25, so the 30 days are long past by that point and the postpone has nothing to block.

But the notification date should of updated from gnuton1 to gnuton2 and reset the postpone period, which in this case it doesn't look like it did for some reason. What is your cron schedule set as?

I'm assuming because up until 1.5.1 both MerlinAU and the built-in Webs_update script was were unable to determine that Gnuton2 is newer than Gnuton1.
MerlinAU is manually working around that issue until @GNUton merges in PR: https://github.com/gnuton/asuswrt-merlin.ng/pull/813

I believe you are correct that the issue was due to the notification date not being updated. The date it currently has is from when the F/W
3004.388.9.2-gnuton1 was released. At that time it did what I was expecting. Sent a email of new F/W version but did not update F/W.

All of my routers have the same notification date of June 25. None were updated from this mornings F/W updates.

Attached is the cron from one of the XT8's.

 

[ExtremeFiretop]

I believe you are correct that the issue was due to the notification date not being updated. The date it currently has is from when the F/W
3004.388.9.2-gnuton1 was released. At that time it did what I was expecting. Sent a email of new F/W version but did not update F/W.

All of my routers have the same notification date of June 25. None were updated from this mornings F/W updates.

Attached is the cron from one of the XT8's.

Okay thanks for that, the extra detail helps shape a picture. The script at this point is over 11,000 lines of code so going off memory these days isn't always possible.

I have a theory, let me see if I can recreate it/confirm it. I'll message you shortly if I need anything else from you.

 

[scootertramp]

Okay thanks for that, the extra detail helps shape a picture. The script at this point is over 11,000 lines of code so going off memory these days isn't always possible.

I have a theory, let me see if I can recreate it/confirm it. I'll message you shortly if I need anything else from you.

I don't see anything that catches my eye but here is the messages file from first entry after midnight till reboot after F/W update.

 

[ExtremeFiretop]

Hi @scootertramp
Just circling back around to confirm I've replicated your behavior, thank you for reporting it and providing the extremely useful log data as i was unable to replicate it originally.

The issue as I thought is the fact that your settings file still contained the older formatted version for Gnuton as seen below.
-Postpone "Bypassed"

-Postpone working as designed:

It would only be an issue for Gnuton users, and only an issue for users jumping from 1.5.0 to 1.5.1 with our current state of having 2 identical releases from Gnuton: 3004.388.9_2-gnuton1 and 3004.388.9_2-gnuton2
I won't lie; this is 120% an oversight on my part with MerlinAU release v1.5.1 where I fixed the Gnuton version comparisons in PR: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/498

To quote mydumbself:

PR: [ #498 ] - Fixing More Comparison Errors

• Turns out we can't strip -gnuton1 or -gnuton2 as those actually mean something LOL I had to pivot so we correctly weighted those suffixes, and then go back and redo the fixes for the 2 previous PRs and think real hard to make sure there's no backlash and I don't retrigger those problems

Well; clearly I didn't think hard enough LOL.
It would "fix itself" and start to use the "long version" of the firmware version when the next firmware release actually increments itself (i.e 3004.388.9_3 or 3004.389.0?)

However that's not something I'm okay ignoring so I've created PR: https://github.com/ExtremeFiretop/MerlinAutoUpdate-Router/pull/505
It resolved the issue for me in my test after re-creating the issue, and the change is so small I was tempted to just push it through... But I think it's in everyone's interest I let Martinski test on his non-Gnuton routers as well to sign off on the next release.

Thanks again for the fun investigation!