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

[ExtremeFiretop]

Just tried to run the update again, making sure this time to avoid spdMerlin's schedule, and it completed successfully in about 5 minutes. I'm now on 3004.388.10.2. FYI, the logs don't show any lines containing rc_service: start_upgrade. Are you sure that's part of an upgrade?

Seems to us that the most likely explanation is that your settings for the system log are preventing some entries from showing up in the log.
You most likely have set the option "Log only messages more urgent than" to "notice" level or perhaps higher, which is causing our ability to see what happened to be limited in scope unfortunately.

I've merged in a change from Martinski that enhances our control of the USB unmount so we will be doing extensive testing to try and recreate the issue and validate the changes ASAP.
Thanks for holding tight, anyone that updates to the current dev build, be aware we are calling it experimental and in testing at this time.

 

[aletaziar]

Seems to us that the most likely explanation is that your settings for the system log are preventing some entries from showing up in the log.
You most likely have set the option "Log only messages more urgent than" to "notice" level or perhaps higher, which is causing our ability to see what happened to be limited in scope unfortunately.

I have it set to info. I thought this would mean the only messages hidden are the debug level. Am I mistaken? I'm not sure how the "Default message log level" affects this, but I don't remember changing anything here from defaults. I guess this does mean that if the rc_service: start_upgrade is a kernel message, it wouldn't be shown.

 

[ExtremeFiretop]

View attachment 68869
I have it set to info. I thought this would mean the only messages hidden are the debug level. Am I mistaken? I'm not sure how the "Default message log level" affects this, but I don't remember changing anything here from defaults. I guess this does mean that if the rc_service: start_upgrade is a kernel message, it wouldn't be shown.

I believe this is usually the default we see/deal with:

The option for "Default message log level" is set to: "notice"
And the option for "log only messages more urgent than" is set to: "debug"

(I've never changed mine)

Other posts found below that confirm this:

Router restarts...kernel: brcmboard registered...

Latest Merlin FW: 3004.388.8_4 I noticed the router re-boot on its own around every 10-20 days but last 2 days I have seen this message twice at night, the NAS sends me a disconnect email, everything works fine but the router rebooting? Also the May 4 date is not right, anyone? May 4 22:05:07...

www.snbforums.com

Skynet - Logging level

What log level for "Default message log level" and "Log only messages more urgent than" should I set for Skynet (I also use Diversion) in System Log: General Log?

www.snbforums.com

 

[ExtremeFiretop]

View attachment 68869
I have it set to info. I thought this would mean the only messages hidden are the debug level. Am I mistaken? I'm not sure how the "Default message log level" affects this, but I don't remember changing anything here from defaults. I guess this does mean that if the rc_service: start_upgrade is a kernel message, it wouldn't be shown.

Can I ask you to share a screenshot of your spdMerlin configuration? For example, which binary are you using? built-in or external? etc
May help us recreate your situation better. Thank you.

 

[aletaziar]

Can I ask you to share a screenshot of your spdMerlin configuration? For example, which binary are you using? built-in or external? etc
May help us recreate your situation better. Thank you.

imgur link, the forum kept resizing it

 

[visortgw]

I just confirmed MerlinAU compatibility with RT-BE58 Go with an update from 3006.102.6_beta2 to 3006.102.6_0.

 

[ExtremeFiretop]

I just confirmed MerlinAU compatibility with RT-BE58 Go with an update from 3006.102.6_beta2 to 3006.102.6_0.

Fantastic news @visortgw i appreciate you reporting back your success!

I thought in theory it should work, but always good to have someone validate that assumption with some first hand experience.

 

[Untried3868]

Question regarding upgrading an AiMesh node from the router using MerlinAU. After upgrading the router to 102.6 via MerlinAU, I had it check the node and it showed no update available. So I SSH'd into the node, ran MerlinAU and it did show an update and I upgraded then and there.

Is there an issue? Should MerlinAU see an update for the node and can it update the node from the router?

 

[visortgw]

Question regarding upgrading an AiMesh node from the router using MerlinAU. After upgrading the router to 102.6 via MerlinAU, I had it check the node and it showed no update available. So I SSH'd into the node, ran MerlinAU and it did show an update and I upgraded then and there.

Is there an issue? Should MerlinAU see an update for the node and can it update the node from the router?

It should determine that an update is available, but it cannot perform the update.

 

[ExtremeFiretop]

Question regarding upgrading an AiMesh node from the router using MerlinAU. After upgrading the router to 102.6 via MerlinAU, I had it check the node and it showed no update available. So I SSH'd into the node, ran MerlinAU and it did show an update and I upgraded then and there.

Is there an issue? Should MerlinAU see an update for the node and can it update the node from the router?

It should determine that an update is available, but it cannot perform the update.

Correct. With one caveat.
It will only determine if an update is available once the node itself detects an update available.

That would of been likely tonight by its own built-in webs_update script being triggered, or the next time it was triggered to check via MerlinAU
(Either automatically via scheduled cron, or manually as he did by logging into the node and manually running MerlinAU)

If the node does not yet detect an update for itself, the primary won't know about an available update either. It relies on the node to be self aware of available updates.
Edit: For example, if he logged into the node, ran MerlinAU, but didn't immediately update it, then the primary would see the update available next time he ran MerlinAU)

 

[visortgw]

Correct. With one caveat.

It will only determine if an update is available once the node itself detects an update available.

That would of been likely tonight by its own built-in webs_update script being triggered, or the next time it was triggered to check via MerlinAU

(Either automatically via scheduled cron, or manually as he did by logging into the node and manually running MerlinAU)

If the node does not yet detect an update for itself, the primary won't know about an available update either. It relies on the node to be self aware of available updates.

Edit: For example, if he logged into the node, ran MerlinAU, but didn't immediately update it, then the primary would see the update available next time he ran MerlinAU)

Thanks for setting me straight — I wasn't aware of the caveat (or I forgot that it was the case).

 

[ExtremeFiretop]

Thanks for setting me straight — I wasn't aware of the caveat (or I forgot that it was the case).

It's a minor detail that is very easy to miss, and on second thought I am currently in the process of re-evaluating the need for the node to be self aware or if it makes sense to make the primary ignore the webs_update flag on the node completely.

 

[Untried3868]

Thank you @visortgw and @ExtremeFiretop

 

[ExtremeFiretop]

Thank you @visortgw and @ExtremeFiretop

No worries, after re-reviewing the code, the reason we rely on the node to be “aware” of the update first is actually pretty simple.
When MerlinAU checks nodes from the primary, it doesn’t invent its own view of what’s available. It reads the node’s own webs_state_info, which is populated by the built-in webs_update script. That’s how we make sure the info we’re pulling isn’t stale and really does reflect a new update the node has already detected.

Detaching from that would basically mean ignoring webs_update on the node and implementing a completely separate update-detection path for AiMesh nodes.
Technically doable, but webs_update is something we’ve intentionally leaned on since the very beginning, and ripping that out could have wider implications.

webs_update itself is a small script that RMerlin maintains (roughly ~100 lines), whereas MerlinAU is sitting at over 11,000 lines for handling the flashing side of things.
Using the existing firmware update mechanism and simply triggering it when needed is both simpler and more robust. It also guarantees MerlinAU never drifts out of sync with what the firmware itself thinks is available.

So for now, that dependency is by design. I’m still evaluating whether it makes sense for the primary to bypass that in some scenarios, but that’s the rationale behind the current behavior.

 

[ExtremeFiretop]

MerlinAU 1.5.7 Released!

What's Changed/Fixed?:

PR: [ #529 ] - Improved Code to Unmount USB Drives

• Improved/modified code that tries to unmount the USB-attached drives before flashing the F/W.
• If any USB drive is "busy", the code waits until it becomes idle, up to a maximum of 4 minutes.
• This is in an attempt to solve the issue reported by @aletaziar
• (Thanks @Martinski4GitHub )

PR: [ #531 ] - Email Notification when USB Drive Unmount Fails

• Added an email notification when unmounting the USB-attached drive fails after trying for 4 minutes.
• This in response to the issue reported by @aletaziar
• (Thanks @Martinski4GitHub )

PR: [ #532 ] - Code Improvements

• Modified code to make sure we get correct parameters when changing settings from the WebUI.
• Essentially, sometimes when diff'ing the configuration file looking for modified settings from the WebUI, the diff results would show more than just the modified lines, so the code handling a setting change was being triggered for a "change" that actually didn't happen.
• AFAICT, in the case of MerlinAU, this issue wouldn't cause a malfunction or an error, but we didn't run all the possible scenarios, so Martinski decided to fix it anyway since that's the "right thing to do."
• (Thanks @Martinski4GitHub )

As always, we highly recommend you update ASAP as this includes functional improvements and little bug fixes.
Thanks!